Sauvegarde et restauration dans ClickHouse

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.

Bien que la réplication offre une protection contre les pannes matérielles, elle ne protège pas contre les erreurs humaines : suppression accidentelle de données, suppression de la mauvaise table ou d'une table sur le mauvais cluster, et bogues logiciels entraînant un traitement incorrect des données ou leur corruption.

Dans de nombreux cas, ce type d'erreur affectera toutes les répliques. ClickHouse intègre des mécanismes de protection pour éviter certains types d'erreurs. Par exemple, par défaut vous ne pouvez pas simplement supprimer des tables utilisant un moteur de la famille 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.

Les pages suivantes détaillent les différentes méthodes de sauvegarde et de restauration disponibles dans ClickHouse :

Les sauvegardes peuvent :

• ê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 journalisation ou tables de gestion des accès

Les sauvegardes peuvent être complètes ou incrémentielles. Les sauvegardes complètes constituent une copie intégrale des données, tandis que les sauvegardes incrémentielles ne contiennent que les modifications apportées depuis la dernière sauvegarde complète.

Les sauvegardes complètes offrent l’avantage d’être une méthode de récupération simple, indépendante (des autres sauvegardes) et fiable. Cependant, elles peuvent prendre beaucoup de temps à s’exécuter et occuper beaucoup d’espace. Les sauvegardes incrémentielles, en revanche, sont plus efficaces à la fois en temps et en espace, mais la restauration des données nécessite que toutes les sauvegardes soient disponibles.

Selon vos besoins, vous pouvez privilégier :

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

Les commandes 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.

Par défaut, ClickHouse autorise les sauvegardes et les restaurations concurrentes. Cela signifie que vous pouvez lancer simultanément plusieurs opérations de sauvegarde ou de restauration. Cependant, des paramètres au niveau du serveur permettent de désactiver ce comportement. Si vous définissez ces paramètres sur false, une seule opération de sauvegarde ou de restauration peut s’exécuter sur un cluster à la fois. Cela peut aider à éviter la contention des ressources ou d’éventuels conflits entre les opérations.

Pour interdire les sauvegardes/restaurations concurrentes, vous pouvez utiliser respectivement les paramètres suivants :

<clickhouse>
    <backups>
        <allow_concurrent_backups>false</allow_concurrent_backups>
        <allow_concurrent_restores>false</allow_concurrent_restores>
    </backups>
</clickhouse>

La valeur par défaut des deux est true ; par défaut, les sauvegardes/restaurations concurrentes sont donc autorisées. Lorsque ces paramètres sont définis sur false sur un cluster, une seule sauvegarde/restauration peut être exécutée sur un cluster à la fois.

Les sauvegardes ClickHouse prennent en charge la compression via les paramètres compression_method et compression_level.

Lors de la création d’une sauvegarde, vous pouvez spécifier :

BACKUP TABLE test.table
  TO Disk('backups', 'filename.zip')
  SETTINGS compression_method='lzma', compression_level=3

Les collections nommées vous permettent de stocker des paires clé-valeur (comme des identifiants S3, des endpoints et des paramètres) réutilisables dans les opérations de sauvegarde/restauration. Elles permettent de :

• 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

Voir « collections nommées » pour plus de détails.

Les tables système peuvent également être incluses dans vos workflows de sauvegarde et de restauration, mais leur prise en compte dépend de votre cas d’usage.

Les tables système qui stockent des données historiques, comme celles avec le suffixe _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.

-- core commands
BACKUP | RESTORE 
--- what to backup/restore (or exclude)
TABLE [db.]table_name           [AS [db.]table_name_in_backup] |
DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] |
DATABASE database_name          [AS database_name_in_backup] |
TEMPORARY TABLE table_name      [AS table_name_in_backup] |
VIEW view_name                  [AS view_name_in_backup] |
[EXCEPT TABLES ...] |
ALL [EXCEPT {TABLES|DATABASES}...] } [,...]
--- 
[ON CLUSTER 'cluster_name']
--- where to backup or restore to or from
TO|FROM 
File('<path>/<filename>') | 
Disk('<disk_name>', '<path>/') | 
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>', '<extra_credentials>') |
AzureBlobStorage('<connection string>/<url>', '<container>', '<path>', '<account name>', '<account key>')
--- additional settings
[SETTINGS ...]
[ASYNC]

Consultez "résumé des commandes" pour obtenir plus de détails sur chaque commande.

Chacune des commandes ci-dessus est détaillée ci-dessous :

Paramètres génériques de sauvegarde/restauration

Paramètres spécifiques à S3

Paramètres spécifiques à Azure

La commande de sauvegarde renvoie un 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 :

BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC

┌─id───────────────────────────────────┬─status──────────┐
│ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │
└──────────────────────────────────────┴─────────────────┘

1 row in set. Elapsed: 0.001 sec.

SELECT
*
FROM system.backups
WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52'
FORMAT Vertical

Row 1:
──────
id:                7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:              Disk('backups', '1.zip')
status:            BACKUP_FAILED
num_files:         0
uncompressed_size: 0
compressed_size:   0
error:             Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 22.8.2.11 (official build))
start_time:        2022-08-30 09:21:46
end_time:          2022-08-30 09:21:46

1 row in set. Elapsed: 0.002 sec.

Outre la table 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 :

SELECT *
FROM system.backup_log
WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52'
ORDER BY event_time_microseconds ASC
FORMAT Vertical

Row 1:
──────
event_date:              2023-08-18
event_time_microseconds: 2023-08-18 11:13:43.097414
id:                      7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:                    Disk('backups', '1.zip')
status:                  CREATING_BACKUP
error:
start_time:              2023-08-18 11:13:43
end_time:                1970-01-01 03:00:00
num_files:               0
total_size:              0
num_entries:             0
uncompressed_size:       0
compressed_size:         0
files_read:              0
bytes_read:              0

Row 2:
──────
event_date:              2023-08-18
event_time_microseconds: 2023-08-18 11:13:43.174782
id:                      7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:                    Disk('backups', '1.zip')
status:                  BACKUP_FAILED
error:                   Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 23.8.1.1)
start_time:              2023-08-18 11:13:43
end_time:                2023-08-18 11:13:43
num_files:               0
total_size:              0
num_entries:             0
uncompressed_size:       0
compressed_size:         0
files_read:              0
bytes_read:              0

2 rows in set. Elapsed: 0.075 sec.