MySQL レプリケーション アーキテクチャをマスターする方法

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

実際のアプリケーションでは、ほとんどの MySQL レプリケーション アーキテクチャ パターンは 1 つのマスターを 1 つ以上のスレーブにレプリケートします。

メイン ライブラリの読み取り要求の負荷が非常に高いシナリオでは、ワンマスター マルチスレーブ レプリケーション アーキテクチャを構成して読み取りと書き込みの分離を実現し、多数のリアルタイム要件が特に高くないデータ読み取りリクエストはロード バランシングを通じて複数のスレーブ ライブラリに分散され (リアルタイム要件の高い読み取りリクエストはマスター ライブラリから読み取ることができます)、マスター ライブラリへの読み取りプレッシャーが軽減されます。以下の図に示すように。

欠点:

• マスターはシャットダウンできず、シャットダウンすると書き込みリクエストを受信できません

• スレーブが多すぎると遅延が発生します

定期メンテナンスのためにマスターをシャットダウンする必要があるため、スレーブをマスターに変換する必要があります。どれを選ぶかが悩みどころ？

スレーブがマスターになると、現在のマスターと以前のマスターのデータの間に不一致が発生し、以前のマスターは現在のマスター ノードの binlog ファイルと pos の場所を保存しませんでした。

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

マルチマスター レプリケーション アーキテクチャは、シングルマスター マルチスレーブ レプリケーション アーキテクチャにおけるマスターの単一障害点の問題を解決します。

keepalived などのサードパーティ ツールを使用すると、メンテナンスのためのマスターのダウンタイムが書き込み操作に影響しないように、IP ドリフトを簡単に実現できます。

カスケード レプリケーション アーキテクチャ

1 つのマスターと多数のスレーブスレーブが多すぎると、スレーブ ライブラリの増加に応じてマスター ライブラリの I/O プレッシャーとネットワーク プレッシャーが増加します。各スレーブ ライブラリには、イベントを送信するためのマスター ライブラリ上に独立した BINLOG ダンプ スレッドがあり、カスケード レプリケーション アーキテクチャは、1 つのマスターと複数の奴隷。

以下に示すように。

1 マスターおよび複数スレーブのアーキテクチャと比較すると、カスケード レプリケーションはマスター データベースから少数のスレーブ データベースにのみコピーし、他のスレーブ データベースはそこからコピーします。これらのいくつかのスレーブ データベース。データをコピーすることで、メイン データベース マスターへの負担が軽減されます。

もちろん、欠点もあります: MySQL の従来のレプリケーションは非同期です。カスケード レプリケーション シナリオでは、マスター データベース内のデータは、他のスレーブ データベースに到達する前に 2 回のレプリケーションを受ける必要があります。この期間の遅延を比較します。 1 つのマスターと複数のスレーブのレプリケーション シナリオでは、次回にコピーが 1 つしか経由しない場合は大問題です。

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

以下は BLACKHOLE エンジンを示しています:

mysql> CREATE TABLE `user` (
    -> `id` int NOT NULL AUTO_INCREMENT PRIMARY KEY,
    -> `name` varchar(255) NOT NULL DEFAULT '',
    -> `age` tinyint unsigned NOT NULL DEFAULT 0
    -> )ENGINE=BLACKHOLE charset=utf8mb4;Query OK, 0 rows affected (0.00 sec)mysql> INSERT INTO `user` (`name`,`age`) values("itbsl", "26");Query OK, 1 row affected (0.00 sec)mysql> select * from user;Empty set (0.00 sec)

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

マルチマスターとカスケード レプリケーションの組み合わせアーキテクチャ

マルチマスターとカスケード レプリケーション アーキテクチャを組み合わせることで、シングルポイント マスターの問題とスレーブ カスケード遅延の問題が解決されます。

#マルチマスター レプリケーション アーキテクチャの構築

ホスト計画:

• master1: docker、ポート 3314

• master2: docker、ポート 3315

master1 の構成

構成ファイル my.cnf:

$ cat /home/mysql/docker-data/3315/conf/my.cnf
[mysqld]
character_set_server=utf8
init_connect='SET NAMES utf8'

symbolic-links=0

lower_case_table_names=1
server-id=1403314
log-bin=mysql-bin
binlog-format=ROW
auto_increment_increment=2 # 几个主库，这里就配几
auto_increment_offset=1 # 每个主库的偏移量需要不一致
gtid_mode=ON
enforce-gtid-consistency=true
binlog-do-db=order      # 要同步的数据库

docker を開始します:

$ docker run --name mysql3314 -p 3314:3306 --privileged=true -ti -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=order -e MYSQL_USER=user -e MYSQL_PASSWORD=pass -v /home/mysql/docker-data/3314/conf:/etc/mysql/conf.d -v /home/mysql/docker-data/3314/data/:/var/lib/mysql -v /home/mysql/docker-data/3314/logs/:/var/log/mysql -d mysql:5.7

