> ## 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.

# Que deviennent les vues matérialisées actualisables lors du redémarrage du serveur ?

> Pourquoi les vues matérialisées actualisables peuvent toutes se rafraîchir en même temps au redémarrage d'un serveur, et comment les relancer une par une.

<Warning>
  Une vue matérialisée actualisable dont les rafraîchissements ne sont pas coordonnés via ClickHouse Keeper perd la trace de son dernier rafraîchissement : elle peut donc se rafraîchir à nouveau dès que le serveur est prêt. Sur un serveur comportant de nombreuses vues de ce type, ou des vues portant sur de grands jeux de données, de nombreux rafraîchissements complets peuvent ainsi être lancés simultanément, au moment précis où il est le moins à même de les absorber.
</Warning>

<h2 id="which-views-keep-their-schedule">
  Quelles vues conservent leur planification ?
</h2>

Pour une vue d'une base de données [`Replicated`](/fr/reference/engines/database-engines/replicated), les rafraîchissements sont coordonnés par ClickHouse Keeper. Dans ClickHouse Cloud, il en va de même pour une base de données [`Shared`](/fr/cloud/reference/shared-catalog). Dans l'une ou l'autre de ces bases de données Cloud, une vue de la famille `APPEND` peut se soustraire à cette coordination avec `SETTINGS all_replicas = 1` ; sur un serveur ClickHouse open source, seule une base de données `Replicated` bénéficie de cette coordination. Une vue sans coordination ne conserve l'heure de son dernier rafraîchissement qu'en mémoire : après un redémarrage, elle se retrouve donc en retard sur toute planification ordinaire. `RANDOMIZE FOR` ne permet pas d'étaler ces rafraîchissements.

<h2 id="the-extra-refreshes-can-also-duplicate-data">
  Les rafraîchissements supplémentaires peuvent également dupliquer des données
</h2>

Une vue `APPEND` ajoute un nouveau résultat complet. Une vue `APPEND INCREMENTAL` non coordonnée perd son curseur en mémoire lors d'un redémarrage, sauf si sa cible transactionnelle a validé ce curseur ; elle retraite alors des lignes qu'elle avait déjà ajoutées.

Échelonner le démarrage comme décrit ci-dessous limite le nombre de rafraîchissements exécutés simultanément, mais ne les empêche pas. Une vue `APPEND` évite l'ajout supplémentaire si vous ne la démarrez qu'au moment où son prochain rafraîchissement est de toute façon prévu. Une vue `APPEND INCREMENTAL` qui a perdu son curseur ne gagne rien à ce choix du moment : quelle que soit sa prochaine exécution, elle retraitera l'intégralité de la table source et ajoutera ce résultat. Laissez-la donc arrêtée jusqu'à ce que vous puissiez absorber ou supprimer les lignes dupliquées.

<h2 id="keep-every-view-stopped-when-the-server-comes-up">
  Maintenir toutes les vues arrêtées au démarrage du serveur
</h2>

Définissez [`stop_refreshable_materialized_views_on_startup`](/fr/reference/settings/session-settings/other#stop_refreshable_materialized_views_on_startup) dans le settings profile propre au serveur, c'est-à-dire le profil désigné par `system_profile`, ou à défaut `default_profile`, puis `default`. Ce paramètre est expérimental :

```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>
```

L'exemple utilise le profil par défaut `default`. Remplacez-le par votre profil personnalisé `system_profile` si vous en utilisez un.

[`SYSTEM STOP VIEWS`](/fr/reference/statements/system#stop-view-stop-views) ne constitue pas une alternative, car l'état d'arrêt qu'elle définit n'est pas conservé après un redémarrage.

<h2 id="start-the-views-one-at-a-time">
  Démarrer les vues une par une
</h2>

[`SYSTEM START VIEWS`](/fr/reference/statements/system#start-view-start-views) démarre toutes les vues simultanément, ce qui provoque le même pic de charge. Démarrez donc chaque vue individuellement, par son nom, et attendez la fin de son rafraîchissement avant de lancer la suivante. La table [`system.view_refreshes`](/fr/reference/system-tables/view_refreshes) les répertorie. Dans ClickHouse Cloud, cette table système est locale à chaque nœud ; il faut donc l'interroger sur chacun d'eux :

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

Démarrer une vue ne fait que reprendre sa planification et, contrairement à [`SYSTEM REFRESH VIEW`](/fr/reference/statements/system#refresh-view), ne déclenche aucun rafraîchissement supplémentaire. Une vue dont l'heure de rafraîchissement est passée pendant qu'elle était arrêtée est déjà en retard sur cette planification : elle se rafraîchit donc dès son démarrage, et [`SYSTEM WAIT VIEW`](/fr/reference/statements/system#wait-view) reste bloqué pendant l'exécution de ce rafraîchissement.

Une vue qui attend un prérequis [`REFRESH ... DEPENDS ON`](/fr/reference/statements/create/view#refresh-dependencies) ne se rafraîchit pas encore ; démarrez donc ces vues après celles dont elles dépendent. Une dépendance circulaire n'admet pas un tel ordre, et un redémarrage rompt le cycle dès lors que ses vues ne sont pas coordonnées : démarrez chaque membre, puis exécutez le même `SYSTEM REFRESH VIEW` que celui utilisé pour lancer le cycle lors de sa création, et attendez la fin de ce rafraîchissement. Un graphe dont le lancement a nécessité plusieurs rafraîchissements de ce type requiert à nouveau le même ensemble de rafraîchissements. Déclencher un autre membre peut laisser le cycle inactif, car une vue ne reprend qu'une fois que tous ses prérequis ont été rafraîchis. Une fois déclenché, le cycle se rafraîchit de lui-même : le démarrage vue par vue s'arrête donc au déclenchement.

<h2 id="what-this-means-for-your-automation">
  Ce que cela implique pour votre automatisation
</h2>

Tant que ce paramètre est en place, un redémarrage imprévu laisse toutes les vues matérialisées actualisables à l'arrêt, et une vue nouvellement créée ne commence pas non plus à se rafraîchir tant qu'elle n'a pas été démarrée. `RESTORE` fait exception pour les vues dont les rafraîchissements ne sont pas coordonnés : il démarre chacune des vues de ce type qu'il inclut, et celles-ci peuvent alors se retrouver immédiatement en retard et rejouer leur source. Une vue coordonnée n'est pas démarrée par la restauration ; elle reste donc arrêtée jusqu'à ce que vous la démarriez. Confiez le démarrage des vues à l'automatisation chargée de redémarrer vos serveurs et de créer vos vues.