スレーブを生成したい大きなMySQLデータベース(ディスク上で約100GB)があります。
スレーブを作成する一般的なプロセスは次のとおりです。
私たちが抱えている問題は、データベースのサイズです。上記のステップ2が完了するまでに、スレーブはマスターに大きく遅れて追いつくことができません。実際、スレーブレプリケーションどんどん遅れて。なぜこれが起こるのか分かりません。
スレーブサーバーをより早くシードする方法、またはレプリケーションの問題を修正する方法に関するアイデアはありますか?マスターサーバーには複数のデータベースがあり、InnoDB/MyISAMテーブルが混在していることに注意してください。サーバーはMySQL 5.1を実行しています
ここには2つの問題があり、個別に解決する必要があります。
スレーブの作成
そのサイズ、100GBでは、mysqldumpは通常、遅くなりすぎて効率的に実行できません。バイナリバックアップを使用してみてください。いくつかのオプションがあります。@ paulは1つを教えてくれますが、コピープロセスの間、マスターがロックされるという不便があります。さらに、小さなファイルが複数ある場合、rsyncは非常に効率的ですが、大きなファイルサイズ(ランダムに大きなibdata1がある場合)全体でランダムに変更されない場合があります。
私の推奨事項はsnapshoting(それを許可する仮想マシンまたはファイルシステムを使用している場合:ZFS、LVM上のその他すべて)またはPercona Xtrabackup/Oracle Enterprise Backup。これらのオプションを使用すると、ほとんどロックをかけずに、ファイルシステムからファイルをコピーするのとほぼ同じくらい高速にバックアッププロセスを実行できます。帯域幅が許す場合、それらのいくつかは並列コピーも可能にします。
これらのいずれもうまくいかない場合は、mydumperのような論理並列バックアップ/復元ユーティリティを使用してみてください。
ラグの増加を伴う複製
それが最初に発生する理由を発見する必要があります(両方のサーバーでクエリをプロファイルします)が、これらは最も一般的な原因の一部です。
binlog_format = ROW
。帯域幅の使用量を増やすことができますが、スレーブの負荷を軽減できます。innodb_flush_log_at_trx_commit
、 例えば)。そのサイズのデータベースを再作成する場合の主な問題は、インデックスです。数十億の行であると私が想定しているものを索引付けするには、しばらく時間がかかります。
解決策は、データとともにインデックスをコピーすることです。これは、ダンプをスキップすることを意味します。また、700Gbを超えるデータの移動をスキップすることも意味します。
これがあなたが今していることです:
代わりにこれを試してください:
ログインデックスを正しく設定するようなハウスキーピングがあるかもしれませんが、この方法では、データベースを再作成するのではなく、そのままコピーします。もちろん、バージョン番号は一致している必要があります。
より大きなテーブルを分割すると、rsyncは変更されたファイルのみをコピーするため、さらに高速なパフォーマンスが得られます。