このセクションでは、ClickHouse におけるバックアップと復元の概要を説明します。各バックアップ方法のより 詳細な説明については、サイドバーにある各方法のページを参照してください。
はじめに
MergeTree ファミリーのエンジンを使用するテーブルを
そのまま削除することはできません。とはいえ、こうした安全策ですべてのケースを
カバーできるわけではなく、問題が発生する可能性は残ります。
想定される人的ミスを効果的に軽減するには、
データのバックアップと復元のための戦略をあらかじめ慎重に準備しておく必要があります。
利用できるリソースや業務要件は会社ごとに異なるため、
あらゆる状況に適した ClickHouse のバックアップと復元の万能な解決策は
存在しません。1 ギガバイトのデータに有効な方法が、数十
PB のデータには通用しない可能性があります。考えられるアプローチにはそれぞれ長所と短所が
あり、このドキュメントのこのセクションで紹介しています。さまざまな
欠点を補うために、1 つだけでなく複数のアプローチを併用することをお勧めします。
何かをバックアップしても、一度も復元を試したことがない場合、
実際に必要になったときに復元が正しく動作しない可能性があります (少なくとも、
業務で許容できるよりも長い時間がかかるでしょう) 。したがって、どのバックアップ
アプローチを選ぶ場合でも、復元プロセスも自動化し、定期的に予備の
ClickHouse クラスターで復元手順を検証してください。
| Page | Description |
|---|---|
| ローカルディスクまたは S3 disk を使用したバックアップ/復元 | ローカルディスクまたは S3 disk への、またはそれらからのバックアップ/復元について詳しく説明します |
| S3 エンドポイントを使用したバックアップ/復元 | S3 エンドポイントへの、またはそこからのバックアップ/復元について詳しく説明します |
| AzureBlobStorage を使用したバックアップ/復元 | Azure blob storage への、またはそこからのバックアップ/復元について詳しく説明します |
| 代替手法 | 代替のバックアップ方法について説明します |
| スナップショットバックアップ | クラウドオブジェクトストレージを使用する SharedMergeTree テーブル向けの軽量スナップショット |
- フルまたは増分
- 同期または非同期
- 同時実行または非同時実行
- 圧縮または非圧縮
- named collections を使用
- パスワードで保護
- システムテーブル、ログテーブル、または アクセス管理テーブル のバックアップを取得
バックアップの種類
- フルバックアップ: 小規模なデータベースや重要なデータ向け。
- 増分バックアップ: 大規模なデータベース向け、またはバックアップを高頻度かつコスト効率よく実行する必要がある場合。
- 両方: たとえば、毎週フルバックアップを実行し、毎日増分バックアップを実行します。
同期バックアップと非同期バックアップ
BACKUP コマンドと RESTORE コマンドには、ASYNC を指定することもできます。この場合、
バックアップコマンドはすぐに制御を返し、バックアップ処理はバックグラウンドで実行されます。
コマンドに ASYNC を指定しない場合、バックアップ処理は同期的に実行され、
バックアップが完了するまでコマンドは待機します。
同時実行バックアップと非同時実行バックアップ
圧縮バックアップと非圧縮バックアップ
compression_method および compression_level 設定により圧縮を利用できます。
バックアップの作成時には、以下を指定できます。
named collections の使用
- 管理者アクセス権のないユーザーに認証情報を見せない
- 複雑な構成を一元管理して、コマンドを簡素化する
- 操作間の一貫性を保つ
- クエリログに認証情報が露出するのを防ぐ
システム、ログ、またはアクセス管理テーブルのバックアップ
_log 接尾辞を持つもの (たとえば
query_log、part_log) など、履歴データを格納するシステムテーブルは、
他のテーブルと同様にバックアップおよび復元できます。
ユースケース上、履歴データの分析が必要な場合、たとえば query_log を使って
クエリのパフォーマンスを追跡したり問題をデバッグしたりする場合は、これらの
テーブルをバックアップ戦略に含めることを推奨します。ただし、これらのテーブルの履歴データが
不要であれば、バックアップの保存容量を節約するために除外できます。
users、ロール、row_policies、
settings_profiles、quotas などのアクセス管理に関連するシステムテーブルは、バックアップおよび復元操作時に
特別な扱いを受けます。
これらのテーブルがバックアップに含まれると、その内容は特別な
accessXX.txt ファイルにエクスポートされ、このファイルにはアクセスエンティティの作成と
設定に対応する SQL ステートメントがまとめられます。復元時には、復元処理が
これらのファイルを解釈し、SQL コマンドを再適用して users、
ロール、その他の設定を再作成します。この機能により、
ClickHouse クラスターのアクセス制御設定を、
クラスター全体の構成の一部としてバックアップおよび復元できます。
この機能は、SQL コマンドで管理される構成に対してのみ動作します
(“SQL-driven Access Control and Account Management” と呼ばれます) 。
ClickHouse server の設定ファイル (例: users.xml) で定義されたアクセス設定は
バックアップに含まれず、この方法では復元できません。
基本構文
コマンド概要
| Command | Description | |
|---|---|---|
BACKUP | 指定したオブジェクトのバックアップを作成します | |
RESTORE | バックアップからオブジェクトを復元します | |
TABLE [db.]table_name [AS [db.]table_name_in_backup] | 特定のテーブルをバックアップまたは復元します (名前の変更可) | |
[PARTITION[S] partition_expr [,...]] | テーブルの特定のパーティションのみをバックアップまたは復元します | |
DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] | Dictionaryオブジェクトをバックアップまたは復元します | |
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 | すべて (すべてのデータベース、テーブルなど) をバックアップまたは復元します。ClickHouse バージョン 23.4 より前では、ALL は RESTORE コマンドでのみ使用可能でした。 | |
[EXCEPT {TABLES|DATABASES}...] | ALL 使用時に特定のテーブルまたはデータベースを除外します | |
[ON CLUSTER 'cluster_name'] | ClickHouse クラスター全体でバックアップまたは復元を実行します | |
TO|FROM | 方向：バックアップの宛先には TO、復元元には FROM を使用します | |
File('<path>/<filename>') | ローカルファイルシステムに保存、またはローカルファイルシステムから復元します | |
Disk('<disk_name>', '<path>/') | 設定済みディスクに保存、または設定済みディスクから復元します | |
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>') | Amazon S3 または S3-compatible ストレージに保存、またはそこから復元します | |
[SETTINGS ...] | Settings の完全な一覧は以下を参照してください | |
[ASYNC] | 操作を非同期で実行します (すぐに制御が返り、監視可能な ID が返されます) |
設定
| 設定 | 説明 | デフォルト値 |
|---|---|---|
id | バックアップまたは復元操作の ID です。指定しない場合は、ランダムに生成された UUID が使用されます。すでに同じ ID の操作が実行中の場合は、例外がスローされます。 | |
compression_method | バックアップの圧縮方式を指定します。“カラム圧縮コーデック”のセクションを参照してください | |
compression_level | バックアップの圧縮レベルを指定します | |
password | バックアップアーカイブのパスワード。ZIPアーカイブ (.zip、.zipx) でのみ使用できます。 | |
base_backup | 増分バックアップに使用するベースバックアップの宛先。例: Disk('backups', '1.zip') | |
use_same_password_for_base_backup | base backup アーカイブがクエリのパスワードを引き継ぐかどうかを指定します。 | |
structure_only | 有効にすると、実際のテーブルデータは含めず、CREATE ステートメントのみをバックアップまたは復元します。 | |
storage_policy | 復元対象のテーブルのストレージポリシー。“データストレージに複数のブロックデバイスを使用するを参照してください。RESTOREコマンドでのみ使用できます。MergeTreeファミリーのエンジンを使用するテーブルにのみ適用されます。 | |
allow_non_empty_tables | RESTORE TABLE で空でないテーブルにデータを挿入できるようにします。これにより、テーブル内の既存データとバックアップから抽出されたデータが混在します。そのため、この設定はテーブル内でデータの重複を引き起こす可能性があるため、注意して使用してください。 | 0 |
backup_restore_keeper_max_retries | BACKUP または RESTORE の処理中における [Zoo]Keeper 操作の最大再試行回数。一時的な [Zoo]Keeper 障害によって処理全体が失敗しないよう、十分に大きな値にする必要があります。 | 1000 |
backup_restore_keeper_retry_initial_backoff_ms | バックアップまたは復元中の [Zoo]Keeper 操作に対する初期バックオフタイムアウト | 100 |
backup_restore_keeper_retry_max_backoff_ms | バックアップまたは復元中の [Zoo]Keeper 操作に対する最大バックオフタイムアウト | 5000 |
backup_restore_failure_after_host_disconnected_for_seconds | BACKUP ON CLUSTER または RESTORE ON CLUSTER の実行中に、あるホストがこの時間内に ZooKeeper 上の一時的な ‘alive’ ノードを再作成できない場合、バックアップまたはリストア全体は失敗と見なされます。この値は、障害発生後にホストが ZooKeeper に再接続するのにかかり得る妥当な時間よりも長く設定する必要があります。ゼロは無制限を意味します。 | 3600 |
backup_restore_keeper_max_retries_while_initializing | BACKUP ON CLUSTER または RESTORE ON CLUSTER 操作の初期化中における [Zoo]Keeper 操作の最大再試行回数。 | 20 |
backup_restore_keeper_max_retries_while_handling_error | BACKUP ON CLUSTER または RESTORE ON CLUSTER のエラー処理中における [Zoo]Keeper 操作の最大再試行回数。 | 20 |
backup_restore_finish_timeout_after_error_sec | 現在の BACKUP ON CLUSTER または RESTORE ON CLUSTER 操作で、他のホストが ‘error’ ノードを検知して処理を停止するまで、イニシエーターが待機する時間。 | 180 |
backup_restore_keeper_value_max_size | バックアップ中の [Zoo]Keeper ノードのデータの最大サイズ | 1048576 |
backup_restore_batch_size_for_keeper_multi | バックアップまたは復元時に [Zoo]Keeper へのマルチリクエストで使用するバッチの最大サイズ | 1000 |
backup_restore_batch_size_for_keeper_multiread | バックアップまたは復元時に [Zoo]Keeper へのマルチリードリクエストで使用するバッチの最大サイズ | 10000 |
backup_restore_keeper_fault_injection_probability | バックアップまたは復元中に Keeper リクエストが失敗するおおよその確率です。有効な値は区間 [0.0f, 1.0f] です | 0 |
backup_restore_keeper_fault_injection_seed | 0 はランダムシード、それ以外は設定された値 | 0 |
backup_restore_s3_retry_attempts | Aws::Client::RetryStrategy の設定です。Aws::Client 自体が再試行を行い、0 は再試行しないことを意味します。バックアップ／復元時にのみ適用されます。 | 1000 |
max_backup_bandwidth | サーバー上の特定のバックアップに対する、1 秒あたりの最大読み取り速度 (バイト数) です。0 は無制限を意味します。 | 0 |
max_backups_io_thread_pool_size | ClickHouse は、S3 バックアップの IO 処理に Backups IO Thread pool のスレッドを使用します。max_backups_io_thread_pool_size は、このプール内のスレッド数の上限を設定します。 | 1000 |
max_backups_io_thread_pool_free_size | Backups IO Thread pool 内のアイドル状態のスレッド数が max_backup_io_thread_pool_free_size を超えると、ClickHouse はアイドル状態のスレッドが使用しているリソースを解放し、プールサイズを縮小します。必要に応じて、スレッドは再び作成されます。 | 0 |
backups_io_thread_pool_queue_size | Backups IO Thread pool にスケジュールできるジョブの最大数。現在の S3 バックアップのロジック上、このキューは無制限のままにしておくことを推奨します。注: 値 0 (デフォルト) は無制限を意味します。 | 0 |
backup_threads | BACKUP リクエストの実行に使用するスレッドの最大数。 | |
max_backup_bandwidth_for_server | サーバー上のすべてのバックアップに対する1秒あたりの最大読み取り速度 (バイト単位) です。0 は無制限を意味します。 | 0 |
shutdown_wait_backups_and_restores | true に設定すると、ClickHouse はシャットダウン前に、実行中のバックアップおよび復元が完了するまで待機します。 | 1 |
| 設定 | 説明 | デフォルト値 |
|---|---|---|
use_same_s3_credentials_for_base_backup | S3 へのベースバックアップで、クエリの認証情報を引き継ぐかどうかを指定します。S3 でのみ有効です。 | |
s3_storage_class | S3 バックアップで使用するストレージクラス。例: STANDARD |
| 設定 | 説明 | デフォルト値 | ||
|---|---|---|---|---|
azure_attempt_to_create_container | Azure Blob Storage の使用時に、指定したコンテナーが存在しない場合は作成を試みるかどうか。 | true |
管理とトラブルシューティング
id と status を返し、その id を使って
バックアップのステータスを取得できます。これは、長時間かかる
ASYNC バックアップの進行状況を確認する際に非常に便利です。以下の例は、
既存のバックアップファイルを上書きしようとしたときに発生したエラーを示しています。
system.backups テーブルに加え、すべてのバックアップおよび復元操作は、システムログテーブル
system.backup_log にも記録されます: