マスタに接続したスレーブの数が増えると、若干の負荷も同様に増え、それぞれのスレーブがマスタへのクライアント コネクションを使い切ります。さらに、それぞれのスレーブはマスタのバイナリ ログの完全なコピーを受け取る必要があるめ、マスタのネットワーク負荷も同様に増え、ボトルネックを生成しシステム全体の性能が低下します。
スケール アウト ソリューションなどで、マスタに接続しているスレーブの数が多いときは、それに対応してマスタでの処理量は膨大になるため、レプリケーション プロセスのパフォーマンスを改善することをお勧めします。
レプリケーション プロセスのパフォーマンスを改善する方法の一つには、よりディープなレプリケーション ストラクチャを構築することがあります。これは、マスタが一つのスレーブにだけ複製を行い、ほかのスレーブは個別のレプリケーション要求に対応するプライマリ スレーブに接続するという方法です。このストラクチャのサンプルは 図 5.8. 「追加のレプリケーション ホストでパフォーマンス改善」 を参照してください。
これを実現するには、MySQL インスタンスを次のように設定します。
Master 1 はプライマリ マスタで、このデータベースにすべての変更とアップデートが書き込まれます。バイナリ ロギングはこのマシンで実行可能にします。
Master 2 は Master 1 へのスレーブです。Master 1 はレプリケーション ストラクチャにおいて、レプリケーションの機能性をスレーブの残留分に提供します。ここで Master 2 は Master 1 に唯一接続しているマシンです。Master 2 はバイナリ ロギングが可能な状態です。
--log-slave-updatesオプション で Master 1 からの複製指示が Master 2 のバイナリ ログに書き込まれ、これにより、両者が正当なスレーブに複製するようになります。Slave 1、Slave 2、Slave 3 は Master 2 のスレーブとして稼動し、Master 2 からの情報を複製しますが、実際には Master 1 でログしたデータです。
このソリューションは、プライマリ マスタのクライアント負荷だけでなくネットワーク インターフェイス負荷を減らすことができ、プライマリ マスタのパフォーマンス全体を改善するダイレクト データベース ソリューションとして活用できます。
マスタのレプリケーション プロセスに追いつくことに支障をきたしているスレーブがある場合には、次のオプションで対応します。
リレー ログとデータ ファイルをできるだけ物理的に独立したドライブに割り振ります。そのためには、
--relay-logオプションを使用して、リレー ログの保管場所を指定します。スレーブがマスタよりも特段に遅い場合は、データベースの種類にあわせて複製の役割を別のスレーブに分けることをお勧めします。詳細は 項5.3.4. 「異なるデータベースから異なるスレーブへのレプリケーション」 を参照してください。
マスタのトランザクションを活用し、スレーブがそのトランザクション サポートをしているかどうかを確かめるには、
MyISAMまたはその他の非トランザクション エンジンを使用します。詳細は 項5.3.2. 「ストレージ エンジンが異なるマスタとスレーブのレプリケーション」 を参照してください。スレーブがマスタとして稼動していない状況で、なにかしら対処できる方法があり、障害イベント中のマスタを持ち込むことができる場合には、
--log-slave-updatesオプションをオフにします。これは、“処理能力のない”スレーブがまた、それぞれのバイナリのログに実行したイベントを記録することを防ぎます。
