ScalarDL でデータをバックアップおよび復元する方法に関するガイド
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
ScalarDL は、非トランザクション (おそらくトランザクション) データベース上で非侵襲的にトランザクション機能を提供する ScalarDB を使用するため、 トランザクション的に一貫した方法でデータベースをバックアップおよび復元するには、特別な注意を払う必要があります。 このガイドでは、トランザクション的に一貫性のある ScalarDL バックアップを作成および復元する方法を説明します。
まず、ScalarDL Ledger のデータベースをバックアップおよび復元する方法について説明します。 次に、Auditor が使用されるケースをカバーするためにプロセスがどのように拡張されるかについて説明します。
Ledger データベースのバックアップを作成する
トランザクション データベースの場合
JDBC データベース
JDBCデータベースはお好みの方法でバックアップが可能です。
JDBC データベース上の ScalarDL でのバックアップの要件の 1 つは、すべての ScalarDL 管理テーブル (コーディネーター テーブルと scalardb テーブルを含む) のバックアップがトランザクション的に一貫性があるか、トランザクション的に一貫性のある状態に自動的にリカバリ可能である必要があることです。
つまり、単一トランザクションですべてのテーブルをダンプして、一貫性のあるスナップショットを作成する必要があります。 たとえば、MySQL では mysqldump コマンドを --single-transaction オプションとともに使用し、PostgreSQL では pg_dump コマンドを使用してこれを実現できます。
または、Amazon RDS (Relational Database Service) または Azure Database for MySQL/PostgreSQL を使用している場合は、要件を満たす自動バックアップ機能を使用して、バックアップ保持期間内の任意の時点に復 元できます。
非トランザクション データベースの場合
トランザクションの一貫性のあるバックアップを作成するための基本戦略
トランザクションの一貫性のあるバックアップを作成する 1 つの方法は、ScalarDL クラスターに未処理のトランザクションがない間にバックアップを作成することです。 基礎となるデータベースがポイントインタイム スナップショット/バックアップ メカニズムをサポートしている場合は、その期間中にスナップショットを取得できます。 基礎となるデータベースがポイントインタイム復元/回復メカニズムをサポートしている場合は、復元ポイントを期間内の特定の時刻 (できれば中間時刻) に設定できます。
これを簡単に実現するために、ScalarDL は一時停止 API を公開して、ScalarDL に未処理のトランザクションを排出させ、新しいトランザクションの受け入れを停止させます。 ま た、scalar-admin という単純なクライアント プログラムも提供しており、ScalarDL クラスターに対して一時停止リクエスト (および一時停止解除リクエスト) を行い、一時停止期間を取得します。
ポイントインタイム復元/回復メカニズムを使用する場合は、NTP などのクロック同期を使用して、ノード (ScalarDL ノードと一時停止を要求するクライアント ノード) 間のクロック ドリフトを最小限に抑えることをお勧めします。 そうしないと、一時停止期間として取得される時間が実際に一時停止が行われた時間と大きく異なる可能性があり、進行中のトランザクションが存在する時点に復元される可能性があります。 また、クロック同期ではノード間のクロックを完全に同期させることはできないため、十分な時間 (10 秒など) を一時停止し、一時停止期間の中間時間を使用することをお勧めします。
トランザクション整合性のあるバックアップを作成するデータベース固有の方法
カサンドラ
Cassandra にはレプリケーション メカニズムが組み込まれているため、トランザクション的に一貫性のあるバックアップを常に作成する必要はありません。 たとえば、レプリケーションが 3 に設定されており、クラスター内の 1 つのノードのデータのみが失われた場合、ノードは通常の (トランザクション的に一貫性のない) スナップショットと、 修復機構。 ただし、クラスターのノードのクォーラムがデータを失った場合、クラスターを特定のトランザクション整合性のあるポイントに復元するには、トランザクション整合性のあるバックアップが必要です。
トランザクション的に一貫性のあるクラスター全体のバックアップを作成する場合は、基本戦略 セクションに従ってください。または Cassandra クラスターを停止し、クラスターのすべてのノードのコピーを取得して、クラスターを開始します。
間違いを避けるために、Cassy を使用することをお勧めします。
Cassy は scalar-admin とも統合されているため、Cassandra クラスターのアプリケーションに一時停止リクエストを発行できます。
詳細については、ドキュメント を参照してください。
Cosmos DB
ポイントインタイム復元 (PITR) 機能を使用するには、継続バックアップ ポリシーが有効になっている Cosmos DB アカウントを作成する必要があります。 バックアップは有効になった後も継続的に 作成されます。 トランザクション整合性のある復元ポイントを指定するには、基本戦略 の説明に従って、ScalarDL サービスを一時停止してください。
DynamoDB
DynamoDB テーブルのポイントインタイム リカバリ (PITR) 機能を有効にする必要があります。 ScalarDL Schema Loader を使用する場合、デフォルトで PITR が有効になります。 トランザクション整合性のある復元ポイントを指定するには、基本戦略 の説明に従って、ScalarDL サービスを一時停止してください。
Ledger データベースのバックアップを復元する
バックアップを復元するには、バックアップの復元 セクションに従う必要があります。 データベースのバックアップを復元する前に ScalarDL Ledger サービスを停止し、バックアップの復元後に ScalarDL Ledger サービスを開始する必要があります。
Auditor データベースのバックアップの作成/復元
Auditor を使用する場合は、Ledger データベースに加えて Auditor データベースのバックアップも作成する必要があります。 Ledger データベースと Auditor データベースのバックアップの一貫性を保つには、Ledger と Auditor にトランザクション データベースを使用するか非トランザクション データベースを使用するかに関係なく、Ledger クラスターを常に一時停止する必要があります。
バックアップを作成する手順は次のとおりです。
- Ledgerクラスターを一時停止する
- Ledger データベースのバックアップを作成します (上記のとおり)
- Auditor データベースのバックアップを作成します (上記のとおり)
- Ledger クラスターの一時停止を解除します。
Ledgerが一時停止されている場合でも、Auditorは引き続きリクエストを受け入れ、そのデータを更新します(つまり、テーブルをロックします)。ただし、Ledgerの一時停止が解除されると、更新されたデータは遅延回復されることに注意してください。 遅延リカバリのオーバーヘッドを軽減するには、ScalarDL に対するリクエストがないときにバックアップを作成することを常にお勧めします。 今後はより効率的な仕組みを提供していく予定です。
バックアップを復元するときは、必ず同じ一時停止期間内に作成されたバックアップを使用してください。 データベースのバックアップを復元する前に ScalarDL Ledger および Auditor サービスを停止し、 バックアップを復元した後に ScalarDL Ledger および Auditor サービスを開始する必要があります。