資訊專欄INFORMATION COLUMN
基于傳統異步復制和半同步復制的缺陷——數據的一致性問題無法保證，MySQL官方在5.7.17版本正式推出組復制（MySQLGroupReplication，簡稱MGR），以插件形式提供，實現了分布式下數據的最終一致性,提供了高可用、高擴展、高可靠的MySQL集群服務。
MGR是一種可用于實現容錯系統的技術。復制組是一個通過消息傳遞相互交互的Server集群，由多個Server成員組成，如上圖的Master1、Master2、Master3，所有成員獨立完成各自的事務。
當客戶端發起一個更新事務時，該事務先在本地執行，執行完成之后就要發起對事務的提交操作。在還沒有真正提交之前，需要將產生的復制寫集(WRITESET)廣播出去，復制到其它成員。如果沖突檢測成功，組內決定該事務可以提交，其它成員可以應用，否則就回滾。
最終，所有組內成員以相同的順序接收同一組事務。因此組內成員以相同的順序應用相同的修改，保證組內數據強一致性。從MGR復制原理上看，當主節點事務提交時，輔助節點上可能還未重放該事務對應的BINLOG，因此MGR仍屬于異步復制。
本次僅配置MGR的單主模式，采用了三臺linux虛機：
IP | SERVER_ID | 服務端口 | 通信端口 |
192.168.100.110 | 1 | 3306 | 10086 |
192.168.100.111 | 2 | 3306 | 10086 |
192.168.100.112 | 3 | 3306 | 10086 |
編輯mysql參數文件，3個節點除了server_id、loose-group_replication_local_address參數不一樣外，其他保持一致，因為僅演示，參數僅配置需要的參數。
192.168.100.110：
[mysqld] datadir=/data/data3306 socket=/data/data3306/mysql3306.sock user=mysql log-bin=mysql-bin server-id = 1 port=3306 pid-file=/data/data3306/pid3306.pid innodb-buffer-pool-size=300m basedir=/opt/mysql log-error=/data/data3306/3306.err.log sync_binlog = 1 auto-increment-increment = 2 auto-increment-offset = 1 slave-skip-errors = all explicit_defaults_for_timestamp=ON gtid_mode=ON enforce_gtid_consistency=ON master_info_repository=TABLE relay_log_info_repository=TABLE binlog_checksum=NONE log_slave_updates=ON log_bin=binlog binlog_format=ROW #super_read_only=ON slave_parallel_type=logical_clock slave_parallel_workers=16 slave_preserve_commit_order=ON transaction_write_set_extraction=XXHASH64 loose-group_replication_single_primary_mode = true loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" loose-group_replication_start_on_boot=off loose-group_replication_local_address= "mysql-master:10086" loose-group_replication_group_seeds= "mysql-master:10086,mysql-slave:10086,Oracle19c:10086" loose-group_replication_bootstrap_group= off loose-group_replication_enforce_update_everywhere_checks = false |
192.168.100.111：
server-id = 2 loose-group_replication_local_address= "mysql-slave:10086" |
192.168.100.110：
server-id = 3 loose-group_replication_local_address= "Oracle19c:10086"——無視亂入的主機名。。。 |
關于GTID及日志信息記錄相關參數：
gtid_mode=on打開GTID特性
enforce-gtid-consistency=on
master_info_repository=TABLE
relay_log_info_repository=TABLE
binlog_format=ROW 必須使用基于行的格式
binlog_checksum=NONE 禁用二進制日志事件校驗和
關于MGR相關參數說明：
transaction_write_set_extraction #記錄事務的算法
group_replication_start_on_boot#是否隨服務器啟動而自動啟動組復制
group_replication_bootstrap_group#引導組成員的組，這個用于第一次搭建MGR跟重新搭建MGR的時候使用
group_replication_group_name #此GROUP的名字，必須是一個有效的UUID，以此來區分整個內網里邊的各個不同的GROUP
group_replication_local_address#本地的IP地址字符串，host:port
group_replication_group_seeds #需要接受本實例的信息服務器IP地址字符串
group_replication_single_primary_mode#是否啟動單主模式，如果啟動，則本實例是主庫，提供讀寫，其他實例僅提供讀
group_replication_enforce_update_everywhere_checks#多主模式下，強制檢查每一個實例是否允許該操作
mysql>INSTALL PLUGIN group_replication SONAME group_replication.so; |
SET SQL_LOG_BIN=0; CREATE USER repl@% IDENTIFIED BY 123; GRANT REPLICATION SLAVE ON *.* TO repl@%; FLUSH PRIVILEGES; SET SQL_LOG_BIN=1; CHANGE MASTER TO MASTER_USER=repl, MASTER_PASSWORD=123 FOR CHANNEL group_replication_recovery; |
SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group=OFF; |
START GROUP_REPLICATION; |
*設置復制賬號時，應全部操作不寫bin_log，即可不需要使用“setglobal group_replication_allow_local_disjoint_gtids_join=ON;”
可以看到，一個單主模式的MGR已經配置成功。下面來做一些同步驗證。
主庫（192.168.100.111）建庫建表，并插入數據：
192.168.100.112：
192.168.100.110：
可以看到，在主庫執行的操作均在組內其他節點得以回放，驗證成功。
篇幅有限，關于MGR的簡單介紹只能到這里，更多關于MGR特性的演示，只能后續再給大家呈現了，希望有興趣的小伙伴一起交流學習。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/130114.html
摘要：對于該故障的分析，我們要從主從實例相同，但是事務不同的原因入手，該問題猜測與相關，我們針對同步事務的時序做如下分析。接受者被動接收提議者的提議，并記錄和反饋，或學習達成共識的提議。節點將的提案信息發送至組內，仍收到了大多數成員返回。 本文是由愛可生運維團隊出品的「MySQL專欄」系列文章，內容來自于運維團隊一線實戰經驗，涵蓋MySQL各種特性的實踐，優化案例，數據庫架構，HA，監控等...
閱讀 1353·2023-01-11 13:20
閱讀 1699·2023-01-11 13:20
閱讀 1211·2023-01-11 13:20
閱讀 1902·2023-01-11 13:20
閱讀 4161·2023-01-11 13:20
閱讀 2748·2023-01-11 13:20
閱讀 1397·2023-01-11 13:20
閱讀 3664·2023-01-11 13:20
