> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Qué ocurre con las vistas materializadas actualizables cuando se reinicia el servidor

> Por qué todas las vistas materializadas actualizables pueden actualizarse a la vez al reiniciar un servidor y cómo volver a iniciarlas de una en una.

<Warning>
  Una vista materializada actualizable cuyas actualizaciones no se coordinan a través de ClickHouse Keeper pierde el registro de su última actualización, por lo que puede volver a actualizarse en cuanto el servidor esté listo. Un servidor con muchas vistas de este tipo, o con vistas sobre grandes conjuntos de datos, puede acabar ejecutando simultáneamente muchas actualizaciones completas justo cuando menos capacidad tiene para asumirlas.
</Warning>

<h2 id="which-views-keep-their-schedule">
  ¿Qué vistas conservan su programación?
</h2>

Las actualizaciones de una vista en una base de datos [`Replicated`](/es/reference/engines/database-engines/replicated) se coordinan a través de ClickHouse Keeper. En ClickHouse Cloud, lo mismo ocurre con una base de datos [`Shared`](/es/cloud/reference/shared-catalog). 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.

<h2 id="the-extra-refreshes-can-also-duplicate-data">
  Las actualizaciones adicionales también pueden duplicar datos
</h2>

Una vista `APPEND` 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.

<h2 id="keep-every-view-stopped-when-the-server-comes-up">
  Mantener todas las vistas detenidas al iniciar el servidor
</h2>

Establezca [`stop_refreshable_materialized_views_on_startup`](/es/reference/settings/session-settings/other#stop_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:

```xml title="/etc/clickhouse-server/users.d/refreshable_materialized_views.xml" theme={null}
<clickhouse>
    <profiles>
        <default>
            <stop_refreshable_materialized_views_on_startup>1</stop_refreshable_materialized_views_on_startup>
        </default>
    </profiles>
</clickhouse>
```

El ejemplo utiliza el perfil predeterminado `default`. Sustitúyalo por su perfil personalizado `system_profile` si lo utiliza.

[`SYSTEM STOP VIEWS`](/es/reference/statements/system#stop-view-stop-views) no es una alternativa válida, ya que el estado de detención que establece no persiste tras un reinicio.

<h2 id="start-the-views-one-at-a-time">
  Iniciar las vistas de una en una
</h2>

[`SYSTEM START VIEWS`](/es/reference/statements/system#start-view-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`](/es/reference/system-tables/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:

```sql theme={null}
SYSTEM START VIEW my_database.my_view;
SYSTEM WAIT VIEW my_database.my_view;
```

Iniciar una vista solo reanuda su programación y, a diferencia de [`SYSTEM REFRESH VIEW`](/es/reference/statements/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`](/es/reference/statements/system#wait-view) se queda bloqueado mientras se ejecuta esa actualización.

Una vista que está esperando un requisito previo de [`REFRESH ... DEPENDS ON`](/es/reference/statements/create/view#refresh-dependencies) 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.

<h2 id="what-this-means-for-your-automation">
  Qué significa esto para su automatización
</h2>

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.