MySQL 8.0 リファレンスマニュアル


17.4.1.1 mysqldump を使用したレプリカのバックアップ

mysqldump を使用してデータベースのコピーを作成することで、MySQL Server の別のインスタンスに情報をインポートできる形式でデータベース内のすべてのデータを取得できます (セクション4.5.4「mysqldump — データベースバックアッププログラム」を参照してください)。 情報の形式が SQL ステートメントであるため、緊急時にデータにアクセスする必要がある場合にファイルを実行中サーバーに配布して適用することも簡単にできます。 ただし、データセットのサイズが非常に大きい場合は、mysqldump が実用的でない場合があります。

ヒント

複数のスレッド、ファイル圧縮、進捗情報の表示、および Oracle Cloud Infrastructure Object Storage ストリーミングや MySQL データベースサービス 互換性チェックおよび変更などのクラウド機能で並列ダンプを提供する MySQL Shell dump utilities の使用を検討してください。 ダンプは、MySQL Shell load dump utilities を使用して MySQL Server インスタンスまたは MySQL データベースサービス DB システムに簡単にインポートできます。 MySQL Shell のインストール手順は、here にあります。

mysqldump を使用する場合は、ダンププロセスを開始する前にレプリカのレプリケーションを停止して、ダンプに一貫性のあるデータセットが含まれていることを確認する必要があります:

  1. レプリカによるリクエストの処理を停止します。 mysqladmin を使用して、レプリカ上のレプリケーションを完全に停止できます:

    shell> mysqladmin stop-slave

    または、レプリケーション SQL スレッドのみを停止してイベントの実行を一時停止することもできます:

    shell> mysql -e 'STOP SLAVE SQL_THREAD;'
    Or from MySQL 8.0.22:
    shell> mysql -e 'STOP REPLICA SQL_THREAD;'

    これにより、レプリカは引き続きソースバイナリログからデータ変更イベントを受信し、レプリケーション I/O スレッドを使用してリレーログに格納できますが、レプリカはこれらのイベントを実行してデータを変更できなくなります。 ビジーなレプリケーション環境では、レプリケーション SQL スレッドを再起動するときに、バックアップ中にレプリケーション I/O スレッドの実行を許可するとキャッチアッププロセスが高速化される場合があります。

  2. mysqldump を実行してデータベースをダンプします。 すべてのデータベースをダンプしたり、ダンプするデータベースを選択したりできます。 たとえば、すべてのデータベースをダンプするには:

    shell> mysqldump --all-databases > fulldb.dump
  3. ダンプが完了したら、レプリケーションを再度開始します:

    shell> mysqladmin start-slave

前の例では、ログイン資格証明 (ユーザー名、パスワード) をコマンドに追加したり、毎日自動的に実行できるプロセスをスクリプトにバンドルしたりすることをお勧めします。

このアプローチを使用する場合は、必ずレプリケーションプロセスを監視して、バックアップの実行に要した時間が、ソースからのイベントを継続するレプリカ機能に影響しないようにしてください。 セクション17.1.7.1「レプリケーションステータスの確認」を参照してください。 レプリカを維持できない場合は、別のレプリカを追加してバックアッププロセスを分散できます。 このシナリオの構成方法の例は、セクション17.4.6「異なるレプリカへの異なるデータベースのレプリケート」を参照してください。


関連キーワード:  ソース, バックアップ, ベース, データベース, バイナリ, GTID, mysqldump, ステートメント, 構成, トランザクション