Cette section présente de manière générale les sauvegardes et les restaurations dans ClickHouse. Pour une description plus détaillée de chaque méthode de sauvegarde, consultez les pages consacrées aux méthodes spécifiques dans la barre latérale.
Introduction
MergeTree contenant plus de
50 Go de données. Cependant, ces mécanismes de protection ne couvrent pas tous les cas possibles et
des problèmes peuvent malgré tout survenir.
Pour limiter efficacement les erreurs humaines potentielles, vous devez préparer avec soin une
stratégie de sauvegarde et de restauration de vos données à l’avance.
Chaque entreprise dispose de ressources et d’exigences métier différentes. Il
n’existe donc pas de solution universelle de sauvegarde et de restauration ClickHouse qui convienne
à toutes les situations. Ce qui fonctionne pour un gigaoctet de données ne fonctionnera probablement
pas pour des dizaines de pétaoctets de données. Il existe diverses approches possibles, chacune avec ses avantages
et ses inconvénients, présentées dans cette section de la documentation. Il est judicieux
d’utiliser plusieurs approches plutôt qu’une seule afin de compenser leurs différentes
limites.
Gardez à l’esprit que si vous avez sauvegardé quelque chose sans jamais essayer de le restaurer,
il y a de fortes chances que la restauration ne fonctionne pas correctement lorsque vous en aurez réellement besoin (ou qu’à tout
le moins, elle prenne plus de temps que ce que l’entreprise peut tolérer). Quelle que soit l’approche de sauvegarde
que vous choisissez, veillez également à automatiser le processus de restauration et entraînez-vous
régulièrement sur un cluster ClickHouse de rechange.
| Page | Description |
|---|---|
| Sauvegarde/restauration à l’aide d’un disque local ou d’un disque S3 | Détaille la sauvegarde/restauration vers ou depuis un disque local ou un disque S3 |
| Sauvegarde/restauration à l’aide d’un endpoint S3 | Détaille la sauvegarde/restauration vers ou depuis un endpoint S3 |
| Sauvegarde/restauration à l’aide d’AzureBlobStorage | Détaille la sauvegarde/restauration vers ou depuis Azure Blob Storage |
| Méthodes alternatives | Présente des méthodes de sauvegarde alternatives |
| Sauvegarde snapshot | Snapshots légers pour les tables SharedMergeTree utilisant le stockage d’objets cloud |
- être complètes ou incrémentielles
- être synchrones ou asynchrones
- être concurrentes ou non concurrentes
- être compressées ou non compressées
- utiliser des collections nommées
- être protégées par mot de passe
- porter sur des tables système, tables de logs ou tables de gestion des accès
Types de sauvegarde
- Les sauvegardes complètes pour les petites bases de données ou les données critiques.
- Les sauvegardes incrémentielles pour les grandes bases de données ou lorsque les sauvegardes doivent être effectuées fréquemment et à moindre coût.
- Les deux, par exemple des sauvegardes complètes hebdomadaires et des sauvegardes incrémentielles quotidiennes.
Sauvegardes synchrones et asynchrones
BACKUP et RESTORE peuvent également être marquées ASYNC. Dans ce cas, la
commande de sauvegarde renvoie immédiatement, et le processus de sauvegarde s’exécute en arrière-plan.
Si les commandes ne sont pas marquées ASYNC, le processus de sauvegarde est synchrone et
la commande reste bloquée jusqu’à ce que la sauvegarde soit terminée.
Sauvegardes concurrentes ou non concurrentes
Sauvegardes compressées ou non compressées
compression_method et compression_level.
Lors de la création d’une sauvegarde, vous pouvez spécifier :
Utilisation des collections nommées
- Masquer les identifiants aux utilisateurs sans accès administrateur
- Simplifier les commandes en centralisant les configurations complexes
- Assurer la cohérence entre les opérations
- Éviter l’exposition des identifiants dans les journaux de requêtes
Sauvegarde des tables système, de journalisation ou de gestion des accès
_log (par ex.,
query_log, part_log), peuvent être sauvegardées et restaurées comme n’importe quelle autre table.
Si votre cas d’usage repose sur l’analyse de données historiques — par exemple, l’utilisation de query_log
pour suivre les performances des requêtes ou déboguer des problèmes — il est recommandé d’inclure ces
tables dans votre stratégie de sauvegarde. En revanche, si les données historiques de ces tables ne sont
pas nécessaires, elles peuvent être exclues afin d’économiser de l’espace de stockage pour les sauvegardes.
Les tables système liées à la gestion des accès, telles que users, roles, row_policies,
settings_profiles et quotas, font l’objet d’un traitement particulier lors des opérations de sauvegarde et de restauration.
Lorsque ces tables sont incluses dans une sauvegarde, leur contenu est exporté dans un fichier spécial
accessXX.txt, qui contient les instructions SQL équivalentes pour créer
et configurer les entités d’accès. Lors de la restauration, le processus de restauration
interprète ces fichiers et réapplique les commandes SQL pour recréer les utilisateurs,
les rôles et les autres configurations. Cette fonctionnalité garantit que la configuration du contrôle d’accès
d’un cluster ClickHouse peut être sauvegardée et restaurée dans le cadre de
la configuration globale du cluster.
Cette fonctionnalité ne fonctionne que pour les configurations gérées au moyen de commandes SQL
(désignées sous le nom de “contrôle d’accès et gestion des comptes pilotés par SQL”).
Les configurations d’accès définies dans les fichiers de configuration du serveur ClickHouse (par ex. users.xml)
ne sont pas incluses dans les sauvegardes et ne peuvent pas être restaurées par cette méthode.
Syntaxe générale
Résumé des commandes
| Commande | Description | |
|---|---|---|
BACKUP | Crée une sauvegarde des objets spécifiés | |
RESTORE | Restaure des objets à partir d’une sauvegarde | |
TABLE [db.]table_name [AS [db.]table_name_in_backup] | Sauvegarde/restaure une table spécifique (peut être renommée) | |
[PARTITION[S] partition_expr [,...]] | Sauvegarde/restaure uniquement certaines partitions de la table | |
DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] | Sauvegarde/restaure un dictionnaire | |
DATABASE database_name [AS database_name_in_backup] | Sauvegarde/restaure une base de données entière (peut être renommée) | |
TEMPORARY TABLE table_name [AS table_name_in_backup] | Sauvegarde/restaure une table temporaire (peut être renommée) | |
VIEW view_name [AS view_name_in_backup] | Sauvegarde/restaure une vue (peut être renommée) | |
[EXCEPT TABLES ...] | Exclut certaines tables lors de la sauvegarde d’une base de données | |
ALL | Sauvegarde/restaure tout (toutes les bases de données, tables, etc.). Avant la version 23.4 de ClickHouse, ALL ne s’appliquait qu’à la commande RESTORE. | |
[EXCEPT {TABLES|DATABASES}...] | Exclut certaines tables ou bases de données lors de l’utilisation de ALL | |
[ON CLUSTER 'cluster_name'] | Exécute la sauvegarde/restauration sur l’ensemble d’un cluster ClickHouse | |
TO|FROM | Direction : TO pour la destination de sauvegarde, FROM pour la source de restauration | |
File('<path>/<filename>') | Stocke dans/restaure depuis le système de fichiers local | |
Disk('<disk_name>', '<path>/') | Stocke sur/restaure depuis un disque configuré | |
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>') | Stocke sur/restaure depuis Amazon S3 ou un stockage compatible S3 | |
[SETTINGS ...] | Voir ci-dessous pour la liste complète des paramètres | |
[ASYNC] | Exécute l’opération de manière asynchrone (renvoie immédiatement un ID que vous pouvez surveiller) |
Paramètres
| Paramètre | Description | Valeur par défaut |
|---|---|---|
id | Identifiant de l’opération de sauvegarde ou de restauration ; un UUID généré aléatoirement est utilisé s’il n’est pas spécifié. S’il existe déjà une opération en cours avec le même identifiant, une exception est levée. | |
compression_method | Spécifie la méthode de compression de la sauvegarde. Voir la section “codecs de compression des colonnes” | |
compression_level | Définit le niveau de compression de la sauvegarde | |
password | Mot de passe de l’archive de sauvegarde. Uniquement pris en charge pour les archives ZIP (.zip, .zipx). | |
base_backup | La destination de la sauvegarde de base utilisée pour les sauvegardes incrémentielles. Par exemple : Disk('backups', '1.zip') | |
use_same_password_for_base_backup | Indique si l’archive de sauvegarde de base doit hériter du mot de passe de la requête. | |
structure_only | Si ce paramètre est activé, seules les instructions CREATE sont sauvegardées ou restaurées, sans les données de la table. | |
storage_policy | Politique de stockage des tables en cours de restauration. Voir “utilisation de plusieurs périphériques bloc pour le stockage des données. Applicable uniquement à la commande RESTORE. S’applique uniquement aux tables utilisant un moteur de la famille MergeTree. | |
allow_non_empty_tables | Permet à RESTORE TABLE d’insérer des données dans des tables non vides. Les données déjà présentes dans la table seront alors mélangées à celles extraites de la sauvegarde. Ce paramètre peut donc entraîner une duplication des données dans la table ; à utiliser avec prudence. | 0 |
backup_restore_keeper_max_retries | Nombre maximal de tentatives pour les opérations [Zoo]Keeper au cours d’une opération BACKUP ou RESTORE. Il doit être suffisamment élevé pour que l’ensemble de l’opération n’échoue pas en raison d’une défaillance temporaire de [Zoo]Keeper. | 1000 |
backup_restore_keeper_retry_initial_backoff_ms | Délai de backoff initial pour les opérations [Zoo]Keeper pendant une sauvegarde ou une restauration | 100 |
backup_restore_keeper_retry_max_backoff_ms | Délai de backoff maximal pour les opérations [Zoo]Keeper pendant une sauvegarde ou une restauration | 5000 |
backup_restore_failure_after_host_disconnected_for_seconds | Si, lors d’une opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER, un hôte ne recrée pas son nœud éphémère ‘alive’ dans ZooKeeper pendant cette durée, l’ensemble de la sauvegarde ou de la restauration est considéré comme ayant échoué. Cette valeur doit être supérieure à tout délai raisonnable nécessaire à un hôte pour se reconnecter à ZooKeeper après une défaillance. Zéro signifie illimité. | 3600 |
backup_restore_keeper_max_retries_while_initializing | Nombre maximal de tentatives pour les opérations [Zoo]Keeper lors de l’initialisation d’une opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER. | 20 |
backup_restore_keeper_max_retries_while_handling_error | Nombre maximal de tentatives pour les opérations [Zoo]Keeper lors de la gestion d’une erreur survenant pendant une opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER. | 20 |
backup_restore_finish_timeout_after_error_sec | Durée pendant laquelle l’initiateur doit attendre que les autres hôtes réagissent au nœud ‘error’ et arrêtent leur travail sur l’opération BACKUP ON CLUSTER ou RESTORE ON CLUSTER en cours. | 180 |
backup_restore_keeper_value_max_size | Taille maximale des données d’un nœud [Zoo]Keeper pendant une sauvegarde | 1048576 |
backup_restore_batch_size_for_keeper_multi | Taille maximale du batch pour une requête multiple vers [Zoo]Keeper lors d’une sauvegarde ou d’une restauration | 1000 |
backup_restore_batch_size_for_keeper_multiread | Taille maximale du batch pour une requête de lecture multiple vers [Zoo]Keeper lors d’une sauvegarde ou d’une restauration | 10000 |
backup_restore_keeper_fault_injection_probability | Probabilité approximative d’échec d’une requête Keeper lors d’une sauvegarde ou d’une restauration. La valeur doit être comprise dans l’intervalle [0.0f, 1.0f] | 0 |
backup_restore_keeper_fault_injection_seed | 0 pour une valeur d’initialisation aléatoire, sinon la valeur du paramètre | 0 |
backup_restore_s3_retry_attempts | Paramètre pour Aws::Client::RetryStrategy ; Aws::Client gère lui-même les tentatives de nouvelle exécution, 0 signifie aucune tentative. S’applique uniquement à la sauvegarde/restauration. | 1000 |
max_backup_bandwidth | Vitesse de lecture maximale en octets par seconde pour une sauvegarde donnée sur le serveur. Zéro signifie illimité. | 0 |
max_backups_io_thread_pool_size | ClickHouse utilise des threads du pool de threads IO des sauvegardes pour effectuer les opérations IO des sauvegardes S3. max_backups_io_thread_pool_size limite le nombre maximal de threads dans le pool. | 1000 |
max_backups_io_thread_pool_free_size | Si le nombre de threads inactifs dans le Backups IO Thread pool dépasse max_backup_io_thread_pool_free_size, ClickHouse libère les ressources occupées par ces threads et réduit la taille du pool. Des threads pourront être recréés si nécessaire. | 0 |
backups_io_thread_pool_queue_size | Le nombre maximal de jobs pouvant être planifiés dans le pool de threads d’E/S des sauvegardes. Il est recommandé de laisser cette file d’attente illimitée en raison du fonctionnement actuel des sauvegardes S3. Remarque : une valeur de 0 (par défaut) signifie qu’elle est illimitée. | 0 |
backup_threads | Le nombre maximal de threads utilisés pour exécuter les requêtes BACKUP. | |
max_backup_bandwidth_for_server | La vitesse de lecture maximale, en octets par seconde, pour toutes les sauvegardes sur le serveur. Zéro signifie aucune limite. | 0 |
shutdown_wait_backups_and_restores | Si cette option est définie sur true, ClickHouse attendra la fin des sauvegardes et restaurations en cours avant de s’arrêter. | 1 |
| Paramètre | Description | Valeur par défaut |
|---|---|---|
use_same_s3_credentials_for_base_backup | Indique si la sauvegarde de base vers S3 doit hériter des identifiants de la requête. Fonctionne uniquement avec S3. | |
s3_storage_class | Classe de stockage utilisée pour la sauvegarde S3. Par exemple : STANDARD |
| Paramètre | Description | Valeur par défaut | ||
|---|---|---|---|---|
azure_attempt_to_create_container | Lors de l’utilisation d’Azure Blob Storage, indique s’il faut essayer de créer le conteneur spécifié s’il n’existe pas. | true |
Administration et dépannage
id et un status, et cet id peut être utilisé pour
obtenir l’état de la sauvegarde. C’est très utile pour suivre l’avancement de
sauvegardes ASYNC de longue durée. L’exemple ci-dessous montre un échec survenu lors d’une tentative
d’écrasement d’un fichier de sauvegarde existant :
system.backups, toutes les opérations de sauvegarde et de restauration sont également consignées dans la table de journalisation système
system.backup_log :