DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

MySQLの必須バックアップ戦略：データに最適なアプローチの選択

MySQLの論理バックアップ、物理バックアップ、バイナリログバックアップを比較し、RTOとRPOに合った復元戦略を選択できるようにします。

必須のMySQLバックアップ戦略：データに最適なアプローチの選択

MySQLのバックアップ戦略は、プレッシャーの中で復元できて初めて有効です。ダンプファイル、ファイルシステムスナップショット、物理バックアップはそれぞれ異なる復旧問題を解決するため、適切な選択はデータサイズ、ダウンタイム許容度、失っても構わないデータ量に依存します。

MySQLバックアップに復元計画が必要な理由

バックアップはディスク障害から保護するだけではありません。アプリケーションのバグ、悪いデプロイ、誤った削除、ランサムウェア、地域的な障害からの復旧にも役立ちます。

2つの目標から始めましょう：

  • RTO（目標復旧時間）： 復元中にデータベースをどれだけダウンさせられるか？
  • RPO（目標復旧ポイント）： どれだけ最近のデータを失っても構わないか？

例えば、小さな内部Wikiは夜間のmysqldumpと1時間の復元に耐えられるかもしれません。本番の注文システムは、悪意のあるDELETEの前に特定の秒まで復元できるよう、物理バックアップとバイナリログが必要かもしれません。

mysqldumpによる論理バックアップ

論理バックアップはスキーマとデータをSQLとしてエクスポートします。移植性が高く検査が容易ですが、大規模データベースでは作成に時間がかかり、復元にはさらに時間がかかる場合があります。

1つのデータベースをバックアップ：

mysqldump -u your_username -p your_database_name > backup_file.sql

すべてのデータベースをバックアップ：

mysqldump -u your_username -p --all-databases > all_databases_backup.sql

特定のテーブルをバックアップ：

mysqldump -u your_username -p your_database_name table1 table2 > specific_tables_backup.sql

スキーマが依存する場合は、ルーチン、イベント、トリガーを含めます。トリガーは通常のmysqldump使用でデフォルトで含まれますが、バックアップの実行手順書で意図を明示することで、レビュアーが気付きやすくなります。

mysqldump -u your_username -p --routines --events --triggers your_database_name > database_with_programs.sql

既存のデータベースに復元：

mysql -u your_username -p your_database_name < backup_file.sql

InnoDB主体のワークロードでは、--single-transactionを追加して、長いテーブルロックなしで一貫性のあるスナップショットを読み取ります：

mysqldump -u your_username -p --single-transaction --routines --events your_database_name | gzip > backup_file.sql.gz

MyISAMなどの非トランザクションテーブルに依存している場合、--single-transactionを唯一の一貫性保護として使用しないでください。それらのテーブルには別のロックまたはスナップショット計画が必要です。

大規模データベース向けの物理バックアップ

物理バックアップは、データベースをSQLとして再構築する代わりにMySQLデータファイルをコピーします。復元時間がファイルのコピーとリカバリログの適用に近いため、通常は大規模データセットに適しています。

一般的なオプションは次のとおりです：

  • ファイルシステムまたはクラウドボリュームのスナップショット。MySQLデータがクラッシュ一貫性またはアプリケーション一貫性を持つように調整します。
  • Percona XtraBackup。MySQL互換のInnoDBデータのホット物理バックアップ用に広く使用されているオープンソースツール。
  • MySQL Enterprise Backup。MySQL Enterpriseデプロイメント向けのOracleの商用バックアップツール。

XtraBackupでフルバックアップを作成：

xtrabackup --backup --target-dir=/path/to/backup/full --user=your_username --password=your_password

復元前にバックアップを準備：

xtrabackup --prepare --target-dir=/path/to/backup/full

MySQLを停止し、古いデータディレクトリを移動してから復元：

systemctl stop mysql
mv /var/lib/mysql /var/lib/mysql.before-restore
mkdir /var/lib/mysql
xtrabackup --copy-back --target-dir=/path/to/backup/full --datadir=/var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

この例では、Debianスタイルのサービス名とデータディレクトリを想定しています。復元コマンドを実行する前に、パッケージ、コンテナイメージ、または管理データベースのドキュメントを確認してください。

バイナリログとポイントインタイムリカバリ

バックアップは復元元を示します。バイナリログは、そのバックアップ後の変更を再生するのに役立ち、ポイントインタイムリカバリに必要です。

セルフマネージドMySQLで、バージョンとパッケージに適したlog_bin設定でバイナリログを有効にします。次に、バイナリログをデータベースサーバーとは別の場所にバックアップします。

復元時には通常、次の手順を実行します：

  1. 最新の正常なフルバックアップまたは増分バックアップを復元します。
  2. mysqlbinlogを使用して、ターゲットの時刻または位置までバイナリログを再生します。
  3. オペレーターエラーから復旧する場合は、不正なステートメントの前で停止します。

適切なバックアップ戦略の選択

シンプルな決定ルールを使用します：

  • 小規模データベース：自動化されたmysqldump、圧縮、オフサイトストレージ、定期的な復元テストから始めます。
  • 中規模データベース：ポイントインタイムに復元できるよう、バイナリログバックアップを追加します。
  • 大規模またはビジネスクリティカルなデータベース：物理バックアップ、サポートされている場合は増分バックアップ、バイナリログ、監視、文書化された復元訓練を使用します。

バックアップ速度だけで選択しないでください。インシデント中は復元速度の方が重要です。

実際に重要なバックアッププラクティス

バックアップジョブを自動化しますが、プロセスが退屈になるまで手動で復元をテストします。バックアップをオフサイトに保存し、機密バックアップを暗号化し、ジョブの失敗を監視し、静かな破損や数日後に発見される誤削除を検出できるよう十分な保持期間を維持します。

また、正確な復元順序を文書化します。実際の障害時には、どのフルバックアップ、増分バックアップ、バイナリログ範囲が一緒に属するかを将来の自分が推測する必要があってはなりません。

まとめ

復元目標に合ったバックアップ方法を選択してください。mysqldumpは小規模データベースと移植可能な復元に適しています。物理バックアップは大規模システムに適しています。バイナリログはポイントインタイムリカバリが必要な場合のギャップを埋めます。何を選んでも、テスト環境で正常に復元されるまではバックアップはカウントされません。