コピーされるファイルの整合性を保証するには、レプリカサーバーの停止中に MySQL レプリカ上の RAW データファイルのバックアップを実行する必要があります。 MySQL サーバーがまだ実行中の場合は、バックグラウンドタスクがデータベースファイルをまだ更新中の可能性があります (特に、InnoDB などのストレージエンジンをバックグラウンドプロセスで使用するもの)。 InnoDB では、クラッシュリカバリ中にこれらの問題を解決する必要がありますが、この機能を利用すると、ソースの実行に影響を与えることなく、バックアッププロセス中にレプリカサーバーを停止できるためです。

サーバーをシャットダウンしてファイルをバックアップするには：

通常、レプリカ MySQL サーバーのデータディレクトリ全体をバックアップする必要があります。 データをリストアしてレプリカとして操作できるようにするには (レプリカに障害が発生した場合など)、データに加えて、レプリカ接続メタデータリポジトリと適用者メタデータリポジトリ、およびリレーログファイルが必要です。 これらのアイテムは、レプリカデータのリストア後にレプリケーションを再開するために必要です。 MySQL 8.0 のデフォルトであるレプリカ接続メタデータリポジトリおよび適用機能メタデータリポジトリ (セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」 を参照) にテーブルが使用されている場合、これらのテーブルはデータディレクトリとともにバックアップされます。 非推奨のリポジトリにファイルが使用されている場合は、それらを個別にバックアップする必要があります。 リレーログファイルがデータディレクトリとは異なる場所に配置されている場合は、個別にバックアップする必要があります。

リレーログを失っても relay-log.info ファイルが残っている場合は、それをチェックして、レプリケーション SQL スレッドがソースバイナリログで実行された距離を判断できます。 その後、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 から) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) を SOURCE_LOG_FILE | MASTER_LOG_FILE および SOURCE_LOG_POS | MASTER_LOG_POS オプションとともに使用して、バイナリログを再度読み取り、そのレプリカに記録することができます。 これには、バイナリログがソースサーバーにまだ存在している必要があります。

レプリカが LOAD DATA ステートメントをレプリケートしている場合は、レプリカがこの目的で使用するディレクトリに存在する SQL_LOAD-* ファイルもバックアップする必要があります。 レプリカでは、中断された LOAD DATA 操作のレプリケーションを再開するために、これらのファイルが必要です。 このディレクトリの場所は、slave_load_tmpdir システム変数の値です。 その変数を設定してサーバーを起動しなかった場合、ディレクトリの場所は tmpdir システム変数の値になります。