1. MySQL バックアップ戦略
- スレーブ ライブラリに基づいてバックアップを優先し、実稼働環境の負荷を軽減します。
- ホット バックアップを優先する: ホット (ホット) は、バックアップ中に MySQL サービスがシャットダウンされず、運用に影響がないことを意味します。
- データ量が多い場合は物理バックアップが優先され、データ量が少ない場合は論理バックアップが使用できます。論理バックアップ(通常は mysqldump) の方が簡単ですが、リカバリ時間が長くなります。
- 毎日のバックアップ、毎週のバックアップ、毎月のバックアップ、四半期ごとのバックアップなど、包括的なデータ バックアップ戦略を策定する必要があります。データの量が多い場合は、定期的な完全バックアップ (低頻度) と頻繁な増分バックアップ (高頻度) が必要です。原則として、近い将来、毎日バックアップする必要があります。expi re_logs_days パラメータは少なくとも 2 ～ 3 つのバックアップにわたる必要があります。
- バックアップ サーバーは運用サーバーと同じくらい重要であると考える必要があります。バックアップ ファイルはデータベース ホストから物理的に分離する必要があり、独立したバックアップ サーバーにバックアップ ファイルを保持するには FTP アップロードまたはその他のネットワーク送信方法を選択できます。NFS を使用して、リモート バックアップ用のファイル システムをマウントできます。
- スレーブ ライブラリを構築してポイントインタイム リカバリを実行するには、メイン ライブラリでバイナリ ログを有効にする必要があります。
2. mysqldump を使用してデータをバックアップおよび復元する
2.1. 基本的なバックアップとリカバリ
- データベース全体のバックアップコマンドの形式
shell> mysqldump --databases db_name > db_name.sql
- 回復方法 1:
shell> mysql db_name < db_name.sql
- 復元方法 2 では、source コマンドを使用して以下を実行できます。
mysql > source /path/to/db_name.sql
- 実稼働環境では、通常、マスター/スレーブ構成が使用され、スレーブ データベースで定期的なバックアップを実行する必要があります。mysqldump バックアップを使用する完全な例を次に示します。
mysqldump --single-transaction --flush-logs --master-data=2 --hex-blob -R -E -f --all-databases 2>> /path/to/log | gzip > sql.name.gz
- --single-transaction パラメータ: ノンブロッキング バックアップを実現します。最初にテーブルをロックするだけで、その後はノンブロッキング バックアップになります。つまり、バックアップはトランザクションの操作に影響を与えません。
- -f パラメータ: ビューには依存関係があるため、基礎となるテーブルが存在しないか権限がない場合、ビューのエクスポートは失敗し、mysqldump コマンドが終了します。この問題を回避するには、パラメータ -f を追加します。途中で終了するのではなく、データを強制的にエクスポートします。
- --result-file パラメータ: mysqldump のバックアップの場合、出力をチェックしてエラーや警告があるかどうかを確認する必要があります。通常のバックアップの後、「ダンプが完了しました」という文字が表示されるはずです。 -- を使用できます。 mysqldump の結果を保存するための result-file パラメータ。
2.2. ストアドプロシージャのバックアップとリカバリ
- バックアップ ストアド プロシージャ:
shell> mysqldump -td -R --triggers=false db_name > db_name_procedure.sql
- データのみがバックアップされ、ストアやトリガーはバックアップされません。
mysqldump --triggers=false db_name > db_name_data.sql
- トリガーを復元するときは、最初にデータベース内の元のトリガーを削除する必要があります。エクスポートされたトリガーのダンプ ファイルには DROP TRIGGIER ステートメントがないため、DROP TRIGGER ステートメントを手動で生成する必要があります。次のステートメントは、information_schema に基づいてトリガー削除ステートメントを自動的に生成できます。
SELECT CONCAT('drop trigger ',TRIGGER_NAME,';') INTO OUTFILE '/tmp/drop_trigger.sql' FROM information_schema.triggers WHERE TRIGGER_SCHEMA='db_name';
3. まとめ
- MySQL はスレーブ データベースにバックアップするのが最適で、大量のデータは物理バックアップ (データ ファイルのバックアップ)、少量のデータは論理バックアップ (mysqldump) に適しています。
- MySQL バックアップにはホット バックアップを実行するのが最善です。つまり、本番環境に影響を与えず、ダウンタイムも必要ありません。
- 大量のデータを含むデータベースの場合は、定期的な完全バックアップを低い頻度で実行し、定期的なバックアップを高い頻度で実行することをお勧めします。