介紹
MGR 即 MySQL Group Replication 基于原生復制和paxos協(xié)議的組復制技術, 以插件方式提供 , 可動態(tài)新增和移除節(jié)點, 分為單主和多主模式芽唇。
18.1 Group Replication Background
- MGR通訊協(xié)議 Group Communication System (GCS) ,基于Paxos 算法實現(xiàn)
18.1.1 復制技術
-
異步復制
image.png -
半同步復制
image.png -
組復制
分為單主模式(單點寫)和多主模式(多點可寫)
組復制shared-nothing復制方案,每個server有完整數(shù)據(jù)副本
寫事務需要組內(nèi)沖突檢測,通過才能提交,只讀事務不需要
性能瓶頸更大幾率在沖突檢測(內(nèi)存/網(wǎng)絡)而非IO
image.png
18.1.2 組復制用例
MGR盡可能保證集群可用,但當一個節(jié)點奔潰時,連接到db的客戶端需要重定向到其他節(jié)點,MGR不負責重定向, 可以用其他負載均衡夏跷、路由等中間件,也可用用 MySQL Router深胳。
18.1.3 多主和單主模式
設置單主or多主group_replication_single_primary_mode 撑蚌，所有server配置需相同厅须，默認ON表示單主,OFF多主丸逸。
8.0.13開始可以通過函數(shù)在線切換單主與多主模式:
group_replication_switch_to_single_primary_mode()
group_replication_switch_to_multi_primary_mode()
18.1.3.1 單主模式
單主模式group_replication_single_primary_mode=ON 只有M節(jié)點可寫,其他只讀脖律。
group_replication_enforce_update_everywhere_checks單主模式下必須OFF牺弹，多主設置為ON(嚴格檢測)
主選舉場景:
1.當前M離開(主動or被動)
2.SELECT group_replication_set_as_primary(member_uuid);
3.SELECT group_replication_switch_to_single_primary_mode(member_uuid);選舉算法
如果集群中MySQL版本不同,選舉將用最低版本server對應的選舉算法
1.如果所有組成員>=MySQL 8.0.17喇澡，則按小版本排序迅栅。如果任何成員<MySQL 8.0.16，則按主要版本排序晴玖，忽略小版本读存。
2.group_replication_member_weight 權重(0-100为流，默認50),大值優(yōu)先選為M, 如果有5.7則忽略(應該是5.7和8.0混部情況,需測試)
3.權限相同情況下,根據(jù)server_uuid排序查看當前主
1.SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
2.SHOW STATUS LIKE 'group_replication_primary_member' # 將來此變量會被移除
18.1.3.2 多主模式
MySQL 8.0.14 開始新增參數(shù)group_replication_consistency控制事務一致性,動態(tài)可更改, 更改后不需要重啟MGR集群, 支持session級別。
group_replication_enforce_update_everywhere_checks多主模式下一定要設置成ON（雖然可為OFF让簿，但不建議）
- 事務檢查
1.不允許SERIALIZABLE 隔離級別敬察。
2.不支持外鍵。
18.1.4 Group Replication Services
18.1.4.1 Group Membership
group_replication_member_expel_timeout=5
(8.0.13引入≥8.0.21默認5)成員從被懷疑到被踢出集群的等待時間,不包含前期常監(jiān)測異時間,如果網(wǎng)絡環(huán)境不好,可適當調(diào)高; 0表示不等待,可動態(tài)修改立即生效,不同節(jié)點可設置不同值(但建議相同值);最大3600s,但需要足夠大XCom緩存(group_replication_message_cache_size )group_replication_unreachable_majority_timeout=5
默認0,可動態(tài)修改立即生效,指成員因網(wǎng)絡分區(qū)無法連接到其他大部分成員而離開集群前等待的秒數(shù)尔当。
5個server(S1,S2,S3,S4,S5)組成一個集群,如果(S1,S2)和(S3,S4,S5)之間斷開,則表示存在了網(wǎng)絡分區(qū),(S1,S2)屬于少數(shù),將等待指定秒數(shù)后脫離集群,(S3,S4,S5)繼續(xù)運行莲祸。
默認0，意味著由于網(wǎng)絡分區(qū)而處于少數(shù)狀態(tài)的成員將永遠等待脫離集群(會一直等待,不會因為網(wǎng)絡分區(qū)而導致成員脫離組)椭迎。>0 則當指定時間過期時,少數(shù)分區(qū)處理的所有掛起事務都將回滾,少數(shù)分區(qū)中的服務器狀態(tài)變成ERROR
如果設置了group_replication_autorejoin_tries>0則成員會以超級只讀模式嘗試,嘗試完后執(zhí)行group_replication_exit_state_action指定動作锐帜。
注意,如果分區(qū)對等4個server(S1,S2,S3,S4)分區(qū)成(S1,S2)和(S3,S4)則不存在大部分成員,則所有成員變成ERROR狀態(tài)group_replication_autorejoin_tries=3
(8.0.16引入≥8.0.21默認3)組成員被驅(qū)逐出組或失聯(lián)達到超時時間后,嘗試自動重新加入組的次數(shù)⌒蠛牛可動態(tài)修改立即生效, >0時每次嘗試后會等待5分鐘再進行下一一次嘗試直到達到設置嘗試值缴阎。group_replication_exit_state_action=READ_ONLY
(≥8.0.16 默認READ_ONLYM,可選ABORT_SERVER,OFFLINE_MODE,READ_ONLY),可動態(tài)修改立即生效,表示成員意外離開組時的動作行為
READ_ONLY 成員變成只讀模式super_read_only=1
ABORT_SERVER 成員會變成離線模式offline_mode=1 , 此模式下,已連接客戶端在下一個請求時會斷開連接,并拒絕再連接,但CONNECTION_ADMIN權限(和將廢除的SUPER權限)的客戶端用戶除外。
組復制線程還會將系統(tǒng)變量super_read_only設置為ON,因此客戶端無法進行任何更新,即使有CONNECTION_ADMIN或super權限連接弄兜。MySQL 8.0.18起支持OFFLINE_MODE药蜻。
OFFLINE_MODE 成員會關閉mysql服務group_replication_message_cache_size=1073741824
默認1G,所有成員配置最好相同,可動態(tài)設置但是需要重啟MGR進程; 通信引擎XCom中可用于消息緩存的最大內(nèi)存,
XCom包含成員間通訊信息及元數(shù)據(jù),另外可用于與其他組成員無法通信一段時間后重連到組的成員恢復丟失的消息。
從8.0.21開始,最小可設置128M用于低配機器,但要注意緩存結(jié)構還需要額外50M內(nèi)存(一句話,配置不高就別上MGR)
18.1.4.2 Failure Detection
18.1.4.3 Fault-tolerance
| Group Size | Majority | Instant Failures Tolerated |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
18.1.4.4 Observability
18.1.5 Group Replication Plugin Architecture
18.2 Getting Started
18.3 Requirements and Limitations
18.3.1 Group Replication Requirements
Infrastructure
- InnoDB Storage Engine
配置中文件增加disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" - Primary Keys
每個表必須有PK或者非null的unique key
可以設置sql_require_primary_key=ON(默認OFF), 和CHANGE REPLICATION SOURCE TO時設置REQUIRE_TABLE_PRIMARY_KEY_CHECK=ON - Network Performance
不用說了
Server Instance Configuration
Unique Server Identifier
server-id 不用說了Binary Log Active
log-bin 啟用binlog,這也不用說了Replica Updates Logged
log_replica_updates=ON (from MySQL 8.0.26) or log_slave_updates=ON (before MySQL 8.0.26)Binary Log Row Format
binlog_format=row 必須是row格式Binary Log Checksums Off (to MySQL 8.0.20)
<=8.0.20, binlog_checksum=NONE , >=8.0.21 MGR支持binlog_checksum=CRC32Global Transaction Identifiers On
gtid_mode=ON and enforce_gtid_consistency=ON 必須啟用GTID模式Replication Information Repositories
master_info_repository=TABLE and relay_log_info_repository=TABLE 從MySQL 8.0開始放棄FILE吧Transaction Write Set Extraction
transaction_write_set_extraction=XXHASH64 從MySQL 8.0.26開始此變量將成為默認值,后期此變量可能被移除Default Table Encryption
default_table_encryption 所有成員設置需相同,默認OFFLower Case Table Names
lower_case_table_names 所有成員設置需相同,默認0Binary Log Dependency Tracking
binlog_transaction_dependency_tracking 所有成員保持一致, WRITESET_SESSION可以提高性能,默認COMMIT_ORDER,還可選WRITESET,數(shù)據(jù)安全嚴格要求下用默認值替饿。
如果 transaction_write_set_extraction=OFF 那只能為COMMIT_ORDERMultithreaded Appliers
slave_parallel_type = LOGICAL_CLOCK # replica_parallel_type=LOGICAL_CLOCK (from MySQL 8.0.26)
slave_parallel_workers = 16 # replica_parallel_workers=16 (from MySQL 8.0.26)
slave_preserve_commit_order = 1 # replica_preserve_commit_order=ON (from MySQL 8.0.26)
18.3.2 Group Replication Limitations
- --upgrade=MINIMAL
- Gap Locks
- Table Locks and Named Locks
- Binary Log Checksums
從8.0.21支持binlog_checksum=CRC32 - SERIALIZABLE Isolation Level
多主模式不支持 - Concurrent DDL versus DML Operations.
多主模式下不能不同server并發(fā)對一個對象ddl dml操作语泽。 - Foreign Keys with Cascading Constraints.
- Multi-primary Mode Deadlock.
多主模式下SELECT .. FOR UPDATE可能導致死鎖 - Replication Filters
千萬別配置filter,特別是配置文件(防止意外重啟啟用),8.0可以查詢performance_schema.replication_applier_global_filters,5.7無系統(tǒng)視圖 - Encrypted Connections
- Cloning Operations
