メインコンテンツまでスキップ
メインコンテンツまでスキップ

バックアップと復元

コマンドの概要​

ALL

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ステートメントは、データベースおよびテーブル名のリスト、バックアップまたは復元のための宛先（またはソース）、オプションおよび設定を受け取ります。

  • バックアップの宛先、または復元のソース。これは、前述のディスクに基付くものです。たとえば、Disk('backups', 'filename.zip')
  • ASYNC: 非同期バックアップまたは復元
  • PARTITIONS: 復元するパーティションのリスト
  • SETTINGS:
    • id: バックアップまたは復元操作のid、手動で指定しない場合はランダムに生成されたUUIDが使用されます。同じidで実行中の操作がある場合は例外がスローされます。
    • compression_methodおよびcompression_level
    • ディスク上のファイルのためのpassword
    • base_backup: このソースの前のバックアップの宛先。たとえば、Disk('backups', '1.zip')
    • use_same_s3_credentials_for_base_backup: base_backupをS3に対して、クエリから認証情報を引き継ぐかどうか。S3でのみ機能します。
    • use_same_password_for_base_backup: base_backupアーカイブがクエリからパスワードを引き継ぐべきかどうか。
    • structure_only: 有効にすると、テーブルのデータなしでCREATEステートメントのみをバックアップまたは復元できるようになります。
    • storage_policy: 復元されるテーブルのストレージポリシー。データストレージに複数のブロックデバイスを使用するを参照してください。この設定は、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バックアップに依存しています。増分バックアップから復元するためには、baseバックアップが常に利用可能でなければなりません。

新しいデータを増分的に保存します。設定base_backupにより、前のバックアップ以来のデータがDisk('backups', 'd.zip')からDisk('backups', 'incremental-a.zip')に保存されます：

増分バックアップとbase_backupからすべてのデータを新しいテーブル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を使用してバックアップの状態を取得することができます。これは長いASYNCバックアップの進捗を確認するのに非常に便利です。以下の例は、既存のバックアップファイルを上書きしようとした際に発生した失敗を示しています：

system.backupsテーブルに加え、すべてのバックアップおよび復元操作はシステムログテーブルbackup_logにも追跡されています：

S3エンドポイントを使用したBACKUP/RESTOREの設定​

S3バケットにバックアップを書き込むには、次の3つの情報が必要です。

  • S3エンドポイント、 たとえばhttps://mars-doc-test.s3.amazonaws.com/backup-S3/
  • アクセスキーID、 たとえばABC123
  • シークレットアクセスキー、 たとえばAbc+123
注記

S3バケットの作成はClickHouseディスクとしてS3オブジェクトストレージを使用で説明されています。ポリシーを保存した後は、このドキュメントに戻ってきてください。ClickHouseをS3バケットで使用するために設定する必要はありません。

バックアップの宛先は次のように指定されます：

ベース（初期）バックアップを作成する​

増分バックアップには、開始元となる_ベース_バックアップが必要です。この例は後でベースバックアップとして使用されます。S3宛先の最初のパラメータはS3エンドポイントで、その後にこのバックアップに使用するバケット内のディレクトリ名が続きます。この例では、ディレクトリはmy_backupと呼ばれます。

さらにデータを追加​

増分バックアップは、ベースバックアップとバックアップされているテーブルの現在の内容との間の違いで構成されます。増分バックアップを取る前に、さらなるデータを追加します：

増分バックアップを取得する​

このバックアップコマンドは、ベースバックアップに似ていますが、SETTINGS base_backupとベースバックアップの場所が追加されます。増分バックアップの宛先は、ベースバックアップとは異なるディレクトリであることに注意してください。ベースバックアップはmy_backupにあり、増分バックアップはmy_incrementalに書き込まれます：

増分バックアップから復元する​

このコマンドは、増分バックアップを新しいテーブルdata3に復元します。増分バックアップを復元すると、ベースバックアップも含まれます。復元の際には、増分バックアップのみを指定します：

カウントを確認する​

元のテーブルdataには、1,000行の挿入と100行の挿入があり、合計で1,100行です。復元されたテーブルに1,100行があるか確認します：

内容を確認する​

元のテーブルdataと復元されたテーブルdata3の内容を比較します：

S3ディスクを使用したBACKUP/RESTORE​

ClickHouseストレージ構成でS3ディスクを設定することで、BACKUP/RESTOREをS3に対して行うことも可能です。次のファイルを/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エンドポイントを使用したBACKUP/RESTOREの設定​

AzureBlobStorageコンテナにバックアップを書き込むには、次の情報が必要です：

  • AzureBlobStorageエンドポイント接続文字列/URL、
  • コンテナ、
  • パス、
  • アカウント名（URLが指定される場合）
  • アカウントキー（URLが指定される場合）

バックアップの宛先は次のように指定されます：

システムテーブルのバックアップ​

システムテーブルもバックアップおよび復元のワークフローに含めることができますが、含めるかどうかは特定の使用例によります。

ログテーブルのバックアップ​

query_logやpart_logのように歴史データを保存するシステムテーブルは、他のテーブルと同様にバックアップおよび復元できます。使用例が、履歴データの分析に依存する場合（たとえば、クエリのパフォーマンスを追跡したり、問題をデバッグするためにquery_logを使用する場合）、これらのテーブルをバックアップ戦略に含めることをお勧めします。ただし、これらのテーブルの履歴データが必要ない場合、バックアップストレージスペースを節約するためにそれらを除外できます。

アクセス管理テーブルのバックアップ​

ユーザー、ロール、行ポリシー、設定プロファイル、クォータなど、アクセス管理に関連するシステムテーブルは、バックアップおよび復元操作中に特別な扱いを受けます。これらのテーブルがバックアップに含まれると、その内容は特別なaccessXX.txtファイルにエクスポートされ、アクセスエンティティの作成および構成のための同等のSQL文をカプセル化します。復元時には、復元プロセスがこれらのファイルを解釈し、SQLコマンドを再適用してユーザー、ロール、その他の構成を再作成します。

この機能により、ClickHouseクラスターのアクセス制御構成をクラスター全体のセットアップの一部としてバックアップおよび復元できます。

注意: この機能は、SQLコマンドを通じて管理される構成にのみ機能します（"SQL主導のアクセス制御およびアカウント管理"を参照）。ClickHouseサーバー設定ファイル（例:users.xml）で定義されたアクセス構成はバックアップに含まれず、この方法で復元することはできません。