CockroachDB: The Definitive Guide, 2nd Edition

第12章 バックアップとディザスタリカバリ バックアップと災害復旧

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

高可用性は、ほとんどの最新アプリケーションにとって唯一の選択肢である。前の章では、最も極端な状況を除き、あらゆる状況に耐えられる分散CockroachDBクラスタを構成する方法を見てきた。

とはいえ、最もレジリエンスの高いレプリケーション方式を採用したクラスタであっても、回復できない事態に遭遇する可能性はある。例えばサイバー攻撃の結果、複数のデータセンターが連携して障害を起こし、クラスタ内の全データが回復不能になる可能性がある。

また、クラスタインフラは無傷のままでも、その中のデータが破損してしまう状況もある。例えば、データベース管理者（DBA）が開発システムで作業しているつもりで本番データをうっかり変更してしまったり、ランサムウェア攻撃で全データを消去しようとしたり、アプリケーションのバグが時間の経過とともにデータを微妙に破損させたりする可能性がある。

CockroachDBには、（主にAS OF SYSTEM TIME 節に基づいて）データ破損からの復旧を支援する多くの機能があるが、バックアップはデータベース内のデータの損失や破損に対する究極の保険となる。

バックアップはまた、比較的遠い過去のデータ状態を復元する能力も提供する。これは、規制の点から、あるいはデータが論理的に破損し、ある時点からの「やり直し」が必要になった場合に必要となる。

バックアップと高可用性の比較

CockroachDBのような分散データベース（）では、バックアップと高可用性のパターンが、OracleやSQL Serverのようなモノリシックデータベースとは大きく異なる。Oracleのようなモノリシック・データベースでは、レプリケーションとバックアップはどちらもライト・アヘッド・トランザクション・ログ（OracleではREDOログと呼びます）に基づいている。このログは、耐久性のあるコミットレコードの最初の受信者であり、（高可用性を目的とした）スタンバイデータベースへのレプリケーションのソースとして、また、合計で障害が発生した場合に静的バックアップからデータベースを「ロールフォワード」するためにも使用される。

CockroachDBでは、ラフト・ログはモノリシック・データベースのトランザクション・ログと、論理的には同じ機能を果たすが、リカバリのベースとなる単一のログは存在せず、その結果、手順は少し異なる。要するに、CockroachDBにおけるHAとディザスタリカバリの支配的なパターンには以下が含まれる：

• データの冗長性分散コピーを使用して、予測可能なインフラ障害が発生した場合でも可用性を維持する。

• データベースのバックアップを定期的に取り、レプリケーションを圧迫するような災害から守る。

これら2つのテクニックを組み合わせることで、予見可能なインフラ障害に対する高可用性を提供するとともに、インフラ全体が故障した場合やデータベースが論理的に破損した場合のフォールバック・ソリューションも提供する。

バックアップ

CockroachDBのバックアップは、、災害やデータ破損の問題が発生した場合に迅速に復元できるデータのオフラインコピーを作成する主要な手段である。

バックアップはクラスタ全体、または個々のデータベースやテーブルに対して行うことができる。バックアップには、データの現在の状態だけでなく、バックアップ時にデータベースが知っているすべての履歴を含めることができる（デフォルトでは、以下の方法で設定された4時間のウィンドウのデータを含む）。 ...