MySQL のバックアップと復元
予期しない事態が発生すると、ビジネスが影響を受ける可能性があります。ハードウェア障害、データベースの破損、ユーザーのミス、さらには悪意のある攻撃でさえ、データ損失のリスクにつながる可能性があります。データベースをバックアップすることで、何か問題が発生した場合でも、ビジネスを復旧させ、運用を継続できます。データベースが正常に稼働すれば、過去のある時点までデータベースを復元できるため、コンプライアンスと監査の要件を満たすことができます。
MySQL は、データベースをバックアップするためのオプションがいくつかあり、それぞれに異なる長所があります。ニーズに最適な方法を自由に組み合わせて選択できます。
バックアップの種類
MySQL データベースをバックアップする方法は、主に、物理バックアップと論理バックアップの 2 つがあります。物理バックアップでは実際のデータファイルがコピーされ、論理バックアップではデータを再作成できる CREATE TABLE や INSERT などのステートメントが生成されます。
物理バックアップ
物理バックアップには、ディスク上にあるすべてのファイルとディレクトリの未加工のコピーが含まれます。この種類のバックアップでは、論理バックアップと比較して RAW ファイルのコピーの方がはるかに高速であるため、大規模なデータベースに適しています。
メリット:
- 物理バックアップはシンプルで効率的です。実行するために多くのメモリや多くの CPU サイクルを必要としません
- 物理バックアップの場合、RAW ファイルを生成するために追加の作業は必要ありません。必要なことは、未加工のファイルとディレクトリをバックアップ用の場所にコピーすることだけです。
- MySQL では、データベース オブジェクトを再作成してデータをインポートする必要がないため、物理バックアップは論理バックアップよりも復元が高速です。
デメリット:
- 物理バックアップの場合は、InnoDB のテーブルスペース（共有され、テーブル .ibd ファイルに従い、通常は断片化されたスペースがあります）に加え、トランザクション ログやアンドゥーログなどを含むため、論理バックアップよりもはるかに多くの容量を使用することが大半です。
- 物理バックアップは、異なるプラットフォーム、オペレーティング システム、MySQL バージョンへ常に移せるとは限りません。
- 物理バックアップは RAW ファイルをコピーするため、それらに基盤となる破損がある場合、バックアップ ファイルにもコピーされます。
MySQL エコシステム全体で一般的な物理バックアップ ツール
論理バックアップ
論理バックアップには、MySQL が SQL または区切りテキストとして解釈できる形式でデータベースのデータが含まれています。データベースは、データベース オブジェクトを再作成してデータをインポートするために実行できる SQL ステートメントのシーケンスとして表現されます。論理バックアップは物理バックアップよりも復元にかなり時間がかかるため、小規模なデータベースに適しています。このバックアップの種類は、クラウドでのマネージド データベース サービスに移行する場合や、そこから移行する場合に役立ちます。
メリット:
- 論理バックアップは非常に柔軟です。サーバーレベル（すべてのデータベース）、データベース レベル（特定のデータベース内のすべてのテーブル）、テーブルレベル、さらには行レベル（WHERE 条件に一致するテーブル行）で、バックアップと復元オペレーションを細かく制御できます。
- 論理バックアップは、復元が簡単です。バックアップ ファイルを mysql クライアントにパイプで渡し、LOAD DATA ステートメントまたは mysqlimport コマンドを使用して、テキスト区切りファイルを読み込みます。
- 論理バックアップは別のマシンからリモートで実行できます。これにより、ネットワーク全体のデータベースをバックアップして復元できます。これは、ユーザーが仮想マシンに直接アクセスできない Google Cloud SQL、Amazon RDS、Microsoft Azure などのクラウド データベースで役立ちます。
- 論理バックアップはデータの破損を回避する効果があります。物理バックアップは破損することがあり、その場合、検証されるまで通知されない可能性があります。通常、論理バックアップはテキスト ファイルであるため、テキスト エディタでレビューを行い、破損を見つけることは簡単です。論理バックアップが破損することはほとんどありません。
- 物理バックアップとは異なり、論理バックアップはプラットフォーム、オペレーティング システム、MySQL バージョン間で高いポータビリティを備えています。
- 論理バックアップは高度に圧縮できます。
デメリット:
- 論理バックアップは、スキーマと行を取得するために MySQL サーバーにクエリを実行してから論理形式に変換する必要があるため、作成に時間がかかります。
- また、MySQL ではテーブルの作成、行のインポート、インデックスの再構築のために SQL ステートメントを実行する必要があるため、論理バックアップでは復元も遅くなります。
- 物理バックアップと比較して、論理バックアップはバックアップと復元オペレーションのために多くのサーバー リソース（CPU、RAM、ディスク I/O）を必要とします。
一般的な論理バックアップ ツール
ポイントインタイム リカバリ（PITR）
名前のとおり、ポイントインタイム リカバリによりインスタンスを特定の時点まで復元できます。たとえば、エラーによってデータが失われた場合、エラーが発生する前の状態にデータベースを復旧できます。
PITR は 2 段階のプロセスで、バイナリログに依存します。
- 完全な物理または論理バックアップを復元して、サーバーをバックアップ時と同じ状態にする
- バイナリログを適用して、バックアップの時点と目的の時点との間の変更を再生する
バイナリログには、テーブルの作成、行の挿入 / 更新 / 削除など、データベース インスタンスに加えた変更が含まれます。たとえば、毎日のバックアップが午前 6 時で、午前 10 時 15 分までインスタンスを回復したいとします。午前 10 時 15 分に状態を復元するには、まず午前 6 時から完全バックアップを復元してから、午前 6 時から午前 10 時 15 分までバイナリ ログイベントを再生します。これにより、サーバーは望ましいタイミングで望ましい状態になります。
レプリケーションと PITR にはバイナリログが必要で、それはベースとなるデータと同じくらい重要です。リカバリプランで効果的に機能させるには、バイナリログをリアルタイムでバックアップする必要があります。また、mysqlbinlog コマンドを使用してバイナリログをダウンロードできます。
例:
|
mysqlbinlog --host=<ホスト名> --port=<ポート> --user=<ユーザー> --password=<パスワード> --read-from-remote-server --raw --stop-never <binlog_filename> |
<binlog_filename> が最初にダウンロードするファイルとなり、mysqlbinlog はその後に次のファイルに自動的に切り替わります。そうしたバイナリログは、mysqlbinlog コマンドを実行するサーバーの現在のディレクトリに書き込まれます。ファイル名と場所は、--result-file オプションを使用して変更できます。また、--stop-never オプションを使用して、mysqlbinlog binlog をサーバーに接続したままにし、書き込まれた新しい変更をダウンロードすることもできます。
リモート サーバーに接続し、書き込まれたバイナリログをダウンロードする方法については、mysqlbinlog のマニュアルに詳しく説明されています。
Cloud SQL for MySQL でのバックアップと復元
Cloud SQL は、Google Cloud の MySQL 用マネージド データベース サービスとして、データ保護を目的とする自動バックアップとポイントインタイム リカバリ（PITR）を提供します。これらはデフォルトで有効になっており、Cloud SQL for MySQL インスタンスで高可用性（HA）を可能とするために必要です。
Cloud SQL バックアップは、バックアップが Persistent Disk（PD）上に作成されたスナップショットとなるため、物理バックアップの一種です。Cloud SQL は、バックアップを自動的に行う柔軟性を備えています。また、いつでもオンデマンドでバックアップすることも可能です。論理バックアップは、マネージド バックアップを中断することなく、標準の MySQL 論理バックアップ ツール（mysqldump、mydumper、mysqlpump など）を使用して引き続き取得できます。
Cloud SQL のバックアップの仕組みについて詳しく見てみましょう。
Cloud SQL スナップショットについて
Cloud SQL では、ストレージに Persistent Disk（PD）を使用します。すべての Cloud SQL インスタンスには、データベース ファイルやディレクトリを保存するために永続ディスクがアタッチされています。
Cloud SQL は、バックアップに PD スナップショットを使用し、そのスナップショットは特定の時点におけるデータディスクの状態を参照します。PD の最初のスナップショットは、PD のすべてのデータを含む完全なスナップショットであり、後続のスナップショットは増分で、前のスナップショット以降の新しいデータまたは変更されたデータのみが含まれます。これらのスナップショットは、永続データディスクのクラウド管理の物理コピーと考えることができ、これらは PITR を含む Cloud SQL のバックアップと復元のすべての機能の基礎となります。
Cloud SQL バックアップ
Cloud SQL は、自動バックアップとオンデマンドの 2 種類のマネージド バックアップを実行します。どちらのタイプも、デフォルトでインスタンスに最も近いマルチリージョン ロケーションに保存されます。たとえば、Cloud SQL インスタンスが us-central1 にある場合、バックアップはデフォルトで米国のマルチリージョンに保存されます。ただし、australia-southeast1 などのデフォルトのロケーションはマルチリージョンの外にあり、最も近いマルチリージョン（アジア）に配置されます。バックアップのカスタム ロケーションを選択することもできます。
自動バックアップ
自動バックアップは、選択した 4 時間の時間枠で毎日行われます。バックアップはバックアップ時間枠内に開始され、完了するまでバックアップ時間枠の外で続行されます。保持する自動バックアップの数を構成できます（1～365）。デフォルトの保持ポリシーは、最新の 7 個のバックアップを保持します。
オンデマンド バックアップ
また、オンデマンド バックアップはいつでも作成できます。これらはバックアップを必要とし、バックアップ時間枠を待たない場合に便利です。また、自動バックアップとは異なり、オンデマンド バックアップは自動的に削除されません。明示的に削除するか、インスタンスが削除されるまで維持されます。
Cloud SQL バックアップの復元
バックアップは、元のインスタンスと同じインスタンスに復元することも、同じプロジェクト内の別のインスタンスに復元することもできます。ターゲット インスタンスはリードレプリカでない必要があります。リードレプリカはプライマリ インスタンスのコピーであり、レプリカがプライマリと同期しなくなるリスクがあるため、バックアップの復元時にはリードレプリカ以外でなければなりません。リードレプリカは後でいつでも追加できます。
バックアップを復元すると、そのバックアップ スナップショットから新しい PD が作成され、インスタンスにアタッチされます。データベースは新しいディスクの使用を開始し、スナップショットから新たに復元された本格的な MySQL データベースとしてオンラインになる前に、標準の MySQL クラッシュ リカバリ プロセスを実行します。
同じインスタンスに復元する
バックアップから同じインスタンスに復元すると、そのインスタンス上のデータが、バックアップを作成したときの状態に戻ります。
別のインスタンスに復元する
バックアップから別のインスタンスに復元すると、ターゲット インスタンス上のデータが、バックアップを作成したときのソース インスタンスの状態に更新されます。
重要: バックアップを復元すると、以前のポイントインタイム リカバリ ログなど、ターゲット インスタンスの現在のデータがすべて上書きされます。上書きされたデータは復元できません。
Cloud SQL ポイントインタイム リカバリ（PITR）
Cloud SQL では、PITR は常にソース インスタンスの設定を継承した新しいインスタンスを作成します。これはクローン インスタンスのオペレーションと同様です。この機能を使用するには、移行元インスタンスで自動バックアップとポイントインタイム リカバリ（バイナリログ）の両方を有効にする必要があります。バイナリログのデフォルトの保持ポリシーは 7 日間です。1～7 日の範囲で保持期間を構成できます。
PITR は、元のインスタンスのバックアップから新しいインスタンスを作成し、元のインスタンス データディスクに保存されているバイナリログを指定された時点まで再生することで実現されます。
Cloud SQL で PITR を実行するときに、インスタンスの現在の状態のクローンを作成するか、過去のタイムスタンプのクローンを作成するかを選択できます。
PITR を実行するための UI は、次のようになります。
関連プロダクトとサービス
Google Cloud は、オンプレミスのデータセンターの廃止から SaaS アプリケーションの実行、基幹業務システムの移行まで、お客様のビジネスニーズに合わせて構築されたマネージド MySQL データベースを提供します。
