PDF (US Ltr)- 26.8Mb
PDF (A4)- 26.8Mb
マスターに接続するスレーブの数が増えるにつれ、各スレーブがマスターへのクライアント接続を使用するため、最小限ですが負荷も増えます。また、各スレーブはマスターバイナリログのフルコピーを受け取る必要があるため、マスター上のネットワーク負荷も増加し、ボトルネックになる場合があります。
1 つのマスターに接続される非常に多くのスレーブを使用していて、そのマスターも要求の処理にビジーな場合には （たとえば、スケールアウトソリューションの一部として）、レプリケーションプロセスのパフォーマンスを改善することをお勧めします。
レプリケーションプロセスのパフォーマンスを改善する方法の 1 つは、より深いレプリケーション構造を作成して、マスターは 1 つのスレーブにのみ複製し、残りのスレーブは個々のレプリケーション要件のためにこのプライマリスレーブに接続します。この構造のサンプルを図17.3「パフォーマンスを改善するために追加レプリケーションホストを使用する」に示します。
これが機能するには、MySQL インスタンスを次のように構成する必要があります。
マスター 1 はプライマリマスターで、すべての変更と更新がこのデータベースに書き込まれます。バイナリロギングはこのマシンで有効にすべきです。
マスター 2 はマスター 1 のスレーブで、レプリケーション構造内の残りのスレーブにレプリケーション機能を提供します。マスター 2 はマスター 1 への接続を許可される唯一のマシンです。マスター 2 のバイナリロギングも有効になっていて、
--log-slave-updatesオプションによってマスター 1 からのレプリケーション命令がマスター 2 のバイナリログにも書き込まれるため、それらを真のスレーブに複製できます。スレーブ 1、スレーブ 2、およびスレーブ 3 はマスター 2 のスレーブとして機能し、マスター 2 からの情報 (実際にはマスター 1 でログが記録された更新で構成される) を複製します。
上記のソリューションは、クライアント負荷とプライマリマスターでのネットワークインタフェース負荷を低減するため、直接のデータベースソリューションとして使用されるときにプライマリマスターの全体的なパフォーマンスを改善するはずです。
スレーブがマスター上のレプリケーションプロセスに追い付くことに問題がある場合には、利用できるオプションがいくつかあります。
可能であれば、リレーログとデータファイルを異なる物理ドライブに置きます。これを行うには、
--relay-logオプションを使用してリレーログの場所を指定します。スレーブがマスターよりかなり遅い場合は、異なるデータベースを異なるスレーブに複製する責任を分割することをお勧めします。セクション17.3.4「異なるデータベースを異なるスレーブに複製する」を参照してください。
マスターがトランザクションを使用するため、スレーブ上でのトランザクションサポートに関心がない場合は、スレーブ上で
MyISAMまたは別の非トランザクションエンジンを使用してください。セクション17.3.2「異なるマスターおよびスレーブストレージエンジンでレプリケーションを使用する」を参照してください。スレーブがマスターとして動作せず、障害時に確実にマスターを回復できる潜在的ソリューションが実装されている場合は、
--log-slave-updatesをオフに切り替えることができます。これにより、「ダム」スレーブが実行したイベントのログが自身のバイナリログに記録されなくなります。