MySQL レプリケーションアーキテクチャを完全に習得する-mysql チュートリアル-php.cn

この記事では、mysql に関する関連知識を提供し、マスター/スレーブレプリケーションアーキテクチャ、カスケードレプリケーションアーキテクチャ、マルチマスター/スレーブレプリケーションなど、レプリケーションアーキテクチャに関する関連問題を主に紹介します。建築など、皆様のお役に立てれば幸いです。

MySQL レプリケーションアーキテクチャを完全に習得する

推奨学習: mysql ビデオチュートリアル

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

実際のアプリケーションシナリオでは、 MySQL レプリケーションの 90% 以上は、1 つのマスターが 1 つ以上のスレーブにレプリケートするアーキテクチャモデルです。

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

MySQL レプリケーションアーキテクチャを完全に習得する

欠点:

マスターはシャットダウンできず、シャットダウンすると書き込みリクエストを受信できません
スレーブが多すぎると遅延が発生します

定期メンテナンスでマスターをシャットダウンする必要があるため、スレーブをマスターに変換する必要があります。 ?

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

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

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

MySQL レプリケーションアーキテクチャを完全に習得する

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

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

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

以下に示すように。

MySQL レプリケーションアーキテクチャを完全に習得する

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 であるユーザーテーブルにはデータがありません。

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

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

MySQL レプリケーションアーキテクチャを完全に習得する

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

ホスト計画:

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      # 要同步的数据库

ログイン後にコピー

Start 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

ログイン後にコピー

[To] で追加コピーしたユーザーを指定して承認します:

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高可用的搭建

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视频教程

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