このセクションでは、ClickHouse におけるバックアップと復元の概要を説明します。各バックアップ方法のより 詳細な説明については、サイドバーにある各方法のページを参照してください。
はじめに
レプリケーション はハードウェア障害に対する保護を提供しますが、人的ミスまでは防げません。たとえば、データの誤削除、誤った テーブルの削除、誤ったクラスター上のテーブルの削除、さらに不正な データ処理やデータ破損を引き起こすソフトウェアバグなどです。 多くの場合、このようなミスはすべてのレプリカに影響します。ClickHouse には一部の種類のミスを防ぐための 組み込みの安全策があります。たとえば、デフォルト では、50 Gb を超えるデータを含むMergeTree ファミリーのエンジンを使用するテーブルを
そのまま削除することはできません。とはいえ、こうした安全策ですべてのケースを
カバーできるわけではなく、問題が発生する可能性は残ります。
想定される人的ミスを効果的に軽減するには、
データのバックアップと復元のための戦略をあらかじめ慎重に準備しておく必要があります。
利用できるリソースや業務要件は会社ごとに異なるため、
あらゆる状況に適した ClickHouse のバックアップと復元の万能な解決策は
存在しません。1 ギガバイトのデータに有効な方法が、数十
PB のデータには通用しない可能性があります。考えられるアプローチにはそれぞれ長所と短所が
あり、このドキュメントのこのセクションで紹介しています。さまざまな
欠点を補うために、1 つだけでなく複数のアプローチを併用することをお勧めします。
何かをバックアップしても、一度も復元を試したことがない場合、
実際に必要になったときに復元が正しく動作しない可能性があります (少なくとも、
業務で許容できるよりも長い時間がかかるでしょう) 。したがって、どのバックアップ
アプローチを選ぶ場合でも、復元プロセスも自動化し、定期的に予備の
ClickHouse クラスターで復元手順を検証してください。
バックアップは次のように分類できます。
- フルまたは増分
- 同期または非同期
- 同時実行または非同時実行
- 圧縮または非圧縮
- named collections を使用
- パスワードで保護
- システムテーブル、ログテーブル、または アクセス管理テーブル のバックアップを取得
バックアップの種類
バックアップには、フルバックアップと増分バックアップがあります。フルバックアップはデータの完全なコピーであり、増分バックアップは直近のフルバックアップ以降に変更されたデータの差分です。 フルバックアップには、単純で独立性が高く (ほかのバックアップに依存せず) 、信頼性の高い復旧方法であるという利点があります。ただし、完了までに時間がかかる場合があり、多くの容量を消費することもあります。一方、増分バックアップは時間と容量の両面でより効率的ですが、データを復元するには、関連するバックアップがすべて利用可能である必要があります。 要件に応じて、次の方法を検討できます。- フルバックアップ: 小規模なデータベースや重要なデータ向け。
- 増分バックアップ: 大規模なデータベース向け、またはバックアップを高頻度かつコスト効率よく実行する必要がある場合。
- 両方: たとえば、毎週フルバックアップを実行し、毎日増分バックアップを実行します。
同期バックアップと非同期バックアップ
BACKUP コマンドと RESTORE コマンドには、ASYNC を指定することもできます。この場合、
バックアップコマンドはすぐに制御を返し、バックアップ処理はバックグラウンドで実行されます。
コマンドに ASYNC を指定しない場合、バックアップ処理は同期的に実行され、
バックアップが完了するまでコマンドは待機します。
同時実行バックアップと非同時実行バックアップ
デフォルトでは、ClickHouse はバックアップと復元の同時実行を許可しています。つまり、 複数のバックアップまたは復元操作を同時に開始できます。ただし、この動作を 無効にできるサーバーレベルの設定もあります。これらの設定を false にすると、 クラスター上で同時に実行できるバックアップまたは復元操作は 1 つだけになります。 これにより、リソースの競合や、操作間で発生しうる競合を回避しやすくなります。 バックアップ/復元の同時実行を無効にするには、それぞれ次の設定を使用できます:圧縮バックアップと非圧縮バックアップ
ClickHouse のバックアップでは、compression_method および compression_level 設定により圧縮を利用できます。
バックアップの作成時には、以下を指定できます。
named collections の使用
named collections を使用すると、バックアップ/復元操作で再利用できるキー・バリューの組 (S3 の認証情報、エンドポイント、設定など) を保存できます。 これにより、次のことが可能になります。- 管理者アクセス権のないユーザーに認証情報を見せない
- 複雑な構成を一元管理して、コマンドを簡素化する
- 操作間の一貫性を保つ
- クエリログに認証情報が露出するのを防ぐ
システム、ログ、またはアクセス管理テーブルのバックアップ
システムテーブルもバックアップおよび復元のワークフローに含めることができますが、 含めるかどうかは、具体的なユースケースによって異なります。_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) で定義されたアクセス設定は
バックアップに含まれず、この方法では復元できません。
基本構文
コマンド概要
上記の各コマンドの詳細は以下のとおりです。データを含めずにテーブルをバックアップする
EXCEPT DATA FROM {TABLE|TABLES} を指定すると、テーブルの行を含めず、定義だけをバックアップに保存します。
materialized view のターゲットテーブルなど、復元後に内容を再生成できるテーブルに便利です。
この句で指定するのは BACKUP が書き込む内容であり、そのバックアップに対して RESTORE ができることは変わりません。
RESTORE で再作成できるテーブルなら、行を含まない定義から空のテーブルが復元されます。一方、この句を指定しても、
もともと復元できないテーブルが復元可能になるわけではありません。バックアップ内の定義からテーブルを再作成できるかどうかは
エンジンによって異なり、再作成を一切認めないエンジンもあります。詳しくは
RESTORE で再作成できないエンジンを参照してください。
この句の適用範囲は、句を記述した要素に限られます。
DATABASEまたはALL要素に指定する場合は、その要素がバックアップするテーブルを指定できます。
table、dictionary、view、database、all という名前のテーブルまたはデータベースはバッククォートで囲んでください。カンマの後に
バッククォートで囲まれていない名前があると、次の要素の開始として解釈されます。
- 単一オブジェクトを対象とする要素 (
TABLE、DICTIONARY、VIEW、TEMPORARY TABLE) では、その要素が指定するオブジェクトだけが 対象となるため、句にはそのオブジェクトのみを指定してください。各テーブルに対して個別の要素と 句を用意してください。
EXCEPT DATA FROM 句の両方で指定されている場合、
そのデータはバックアップされます。テーブルを指定する要素は、そのデータもバックアップ対象に含めるためです。これは EXCEPT TABLES と同じ動作です。
より広い範囲を指定する要素で除外されていても、明示的に指定されたテーブルはバックアップされます。
materialized view の内部テーブル (または TimeSeries テーブルの内部テーブル) のデータは、
外側のオブジェクトの名前を指定して除外します。この句に内部テーブルの名前を指定することはできません。
EXCEPT DATA FROM {TABLE|TABLES} は BACKUP でのみ有効です。RESTORE では、何もしない操作として扱われるのではなく、
エラーになります。
RESTORE で再作成できないエンジン
一部のエンジンは、EXCEPT DATA FROM {TABLE|TABLES} の有無にかかわらず、RESTORE で再作成することがまったくできません。
こうしたテーブルでも、この句によってバックアップのサイズは制御されますが、テーブルが空の状態で復元されるわけではありません。
RESTORE がテーブルの作成を拒否するため、何も復元されないのです。
特に注意が必要なのは、スタンドアロンの MaterializedPostgreSQL テーブルです。このテーブルは作成された時点で、稼働中の PostgreSQL ソースからのレプリケーションを開始してしまい、
バックアップのスナップショットと現在のリモートの状態が混在することになります。そのため
RESTORE は、テーブルが作成される前のストレージファクトリーの段階で、NOT_IMPLEMENTED としてこれを拒否します。これはエンジン固有の
性質であり、通常のフルバックアップでも同様です。
サポートされている手順は、入れ子テーブルの構造 (_sign カラムと _version カラムを含む) に合わせて事前に作成しておいた
ReplacingMergeTree に、別の名前で復元するというものです。
MaterializedPostgreSQL エンジンが使用されていますが、ここでは意図的に通常の ReplacingMergeTree として復元するため、allow_different_table_def が必要です。
EXCEPT DATA FROM TABLE を指定しない場合は、同じ RESTORE で行も復元されます。
設定
共通のバックアップ/復元設定
S3固有の設定
Azure固有の設定
管理とトラブルシューティング
backup コマンドはid と status を返し、その id を使って
バックアップのステータスを取得できます。これは、長時間かかる
ASYNC バックアップの進行状況を確認する際に非常に便利です。以下の例は、
既存のバックアップファイルを上書きしようとしたときに発生したエラーを示しています。
system.backups テーブルに加え、すべてのバックアップおよび復元操作は、システムログテーブル
system.backup_log にも記録されます: