mysql带唯一主建任然发生gap,MySQL组复制(二)

配置复制组

更改primary

查看当前主节点1root&＃64;(none) 02:12: SELECT * FROM performance_schema.replication_group_members;

指定新的主节点进行切换

1root&＃64;(none) 02:12: SELECT group_replication_set_as_primary(&＃39;d1fbe050-5ecf-11eb-a88d-0050569c8f5e&＃39;);

查看进度

1root&＃64;(none) 02:12: SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";

更改复制模式

更改为单主模式

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16###停止复制

mysql> stop group_replication;

###关闭一致性检查

mysql> set global group_replication_enforce_update_everywhere_checks&＃61;OFF;

###开启单主模式

mysql> set global group_replication_single_primary_mode&＃61;ON;

###主节点引导组复制

mysql> set global group_replication_bootstrap_group&＃61;ON;

mysql> start group_replication

mysql> set global group_replication_bootstrap_group&＃61;OFF;

###其它节点加入组复制

mysql> start group_replication

Tips&＃xff1a;也可以采用SELECT group_replication_switch_to_single_primary_mode(member_uuid)直接进行切换

更改为多主模式

1

2

3

4

5

6

7

8

9

10###停止复制

mysql> stop group_replication;

###关闭单主

mysql> set global group_replication_single_primary_mode&＃61;OFF;

###启动复制

mysql> set global group_replication_bootstrap_group&＃61;ON;

mysql> start group_replication;

mysql> set global group_replication_bootstrap_group&＃61;OFF;

Tips&＃xff1a;也可以采用SELECT group_replication_switch_to_multi_primary_mode()直接进行切换

查看进度

1mysql> SELECT event_name, work_completed, work_estimated FROM performance_schema.events_stages_current WHERE event_name LIKE "%stage/group_rpl%";

配置最大共识实例数

这个最大值被称为组的事件范围&＃xff0c;是组可以并行执行的最大共识实例数。

查看复制组写入并发性

1mysql> SELECT group_replication_get_write_concurrency();

配置写入并发(需要GROUP_REPLICATION_ADMIN权限)

1mysql> SELECT group_replication_set_write_concurrency(instances);

设置组通信协议版本

从MySQL 8.0.16开始&＃xff0c;组复制有了组通信协议的概念。可以显式管理组复制通信协议版本&＃xff0c;并将其设置为适应您希望组支持的最老的MySQL Server版本。这使得组可以由不同MySQL Server版本的成员组成&＃xff0c;同时确保向后兼容性。

查看当前通信协议版本

1mysql> SELECT group_replication_get_communication_protocol();

修改通信协议版本

1SELECT group_replication_set_communication_protocol("5.7.25");

Tips&＃xff1a;当升级组复制成员MySQL Version后&＃xff0c;通信协议并不会自动更新&＃xff0c;我们可以手动升级协议版本

事务一致性保证

就分布式一致性保证而言&＃xff0c;无论是在正常或故障修复的情况下&＃xff0c;组复制始终是一个最终一致性的系统。与系统一致性相关的事件包含控制操作和数据流操作&＃xff0c;对于组复制&＃xff0c;可以根据一致性评估的控制操作为&＃xff1a;

成员加入或离开

网络故障

单主模式下&＃xff0c;主节点故障切换或通过group_replication_set_as_primary()重新选主

在单主模式下&＃xff0c;当主节点发生故障进行转移时&＃xff0c;新的主节点可以立即应用程序流量&＃xff0c;不管有多少事务复制积压。这种情况写一致性得到了保证&＃xff0c;但是在新节点应用backlog中的事务前可能检索到过时数据&＃xff0c;无法保证读一致性。如果采用8.0.14或更高版本时&＃xff0c;可以在主节点故障切换期间使用group_replication_consistency变量配置成员提供的事务一致性保证级别。该参数有下列选择

EVENTUAL&＃xff1a;RO和RW事务在执行之前都不等待前面的事务被应用(8.0.14前的唯一选择)

BEFORE&＃xff1a;确保本地强一致性&＃xff0c;并不保证其它节点数据实时同步&＃xff0c;可能造成当前节点读延迟

AFTER&＃xff1a;确保全局一致性&＃xff0c;可以保证所有节点数据实时同步&＃xff0c;可能造成所有节点都延迟

BEFORE_AND_AFTER&＃xff1a;最高级别&＃xff0c;结合BEFORE和AFTER来确保本地和全局强一致性

BEFOR_ON_PRIMARY_FAILOVER&＃xff1a; 确保新主的本地一致性&＃xff0c;在新选出的主节点上保存新事务&＃xff0c;直到应用完积压事务为止

一致性级别的影响

围绕一致性级别对事务的影响我们通过下列案例来重点说明EVENTUAL、BEFORE和AFTER选项的影响

节点

角色

节点1

主

节点2

只读

节点3

只读

现有如下表

1

2

3

4

5

6

7

8

9

10root&＃64;test 04:19: show create table t1;\

&＃43;-------&＃43;-------------------------------------------------------------------------------------&＃43;

| Table | Create Table |

&＃43;-------&＃43;-------------------------------------------------------------------------------------&＃43;

| t1 | CREATE TABLE &＃96;t1&＃96; (

&＃96;id&＃96; int NOT NULL,

&＃96;r1&＃96; int DEFAULT NULL,

&＃96;r2&＃96; int DEFAULT NULL,

PRIMARY KEY (&＃96;id&＃96;)

) ENGINE&＃61;InnoDB DEFAULT CHARSET&＃61;utf8mb4 COLLATE&＃61;utf8mb4_unicode_ci |

插入一条数据&＃xff0c;其它节点也能正常读取到

1

2

3

4

5

6

7

8

9root&＃64;test 04:21: insert into t1 values (1,2,&＃64;&＃64;server_id);

Query OK, 1 row affected (0.00 sec)

root&＃64;test 04:21: select * from t1;

&＃43;----&＃43;------&＃43;------&＃43;

| id | r1 | r2 |

&＃43;----&＃43;------&＃43;------&＃43;

| 1 | 2 | 2109 |

&＃43;----&＃43;------&＃43;------&＃43;

查看一致性级别

1

2

3

4

5

6root&＃64;test 04:23: show variables like &＃39;group_replication_consistency&＃39;;

&＃43;-------------------------------&＃43;----------&＃43;

| Variable_name | Value |

&＃43;-------------------------------&＃43;----------&＃43;

| group_replication_consistency | EVENTUAL |

&＃43;-------------------------------&＃43;----------&＃43;

在节点2上手动添加read锁

1

2root&＃64;test 04:21: lock table t1 read;

Query OK, 0 rows affected (0.00 sec)

再次插入新数据

1

2root&＃64;test 04:21: insert into t1 values (2,3,&＃64;&＃64;server_id);

Query OK, 1 row affected (0.01 sec)

在节点2上并未读取到新插入的数据

1

2

3

4

5

6root&＃64;test 04:23: select * from t1;

&＃43;----&＃43;------&＃43;------&＃43;

| id | r1 | r2 |

&＃43;----&＃43;------&＃43;------&＃43;

| 1 | 2 | 2109 |

&＃43;----&＃43;------&＃43;------&＃43;

释放锁之后就能读取最新数据

1

2

3

4

5

6

7

8

9

10root&＃64;test 04:26: unlock tables;

Query OK, 0 rows affected (0.00 sec)

root&＃64;test 04:26: select * from t1;

&＃43;----&＃43;------&＃43;------&＃43;

| id | r1 | r2 |

&＃43;----&＃43;------&＃43;------&＃43;

| 1 | 2 | 2109 |

| 2 | 3 | 2109 |

&＃43;----&＃43;------&＃43;------&＃43;

下面将节点2的级别调整为before进行测试

1root&＃64;test 04:26: set &＃64;&＃64;group_replication_consistency&＃61;&＃39;before&＃39;;

再次加锁

1root&＃64;test 04:29: lock table t1 read;

节点1插入新数据

1root&＃64;(test) 04:29: insert into t1 values (3,4,&＃64;&＃64;server_id);

这时发现&＃xff0c;再去节点2查询表会hang住&＃xff0c;需要等待本地数据完全应用。节点3则正常查询

下面将节点2的级别调整为AFTER

1

2root&＃64;(test) 04:34: set &＃64;&＃64;group_replication_consistency&＃61;&＃39;after&＃39;;

Query OK, 0 rows affected (0.00 sec)

重复加锁的过程

1root&＃64;(test) 04:35: lock table t1 read;

在节点1插入新数据

1root&＃64;(test) 04:35: insert into t1 values (3,4,&＃64;&＃64;server_id);

这时会发现插入处于等待状态&＃xff0c;并没有完成&＃xff0c;因为节点2上的表被锁了&＃xff0c;无法完成日志应用。节点2查询成功&＃xff0c;但都为陈旧数据。节点3上的查询也需要等待其它从节点日志应用完成才能返回结果&＃xff0c;而不是返回陈旧数据。当节点2释放锁之后&＃xff0c;节点1的插入完成&＃xff0c;节点3的查询也返回了最新数据。

单主模式发生故障转移后&＃xff0c;为避免在EVENTUAL选项下RO事务可能读取到过时数据导致的一致性问题&＃xff0c;建议使用适当的流控设置&＃xff0c;减小事务积压的可能。并将一致性级别设置为BEFORE_ON_PRIMARY_FAILOVER。尽管在使用BEFORE_ON_PRIMARY_FAILOVER一致性级别时&＃xff0c;所有写操作都被挂起&＃xff0c;但并不是所有读操作都被阻塞&＃xff0c;我们任然可以执行一些运维管理命令。