¿Qué vistas conservan su programación?
Las actualizaciones de una vista en una base de datosReplicated se coordinan a través de ClickHouse Keeper. En ClickHouse Cloud, lo mismo ocurre con una base de datos Shared. Una vista de la familia APPEND en cualquiera de estas dos bases de datos de Cloud puede desactivar la coordinación con SETTINGS all_replicas = 1; en un servidor de ClickHouse de código abierto, solo las bases de datos Replicated cuentan con esta coordinación. Una vista sin coordinación guarda la hora de su última actualización únicamente en memoria, por lo que, tras un reinicio, queda con la actualización pendiente en cualquier programación ordinaria. RANDOMIZE FOR no escalona estas actualizaciones en el tiempo.
Las actualizaciones adicionales también pueden duplicar datos
Una vistaAPPEND anexa otro resultado completo. Una vista APPEND INCREMENTAL no coordinada pierde su cursor en memoria al reiniciarse, a menos que su destino transaccional haya hecho commit del cursor, por lo que vuelve a procesar filas que ya había anexado.
Escalonar el inicio como se describe a continuación limita cuántas actualizaciones se ejecutan a la vez, pero no evita que se ejecuten. Una vista APPEND evita el anexado adicional si solo la inicia cuando de todos modos le toca su próxima actualización. A una vista APPEND INCREMENTAL que ha perdido su cursor no le sirve de nada elegir el momento, porque la próxima vez que se ejecute volverá a procesar toda la tabla de origen y anexará ese resultado. Por lo tanto, manténgala detenida hasta que pueda asumir o eliminar las filas duplicadas.
Mantener todas las vistas detenidas al iniciar el servidor
Establezcastop_refreshable_materialized_views_on_startup en el perfil de configuración propio del servidor, es decir, el perfil indicado por system_profile; si no está definido, se usa default_profile y, en su defecto, default. Esta configuración es experimental:
/etc/clickhouse-server/users.d/refreshable_materialized_views.xml
default. Sustitúyalo por su perfil personalizado system_profile si lo utiliza.
SYSTEM STOP VIEWS no es una alternativa válida, ya que el estado de detención que establece no persiste tras un reinicio.
Iniciar las vistas de una en una
SYSTEM START VIEWS inicia todas las vistas a la vez, lo que provoca el mismo pico de carga, así que inicie cada vista por su nombre y espere a que finalice su actualización antes de iniciar la siguiente. system.view_refreshes muestra el listado de vistas. En ClickHouse Cloud, esta tabla del sistema es local de cada nodo, por lo que debe consultarla en cada uno de ellos:
SYSTEM REFRESH VIEW, no añade ninguna actualización propia. Una vista cuya hora de actualización pasó mientras estaba detenida ya va con retraso respecto a esa programación, por lo que se actualiza en cuanto se inicia, y SYSTEM WAIT VIEW se queda bloqueado mientras se ejecuta esa actualización.
Una vista que está esperando un requisito previo de REFRESH ... DEPENDS ON todavía no se está actualizando, así que inicie esas vistas después de aquellas de las que dependen. Una dependencia circular no admite ese orden, y un reinicio rompe el ciclo siempre que sus vistas no estén coordinadas: inicie todos los miembros, ejecute después el mismo SYSTEM REFRESH VIEW que utilizó para iniciar el ciclo al crearlo y espere a que termine esa actualización. Un grafo que necesitó más de una actualización de este tipo para arrancar requiere de nuevo el mismo conjunto. Activar un miembro distinto puede dejar el ciclo inactivo, porque una vista solo se reanuda cuando todos sus requisitos previos se han actualizado. Una vez activado, el ciclo se actualiza por sí solo, así que la cadencia de una vista a la vez termina con la activación.
Qué significa esto para su automatización
Mientras esta configuración esté vigente, un reinicio no planificado deja detenidas todas las vistas materializadas actualizables, y una vista recién creada tampoco empieza a actualizarse hasta que se inicia.RESTORE es la excepción en el caso de las vistas cuyas actualizaciones no están coordinadas: inicia todas las vistas de este tipo que incluye, por lo que una de ellas puede quedar atrasada de inmediato y volver a procesar su origen. Las vistas coordinadas no se inician al restaurar, así que permanecen detenidas hasta que usted las inicie. Haga que la automatización encargada de reiniciar sus servidores y crear sus vistas sea también la responsable de iniciarlas.