バックアップとリストア
コマンド概要
ClickHouseのバージョン23.4以前では、 ALL
は「RESTORE」コマンドにのみ適用されました。
背景
レプリケーションはハードウェアの故障からの保護を提供しますが、人為的エラーを防ぐことはできません。データの誤削除、誤ったテーブルの削除、間違ったクラスターのテーブルの削除、データ処理の誤りやデータ損失を引き起こすソフトウェアバグなどが含まれます。多くのケースで、これらのミスは全てのレプリカに影響を与えます。ClickHouseには、ある種のミスを防ぐための組み込みの安全対策があります - たとえば、デフォルトで50GBを超えるデータを持つMergeTreeのようなエンジンでテーブルを簡単に削除することはできません。しかし、これらの安全対策はすべての可能なケースをカバーしているわけではなく、回避されることがあります。
人為的エラーの可能性を効果的に軽減するために、データのバックアップとリストアの戦略を前もって慎重に準備する必要があります。
各企業には異なるリソースとビジネス要件があるため、すべての状況に適したClickHouseのバックアップとリストアの普遍的なソリューションは存在しません。1ギガバイトのデータで機能することが、数十ペタバイトには機能しない可能性があります。利点と欠点を持つさまざまなアプローチがありますが、以下で説明します。さまざまな欠点を補うためには、一つのアプローチだけでなく、いくつかのアプローチを使用することをお勧めします。
バックアップを取ったが、リストアを試みていない場合、実際に必要なときにリストアが正しく機能しない可能性が高いことを忘れないでください(または少なくともビジネスが許容できるよりも長くかかります)。したがって、どのバックアップアプローチを選択するにせよ、リストアプロセスも自動化し、定期的に予備のClickHouseクラスターで練習してください。
ローカルディスクへのバックアップ
バックアップ先の設定
以下の例では、Disk('backups', '1.zip')
のようにバックアップ先が指定されています。バックアップ先を準備するには、/etc/clickhouse-server/config.d/backup_disk.xml
にファイルを追加してバックアップ先を指定します。たとえば、このファイルでは、backups
という名前のディスクを定義し、その後backups > allowed_diskリストにそのディスクを追加します。
パラメータ
バックアップはフルまたはインクリメンタルで、テーブル(マテリアライズドビュー、プロジェクション、ディクショナリを含む)やデータベースを含めることができます。バックアップは同期(デフォルト)または非同期に行うことができます。圧縮も可能です。バックアップはファイルにパスワード保護を適用することができます。
BACKUPおよびRESTOREステートメントは、DATABASEおよびTABLE名のリスト、宛先(またはソース)、オプションおよび設定を受け取ります:
- バックアップの宛先、またはリストアのソース。この設定は前に定義したディスクに基づいています。例えば、
Disk('backups', 'filename.zip')
- ASYNC: 非同期でバックアップまたはリストア
- PARTITIONS: リストアするパーティションのリスト
- SETTINGS:
id
: バックアップまたはリストア操作の識別子。設定されていないか空である場合は、ランダムに生成されたUUIDが使用されます。非空の文字列として明示的に設定されている場合は、毎回異なる必要があります。このid
は、特定のバックアップまたはリストア操作に関連するsystem.backups
テーブル内の行を見つけるために使用されます。compression_method
およびcompression_level- ディスク上のファイルの
password
base_backup
: このソースの前のバックアップの宛先。たとえば、Disk('backups', '1.zip')
use_same_s3_credentials_for_base_backup
: S3への基本バックアップがクエリから資格情報を引き継ぐかどうか。S3
でのみ機能します。use_same_password_for_base_backup
: 基本バックアップアーカイブがクエリからパスワードを引き継ぐかどうか。structure_only
: 有効な場合、テーブルのデータなしでCREATEステートメントのみをバックアップまたはリストアすることを許可しますstorage_policy
: リストアされるテーブルのストレージポリシー。詳細はMultiple Block Devices for Data Storageを使用するを参照してください。この設定はRESTORE
コマンドにのみ適用されます。指定されたストレージポリシーは、MergeTree
ファミリーのエンジンを持つテーブルにのみ適用されます。s3_storage_class
: S3バックアップに使用されるストレージクラス。たとえば、STANDARD
azure_attempt_to_create_container
: Azure Blob Storageを使用しているときに、指定されたコンテナが存在しない場合に作成を試みるかどうか。デフォルト: true。- core settingsもここで使用することができます。
使用例
テーブルをバックアップしてリストアします:
対応するリストア:
上記のRESTOREは、test.table
にデータが含まれている場合は失敗します。RESTOREをテストするにはテーブルを削除する必要があるか、allow_non_empty_tables=true
設定を使用する必要があります:
テーブルは新しい名前でリストアまたはバックアップすることができます:
インクリメンタルバックアップ
インクリメンタルバックアップは、base_backup
を指定することで取得できます。
インクリメンタルバックアップは基本バックアップに依存しています。インクリメンタルバックアップからリストアするには、基本バックアップを保持する必要があります。
新しいデータをインクリメンタルに保存します。base_backup
設定により、以前のバックアップからのデータがDisk('backups', 'd.zip')
に保存され、Disk('backups', 'incremental-a.zip')
に保存されます:
インクリメンタルバックアップと基本バックアップからすべてのデータを新しいテーブルtest.table2
にリストアします:
バックアップにパスワードを設定する
ディスクに書き込まれたバックアップファイルにパスワードを適用できます:
リストア:
圧縮設定
圧縮方法やレベルを指定したい場合:
特定のパーティションをリストアする
テーブルに関連する特定のパーティションをリストアする必要がある場合、それらを指定することができます。バックアップからパーティション1と4をリストアするには:
tarアーカイブとしてのバックアップ
バックアップはtarアーカイブとして保存することもできます。機能はzipと同じですが、パスワードはサポートされていません。
tarとしてバックアップを作成:
対応するリストア:
圧縮方法を変更するには、バックアップ名に適切なファイルサフィックスを追加します。つまり、gzipを使用してtarアーカイブを圧縮する場合:
サポートされている圧縮ファイルサフィックスは、tar.gz
、.tgz
、tar.bz2
、tar.lzma
、.tar.zst
、.tzst
、および.tar.xz
です。
バックアップの状態を確認する
バックアップコマンドはid
とstatus
を返し、そのid
を使用してバックアップの状態を取得できます。これは、長時間の非同期バックアップの進行状況を確認するのに非常に便利です。以下の例は、既存のバックアップファイルを上書きしようとした際の失敗を示しています:
system.backups
テーブルに加えて、すべてのバックアップおよびリストア操作は、システムログテーブルbackup_logで追跡されます:
BACKUP/RESTOREをS3エンドポイントで使用するための構成
S3バケットにバックアップを保存するには、次の3つの情報が必要です:
- S3エンドポイント、
例:
https://mars-doc-test.s3.amazonaws.com/backup-S3/
- アクセスキーID、
例:
ABC123
- シークレットアクセストークン、
例:
Abc+123
S3バケットの作成はUse S3 Object Storage as a ClickHouse diskで説明されています。ポリシーを保存した後にこのドキュメントに戻ってきてください。ClickHouseをS3バケットで使用するように設定する必要はありません。
バックアップの宛先は次のように指定されます:
ベース(初期)バックアップを作成する
インクリメンタルバックアップは、_ベース_バックアップから開始する必要があります。この例は後でベースバックアップとして使用されます。S3宛先の最初のパラメータはS3エンドポイントで、次にこのバックアップに使用するバケット内のディレクトリが続きます。この例では、ディレクトリはmy_backup
と呼ばれています。
さらにデータを追加
インクリメンタルバックアップは、基本バックアップとバックアップされるテーブルの現在のコンテンツとの違いで構成されます。インクリメンタルバックアップを取る前にデータを追加します:
インクリメンタルバックアップを取る
このバックアップコマンドは基本バックアップと似ていますが、SETTINGS base_backup
と基本バックアップの場所を追加します。インクリメンタルバックアップの宛先は基本バックアップと同じディレクトリではなく、同じエンドポイント内の異なるターゲットディレクトリです。基本バックアップはmy_backup
にあり、インクリメンタルはmy_incremental
に書き込まれます:
インクリメンタルバックアップからリストアする
このコマンドはインクリメンタルバックアップを新しいテーブルdata3
にリストアします。インクリメンタルバックアップがリストアされるとき、基本バックアップも含まれていることに注意してください。リストア時はインクリメンタルバックアップのみを指定します:
カウントを検証する
元のテーブルdata
には、1,000行のデータと100行のデータが2回挿入された合計1,100行があります。リストアされたテーブルに1,100行があることを確認します:
内容を検証する
元のテーブルdata
とリストアされたテーブルdata3
の内容を比較します:
S3ディスクを使用したBACKUP/RESTORE
ClickHouseストレージ設定でS3ディスクを構成することで、S3にBACKUP
/RESTORE
することも可能です。次のようにディスクを構成します。/etc/clickhouse-server/config.d
にファイルを追加します:
そして、通常通りにBACKUP
/RESTORE
を実行します:
ただし、以下の点に注意してください:
- このディスクは
MergeTree
自体には使用すべきではなく、BACKUP
/RESTORE
のみに使用すべきです。 - テーブルがS3ストレージにサポートされ、ディスクの種類が異なる場合、
CopyObject
コールを使用してパーツを宛先バケットにコピーするのではなく、ダウンロードとアップロードが行われ、非常に非効率的です。このユースケースには、BACKUP ... TO S3(<endpoint>)
構文の使用をお勧めします。
名前付きコレクションの使用
名前付きコレクションはBACKUP/RESTORE
パラメータに使用できます。例についてはこちらを参照してください。
代替手段
ClickHouseはディスク上にデータを保存し、ディスクのバックアップには多くの方法があります。以下は、過去に使用されてきた代替手段のいくつかであり、あなたの環境に適合する可能性があります。
他の場所にソースデータを複製する
多くの場合、ClickHouseに取り込まれるデータは、Apache Kafkaのような永続的キューを通じて提供されます。この場合、ClickHouseに書き込まれている間に同じデータストリームを読み取る追加のサブスクライバセットを構成し、どこかのコールドストレージに保存することが可能です。ほとんどの企業には、オブジェクトストアやHDFSのような分散ファイルシステムのようないくつかのデフォルトの推奨コールドストレージがあります。
ファイルシステムスナップショット
一部のローカルファイルシステムはスナップショット機能を提供します(たとえば、ZFS)。しかし、ライブクエリの提供には最適な選択肢ではないかもしれません。可能な解決策は、この種のファイルシステムで追加のレプリカを作成し、SELECT
クエリで使用される分散テーブルから除外することです。そのようなレプリカのスナップショットは、データを変更する任意のクエリからはアクセスできなくなります。ボーナスとして、これらのレプリカは、サーバーあたりにより多くのディスクが接続された特別なハードウェア構成を持つ場合があり、コスト効率が良いです。
データボリュームが小さい場合は、リモートテーブルへの単純なINSERT INTO ... SELECT ...
も機能するかもしれません。
パーツの操作
ClickHouseは、ALTER TABLE ... FREEZE PARTITION ...
クエリを使用して、テーブルパーティションのローカルコピーを作成することを許可します。これは、/var/lib/clickhouse/shadow/
フォルダーへのハードリンクを使用して実装されるため、古いデータに対して追加のディスクスペースを消費することは通常ありません。作成されたファイルのコピーはClickHouseサーバーによって管理されないため、そこに残しておくことができます。この方法は追加の外部システムを必要としないシンプルなバックアップが得られますが、ハードウェアの問題に対しては依然として影響を受ける可能性があります。そのため、それらを別の場所にリモートコピーしてからローカルコピーを削除する方が良いです。分散ファイルシステムやオブジェクトストアは依然として良い選択肢ですが、十分な容量のある通常の接続ファイルサーバーでも機能するかもしれません(この場合、転送はネットワークファイルシステムを介して行われるか、あるいはrsyncを使うかもしれません)。
データは、ALTER TABLE ... ATTACH PARTITION ...
を使用してバックアップからリストアすることができます。
パーティション操作に関連するクエリの詳細については、ALTERドキュメントを参照してください。
このアプローチを自動化するためのサードパーティ製ツールも利用可能です:clickhouse-backup。
同時バックアップ/リストアを禁止するための設定
同時のバックアップ/リストアを禁止するには、それぞれ以下の設定を使用できます。
デフォルト値は両方ともtrueであり、デフォルトでは同時のバックアップ/リストアが許可されています。 これらの設定がクラスターでfalseの場合、同時に1つのバックアップ/リストアの実行が許可されます。
AzureBlobStorageエンドポイントを使用してバックアップ/リストアを構成する
AzureBlobStorageコンテナにバックアップを書くには、次の情報が必要です:
- AzureBlobStorageエンドポイント接続文字列 / url、
- コンテナ、
- パス、
- アカウント名(urlが指定されている場合)
- アカウントキー(urlが指定されている場合)
バックアップの宛先は次のように指定されます:
システムテーブルのバックアップ
システムテーブルもバックアップおよびリストアのワークフローに含めることができますが、その含有は特定のユースケースに依存します。
ログテーブルのバックアップ
履歴データを保存するシステムテーブル(例えば、query_log
、part_log
などの_logサフィックスを持つテーブル)は、他のテーブルと同様にバックアップおよびリストアできます。ユースケースが履歴データの分析に依存する場合(たとえば、query_logを使用してクエリのパフォーマンスを追跡または問題をデバッグする場合)、これらのテーブルをバックアップ戦略に含めることが推奨されます。しかし、これらのテーブルの履歴データが必要ない場合は、バックアップストレージスペースを節約するために除外できます。
アクセス管理テーブルのバックアップ
ユーザー、ロール、row_policies、settings_profiles、およびクォータなど、アクセス管理に関連するシステムテーブルは、バックアップおよびリストア操作中に特別な扱いを受けます。これらのテーブルがバックアップに含まれると、その内容はアクセスエンティティの作成および構成のための同等のSQLステートメントをカプセル化した特別なaccessXX.txt
ファイルにエクスポートされます。リストア時には、リストアプロセスがこれらのファイルを解釈し、SQLコマンドを再適用してユーザー、ロール、および他の構成を再作成します。
この機能により、ClickHouseクラスターのアクセス制御設定をバックアップおよびリストアし、クラスター全体のセットアップの一部として保管できます。
注意:この機能はSQLコマンドを介して管理される構成("SQL駆動のアクセス制御とアカウント管理"と呼ばれます)に対してのみ機能します。ClickHouseサーバー構成ファイル(例えば、users.xml
)に定義されたアクセス構成はバックアップに含まれず、この方法でリストアすることはできません。