データベースが特段に大きい場合は、mysqldump を使用してそれぞれのスレーブにファイルをインポートするよりも、生データ ファイルをコピーする方が効率的な場合があります。

しかし、複雑なキャッシュやロギング アルゴリズムを使用しているストレージ エンジンのテーブルにこの方法を使うことは、完全にイン タイムのスナップショットにならない可能性があり、キャッシュ情報とロギング アップデートは、グローバル 読み込みロックを使っていたとしても、適用されない場合があります。これにストレージ エンジンがどのように反応するかは、クラッシュ リカバリ能力に依存します。

たとえば、グローバル 読み込みロックを使用していた場合、InnoDB テーブルのファイルシステム スナップショットを開始できます。内部的 (InnoDB ストレージ エンジンの中) には、InnoDB キャッシュをフラッシュしていないなどの理由で、スナップショットが乱れます。しかし、これはスタートアップ時に InnoDB によって解決され、一貫した結果が運ばれるため、問題になることはありません。つまり、InnoDB は破損を伴わずに、クラッシュ リカバリを行うことができる、ということですが、しかし、これは、 InnoDB テーブルの一貫したスナップショットを確保する一方で、MySQLサーバをストップすることができないということです。

生データのスナップショットを作成するには、cp または copy などの標準のコピー ツール、scp or rsync などの リモート コピー ツール、zip or tar などのアーカイブ ツール、dump などのファイル システム スナップショット ツールなどを使用し、MySQL データ ファイルが単一のファイルシステムに存在すると定めます。特定のデータベースを複製するだけである場合は、テーブルに関係のあるファイルのコピーを取るだけであることを確認します。InnoDB で、innodb_file_per_table オプションを利用しない場合は、すべてのデータベースにあるすべてのテーブルを一つのファイルに格納します。

アーカイブから次のファイルを指定して取り除く場合

生データのスナップショットで最も一貫した結果を得るには、次の通りにプロセス中にサーバをシャットダウンします。

データベースをシャットダウンしないで、マスタからスナップショットを得る。

データベースのアーカイブまたはコピーを作成した後は、スレーブでレプリケーション プロセスを開始する前に、それぞれのスレーブにファイルをコピーします。