レプリケーション用のユーザーを追加して承認します:

mysql> GRANT REPLICATION SLAVE,FILE,REPLICATION CLIENT ON *.* TO 'repluser'@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

同期マスター 1 を開始します (ここでのユーザーはマスター 2 からのものです):

mysql> change master to master_host='172.23.252.98',master_port=3315,master_user='repluser',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.03 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

マスター 2 の構成

マスター 2 の構成はマスター 1 と似ています。

主な違いは、my.cnf に一貫性を保つ必要がある属性があることです:

auto_increment_offset=2 # 每个主库的偏移量需要不一致

テスト:

master2 にテーブルを作成し、データを追加します:

mysql> create table t_order(id int primary key auto_increment, name varchar(20));
Query OK, 0 rows affected (0.01 sec)

mysql> insert into t_order(name) values("A");
Query OK, 1 row affected (0.01 sec)

mysql> insert into t_order(name) values("B");
Query OK, 1 row affected (0.00 sec)

mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
|  2 | A    |
|  4 | B    |
+----+------+
2 rows in set (0.00 sec)

master2 の id のステップサイズは 2 で、2 から増加し始めることがわかります。

次に、master1 のデータをクエリして、次を追加します。

mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
|  2 | A    |
|  4 | B    |
+----+------+
2 rows in set (0.00 sec)

mysql> insert into t_order(name) values("E");
Query OK, 1 row affected (0.00 sec)

mysql> select * from t_order;
+----+------+
| id | name |
+----+------+
|  2 | A    |
|  4 | B    |
|  5 | E    |
+----+------+
3 rows in set (0.00 sec)

master1 の id のステップ サイズが 2 で、1 から増加し始めることがわかります。次に、master2 でクエリを実行すると、 ID が 5 であることがわかります。データは、マスター間レプリケーション構成に問題がないことを示しています。

2 つのマスターの ID インクリメントのオフセットが一致しないのはなぜですか? 2 つのマスターが同時に挿入要求を受信した場合、ID が競合しないことを保証できますが、実際には、これは挿入されたデータが競合しないことを保証するだけで、削除や変更によるデータの不整合を保証することはできません。

したがって、実際のアプリケーション シナリオでは、データの一貫性を確保するためにクライアントに公開できるマスターは 1 つだけです。

MySQL の高可用性構築

ここでは、keepalived を使用して上記のマルチマスター レプリケーション アーキテクチャを変換し、MySQL の高可用性を実現します。

keepalived インストール:

$ sudo apt-get install -y keepalived

keepalived.conf

$ cat /etc/keepalived/keepalived3314.conf! Configuration File for keepalived#简单的头部，这里主要可以做邮件通知报警等的设置，此处就暂不配置了；global_defs {
        #notificationd LVS_DEVEL}#预先定义一个脚本，方便后面调用，也可以定义多个，方便选择；vrrp_script chk_haproxy {
    script "/etc/keepalived/chkmysql.sh"  #具体脚本路径
    interval 2  #脚本循环运行间隔}#VRRP虚拟路由冗余协议配置vrrp_instance VI_1 {   #VI_1 是自定义的名称；
    state BACKUP    #MASTER表示是一台主设备，BACKUP表示为备用设备【我们这里因为设置为开启不抢占，所以都设置为备用】
    nopreempt      #开启不抢占
    interface eth0   #指定VIP需要绑定的物理网卡
    virtual_router_id 11   #VRID虚拟路由标识，也叫做分组名称，该组内的设备需要相同
    priority 130   #定义这台设备的优先级 1-254；开启了不抢占，所以此处优先级必须高于另一台

    advert_int 1   #生存检测时的组播信息发送间隔，组内一致
    authentication {    #设置验证信息，组内一致
        auth_type PASS   #有PASS 和 AH 两种，常用 PASS
        auth_pass asd    #密码
    }
    virtual_ipaddress {
        172.23.252.200    #指定VIP地址，组内一致，可以设置多个IP
    }
    track_script {    #使用在这个域中使用预先定义的脚本，上面定义的
        chk_haproxy    }

    #notify_backup "/etc/init.d/haproxy restart"   #表示当切换到backup状态时,要执行的脚本
    #notify_fault "/etc/init.d/haproxy stop"     #故障时执行的脚本}

/etc/keepalived/chkmysql.sh

$ cat /etc/keepalived/chkmysql.s.sh#!/bin/bashmysql -uroot -proot -P 3314 -e "show status;" > /dev/null 2>&1if [ $? == 0 ];then
        echo "$host mysql login successfully"
        exit 0else
        echo "$host login failed"
        killall keepalived        exit 2fi

以上がMySQL レプリケーション アーキテクチャをマスターする方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。