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.

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.

​

Quelles vues conservent leur planification ?

Pour une vue d’une base de données 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. 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.

​

Les rafraîchissements supplémentaires peuvent également dupliquer des données

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.

​

Maintenir toutes les vues arrêtées au démarrage du serveur

Définissez 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 :

/etc/clickhouse-server/users.d/refreshable_materialized_views.xml

<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 ne constitue pas une alternative, car l’état d’arrêt qu’elle définit n’est pas conservé après un redémarrage.

​

Démarrer les vues une par une

SYSTEM 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 les répertorie. Dans ClickHouse Cloud, cette table système est locale à chaque nœud ; il faut donc l’interroger sur chacun d’eux :

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, 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 reste bloqué pendant l’exécution de ce rafraîchissement.

Une vue qui attend un prérequis REFRESH ... DEPENDS ON 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.

​

Ce que cela implique pour votre automatisation

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.