MySQL 4 の一般的なマスタースレーブレプリケーションアーキテクチャ

1つのマスターと複数のスレーブのレプリケーションアーキテクチャ
マルチレベルレプリケーションアーキテクチャ
デュアルマスターレプリケーションアーキテクチャ
マルチソースレプリケーションアーキテクチャ
マスタースレーブ遅延問題を最適化するにはどうすればよいでしょうか?

1つのマスターと複数のスレーブのレプリケーションアーキテクチャ

マスターデータベースへの読み取り要求の負荷が非常に高いシナリオでは、1 つのマスターと複数のスレーブのレプリケーションアーキテクチャを構成することで、読み取りと書き込みの分離を実現できます。次の図に示すように、高いリアルタイムパフォーマンスを必要としない大量の読み取り要求は、ロードバランシングによって複数のスレーブデータベースに分散され (高いリアルタイムパフォーマンスが要求される読み取り要求はマスターデータベースから読み取ることができます)、マスターデータベースへの読み取り負荷が軽減されます。

メインデータベースの異常なダウンタイムが発生した場合、スレーブデータベースをメインデータベースに切り替えて、サービスの提供を継続できます。

マスタースレーブレプリケーションのシナリオでは、マスタースレーブ遅延が発生します。これを解決する方法を考えてみましょう。

マルチレベルレプリケーションアーキテクチャ

1 つのマスターと複数のスレーブのアーキテクチャは、特に高い読み取り要求圧力を伴うほとんどのシナリオのニーズを解決できます。MySQL レプリケーションでは、マスターデータベースが BINLOG ログをスレーブデータベースの I/O スレッドに送信する必要があることを考慮すると、スレーブデータベースの増加に伴って、マスターデータベースの I/O 圧力とネットワーク圧力が増加します (各スレーブデータベースには、イベントを送信するためのマスターデータベース上に独立した BINLOG ダンプスレッドがあります)。マルチレベルレプリケーションアーキテクチャは、1 つのマスターと複数のスレーブのシナリオにおけるマスターデータベースの追加 I/O 圧力とネットワーク圧力を解決します。 MySQL のマルチレベルレプリケーションアーキテクチャを下図に示します。

1 つのマスターと複数のスレーブのアーキテクチャと比較すると、マルチレベルレプリケーションでは、マスターデータベース Master1 をスレーブデータベース Slave1、Slave2、および Slave3 にレプリケーションする途中で、セカンダリマスターデータベース Master2 を追加するだけです。このように、マスターデータベース Master1 は、1 つのスレーブデータベース Master2 に BINLOG ログを送信するだけで済むため、マスターデータベース Master1 への負荷が軽減されます。次に、セカンダリマスターライブラリ Master2 は、BINLOG ログをすべてのスレーブライブラリ Slave1、Slave2、および Slave3 の I/O スレッドに送信します。

マルチレベルレプリケーションは、1 つのマスターと複数のスレーブのシナリオで、マスターデータベースの I/O 負荷とネットワークプレッシャーを解決します。もちろん、欠点もあります。MySQL の従来のレプリケーションは非同期です。マルチレベルレプリケーションのシナリオでは、マスターデータベースのデータは、スレーブデータベース Slave1、Slave2、および Slave3 に到達する前に 2 回複製されます。この期間中の遅延は、1 つのマスターと複数のスレーブのシナリオで 1 回のみのレプリケーションの場合よりも大きくなります。

セカンダリマスターデータベース Master2 のテーブルエンジンとして BLACKHOLE を選択すると、マルチレベルレプリケーションの待機時間を短縮できます。名前が示すように、BLACKHOLE エンジンは「ブラックホール」エンジンです。BLACKHOLE テーブルに書き込まれたデータはディスクに書き込まれません。BLACKHOLE テーブルは常に空のテーブルです。INSERT、UPDATE、および DELETE 操作は、BINLOG にイベントを記録するだけです。

テーブル `user` を作成します (
	`id` int NOT NULL AUTO_INCREMENT 主キー、
	`name` varchar(255) NOT NULL デフォルト ''
	`age` tinyint unsigned NOT NULL DEFAULT 0
)ENGINE=BLACKHOLE 文字セット=utf8mb4;
`user` (`name`,`age`) に値 ("itbsl", "26") を挿入します。
`user` から * を選択します。

ご覧のとおり、ストレージエンジンが BLACKHOLE であるユーザーテーブルにはデータがありません。

BLACKHOLE エンジンは、セカンダリマスターライブラリ Masger2 のシナリオに非常に適しています。Master2 は読み取りおよび書き込み要求を処理しませんが、BINLOG ログをできるだけ早くスレーブライブラリに送信する役割のみを果たします。

デュアルマスターレプリケーションアーキテクチャ

デュアルマスターレプリケーションアーキテクチャは、DBA がメンテナンスのためにマスターデータベースとスレーブデータベースを切り替える必要があるシナリオに適しています。デュアルマスターレプリケーションアーキテクチャにより、スレーブデータベースを繰り返し構築する手間が省けます。デュアルマスターレプリケーションアーキテクチャを次の図に示します。

マスターデータベース Master1 と Master は相互にマスタースレーブであり、すべての Web クライアント書き込み要求はマスターデータベース Master1 または Master2 にアクセスします。さらに、DBA は日常的なメンテナンス操作を実行する必要があり、サービスに影響を与えないようにするために、次の操作を実行する必要があります。

まず、Master1 データベースのスレーブスレッドを停止 (STOP SLAVE) して、Master2 データベースでのその後のメンテナンス操作が Master1 データベースにリアルタイムでコピーされ、サービスに影響を与えないようにします。
次に、Master2 データベースのスレーブスレッドを停止 (STOP SLAVE) し、varchar フィールドの長さを 10 から 200 に変更するなどの定期的なメンテナンス操作を開始します。
次に、Master2 ライブラリのメンテナンス操作が完了したら、Master2 ライブラリでスレーブスレッド (STRART SLAVE) を開き、Master2 のデータを Master1 ライブラリと同期します。同期が完了したら、アプリケーションの書き込み操作を Master2 ライブラリに切り替えます。
最後に、Master1 ライブラリにアクセスしているアプリケーションがないことを確認した後、Master1 の Slave スレッドを開きます (START SLAVE)。

デュアルマスターレプリケーションアーキテクチャにより、1 つのマスターと複数のスレーブのアーキテクチャでマスターライブラリを維持するために必要なスレーブライブラリのセットアップの追加作業が大幅に削減されます。

もちろん、デュアルマスターアーキテクチャは、マスタースレーブレプリケーションと組み合わせて使用することもできます。マスター2ライブラリの下にスレーブライブラリSlave1、Slave2などを設定します。これにより、スレーブライブラリSlave1などを介して読み取り負荷を共有し、DBAがメンテナンスを行う間にスレーブライブラリを再構築するという余分な作業を回避できます。ただし、スレーブライブラリのレプリケーション遅延には注意する必要があります。 MySQL デュアルマスターマルチレベルレプリケーションアーキテクチャを以下に示します。

マルチソースレプリケーションアーキテクチャ

マルチソースレプリケーションアーキテクチャは複雑なビジネスニーズに適しており、OLTP (オンライントランザクション処理) と OLAP (オンライン分析処理) の両方をサポートできます。 MySQL のマルチソースレプリケーションアーキテクチャについては当分描かないことにします。時間があるときに描いて追加します（描くのも体力仕事です）。ご興味があれば、「MySQL データベースの開発、最適化、管理、メンテナンスを簡単に解説」という本をお読みください。