mysql 的节点组是什么_【MySQL 组复制】1.组复制技术简介

最新推荐文章于 2021-09-28 17:45:16 发布

weixin_39629969

最新推荐文章于 2021-09-28 17:45:16 发布

阅读量115

点赞数

文章标签： mysql 的节点组是什么

本文链接：https://blog.csdn.net/weixin_39629969/article/details/113418144

版权

组复制有两种模式

单主模式(single-primary/single-master)下自动选举出一个主节点，从而只允许在同一时刻只有该主节点可以更新数据。

对于MySQL的高级使用人员，可以通过复制组实现多主模型(multi-primary)，这种模型下，所有的主节点都可以在同一时刻接受更新操作，即并发写。

MySQL组复制有一个内置的组成员服务(group membership service)，该服务动态维护组中成员以及可用成员的信息视图。每当有成员离开，加入的时候这个视图都会随之更新。

如果某MySQL实例在非预期的情况下离开了组，失败探测机制可以探测出这种情况并通知组，告知视图已经更改，这是自动完成的。

什么是MGR

MGR(MySQL Group Replication)是MySQL官方在MySQL 5.7.17版本中以插件形式推出的主从复制高可用技术，它基于原生的主从复制，将各节点归入到一个组中，通过组内节点的通信协商(组通信协议基于Paxos算法)，实现数据的强一致性、故障探测、冲突检测、节点加组、节点离组等等功能。

这3个节点互相通信，每当有事件发生，都会向其他节点传播该事件，然后协商，如果大多数节点都同意这次的事件，那么该事件将通过，否则该事件将失败或回滚。

这些节点可以是单主模型的(single-primary)，也可以是多主模型的(multi-primary)。单主模型只有一个主节点可以接受写操作，主节点故障时可以自动选举主节点。多主模型下，所有节点都可以接受写操作，所以没有master-slave的概念。

MGR配置

1.配置环境

S1:10.16.208.5:6005

S2:10.16.208:4:6005

S3:10.16.18.3:6005

S1《--》S2《--》S3

配置时确保3哥节点的主机名不一样

配置组内第一个节点S1

1.修改配置文件

[mysqld]

datadir=/data

socket=/data/mysql.sock

server-id=11701 # 必须

gtid_mode=on # 必须

enforce_gtid_consistency=on # 必须

log-bin=/data/master-bin # 必须

binlog_format=row # 必须

binlog_checksum=none # 必须

master_info_repository=TABLE # 必须

relay_log_info_repository=TABLE # 必须

relay_log=/data/relay-log # 必须，如果不给，将采用默认值

log_slave_updates=ON # 必须

sync-binlog=1 # 建议

log-error=/data/error.log

pid-file=/data/mysqld.pid

transaction_write_set_extraction=XXHASH64 #必须

loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" #必须

loose-group_replication_start_on_boot=off #建议设置OFF

loose-group_replication_member_weigth = 40 #非必须,5.7.20开始支持

loose-group_replication_local_address="10.16.208.5:26005" #必须

loose-group_replication_group_seeds="10.16.208.5:26005,10.16.208.4:26005" #必须

(1).因为组复制基于GTID，所以必须开启gtid_mode和enforce_gtid_consistency。

(2).组复制必须开启二进制日志，且必须设置为行格式的二进制日志，这样才能从日志记录中收集信息且保证数据一致性。所以设置log_bin和binlog_format。

(3).由于MySQL对复制事件校验的设计缺陷，组复制不能对他们校验，所以设置binlog_checksum=none。

(4).组复制要将master和relay log的元数据写入到mysql.slave_master_info和mysql.slave_relay_log_info中。

(5).组中的每个节点都保留了完整的数据副本，它是share-nothing的模式。所以所有节点上都必须开启log_slave_updates，这样新节点随便选哪个作为donor都可以进行异步复制。

(6).sync_binlog是为了保证每次事务提交都立刻将binlog刷盘，保证出现故障也不丢失日志。

(7).最后的6行是组复制插件的配置。以loose_开头表示即使启动组复制插件，MySQL也继续正常允许下去。这个前缀是可选的。

(8).倒数第6行表示写集合以XXHASH64的算法进行hash。所谓写集，是对事务中所修改的行进行的唯一标识，在后续检测并发事务之间是否修改同一行冲突时使用。它基于主键生成，所以使用组复制，表中必须要有主键。

(9).倒数第5行表示这个复制组的名称。它必须是一个有效的UUID值。嫌可以直接和上面一样全写字母a。在Linux下，可以使用uuidgen工具来生成UUID值。

[root@xuexi ~]# uuidgen

09c38ef2-7d81-463e-bdb4-9459b2c0e49b

(10).倒数第4行表示组复制功能不随MySQL实例启动而启动。虽然，可以将组复制插件和启动组复制功能的选项写在配置文件里，但强烈建议不要如此，而是每次手动去配置。

(11).倒数第3行表示该节点在组中的权重为40。权重越高，自动选举为primary节点的优先级就越高。

(12).倒数第2行表示本机上用于组内各节点之间通信的地址和端口。

(13).最后一行，设置本组的种子节点。种子节点的意义在前文已经解释过了。

现在配置文件已经提供。可以启动mysql实例了。

[root@xuexi ~]# systemctl start mysqld

./mysql.server restart

2.创建复制用户

GRANT REPLICATION SLAVE ON *.* TO 'dmrepl'@'10.%.%.%'

3.配置节点加组时的通道,(关键)

在新节点加入组时，首先要选择donor。新节点和donor之间的异步复制就是通过一个名为group_replication_recovery的通道(通道名固定，不可使用自定义通道)进行数据恢复的，经过数据恢复后，新节点填充了它缺失的那部分数据，这样就和组内其他节点的数据保持了同步。

这个恢复过程比较复杂，它是一种分布式恢复。

change master to

master_user='repl',

master_password='P@ssword1!'

for channel 'group_replication_recovery';

这里的用户名、密码和通道在组复制中有一个专门的术语：通道凭据(channel credentials)。通道凭据是连接donor的关键。

当执行完上面的语句后，就生成了一个该通道的relay log文件(注意称呼：该通道的relay log，后面还有另一个通道的relay log)。如下，其中前缀"relay-log"是配置文件中"relay_log"选项配置的值。

-rw-r----- 1 mysql mysql 150 Feb 25 15:22 relay-log-group_replication_recovery.000001

-rw-r----- 1 mysql mysql 83 Feb 25 15:22 relay-log-group_replication_recovery.index

group_replication_recovery通道的relay log用于新节点加入组时，当新节点联系上donor后，会从donor处以异步复制的方式将其binlog复制到这个通道的relay log中，新节点将从这个recovery通道的relay log中恢复数据。

4.安装组复制插件启动组复制功能

install plugin group_replication soname 'group_replication.so';

启动组复制

(admin@g1-db-test-v07:6005)[(none)]>set global group_replication_bootstrap_group=ON;

Query OK, 0 rows affected (0.00 sec)

(admin@g1-db-test-v07:6005)[(none)]>start group_replication;

Query OK, 0 rows affected (2.13 sec)

(admin@g1-db-test-v07:6005)[(none)]>set group_replication_bootstrap_group=OFF;

这里的过程很重要，需要引起注意。在开启组复制之前，设置全局变量group_replication_bootstrap_group为on，这表示稍后启动的组复制功能将引导组，也就是创建组并配置组，这些都是自动的。配置引导变量为ON后，再开启组复制插件功能，也就是启动组复制。最后将引导变量设回OFF，之所以要设置回OFF，是为了避免下次重启组复制插件功能时再次引导创建一个组，这样会存在两个名称相同实际却不相同的组。

这几个过程不适合放进配置文件中，强烈建议手动执行它们的。否则下次重启mysql实例时，会自动重新引导创建一个组。同理，除了第一个节点，其他节点启动组复制功能时，不应该引导组，所以只需执行其中的start语句，千万不能开启group_replication_bootstrap_group变量引导组。

这里的几个过程，应该形成一个习惯，在启动第一个节点时，这3条语句同时执行，在启动其他节点时，只执行start语句。

-rw-r----- 1 mysql mysql 219 Feb 25 15:33 relay-log-group_replication_applier.000001

-rw-r----- 1 mysql mysql 638 Feb 25 15:33 relay-log-group_replication_applier.000002

-rw-r----- 1 mysql mysql 164 Feb 25 15:33 relay-log-group_replication_applier.index

-rw-r----- 1 mysql mysql 150 Feb 25 15:22 relay-log-group_replication_recovery.000001

-rw-r----- 1 mysql mysql 83 Feb 25 15:22 relay-log-group_replication_recovery.index

是否还记得刚才用于恢复的通道group_replication_recovery？这个applier通道是干什么的？常规复制有两个复制线程：io线程和sql线程，在组复制中，不再称之为io_thread和sql_thread，取而代之的是receiver、certifier和applier。这里简单介绍一下它们的作用：

receiver的作用类似于io线程，用于接收组内个节点之间传播的消息和事务。也用于接收外界新发起的事务。

applier的作用类似于sql线程，用于应用relay log中的记录。不过，组复制的relay log不再是relay log，而是这里的组复制relay log：relay-log-group_replication_applier.00000N。

certifier的作用在receiver接收到消息后，验证是否有并发事务存在冲突问题。冲突检测通过后，这条消息就会写入到组复制的relay log中，等待applier去应用。

并不是说组复制中没有io线程和sql线程，而是称呼改变了，receiver和applier实际上就是io_therad和sql_thread。

5.验证组中节点并测试插入不满足组复制要求的数据

(admin@g1-db-test-v07:6005)[(none)]>select * from performance_schema.replication_group_members;

+---------------------------+--------------------------------------+----------------+-------------+--------------+

+---------------------------+--------------------------------------+----------------+-------------+--------------+

+---------------------------+--------------------------------------+----------------+-------------+--------------+

请注意这里的每一行，包括member_host，它是对外连接的地址，所以应该设置它的DNS解析为提供MySQL数据库服务的接口地址。这很重要，如果你不想去修改DNS解析，可以在启动组复制之前，设置report_host变量为对外的IP地址，或者将其写入到配置文件中。

现在，组中的这个节点已经是ONLINE了，表示可以对外提供组复制服务了。

下面创建4个表：t1和t4是InnoDB表，t3和t4具有主键。

(root@g1-db-test-v07:6005)[jhl]>create table t1(id int);

Query OK, 0 rows affected (0.00 sec)

(root@g1-db-test-v07:6005)[jhl]>create table t2(id int)engine=myisam;

Query OK, 0 rows affected (0.04 sec)

(root@g1-db-test-v07:6005)[jhl]>create table t3(id int primary key)engine=myisam;

Query OK, 0 rows affected (0.00 sec)

(root@g1-db-test-v07:6005)[jhl]>create table t4(id int primary key);

Query OK, 0 rows affected (0.01 sec)

虽说组复制对这些有限制，但是创建时是不会报错的。

向这4张表中插入数据：

(root@g1-db-test-v07:6005)[jhl]>insert into t1 values(1);

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

(root@g1-db-test-v07:6005)[jhl]>insert into t2 values(1);

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

(root@g1-db-test-v07:6005)[jhl]>insert into t3 values(1);

ERROR 3098 (HY000): The table does not comply with the requirements by an external plugin.

(root@g1-db-test-v07:6005)[jhl]>insert into t4 values(1);

Query OK, 1 row affected (0.01 sec)

意思是该表不遵从外部插件(即组复制插件)的要求。

最后，查看下二进制日志中的事件

(root@g1-db-test-v07:6005)[jhl]>show binlog events in 'jhl_master-mysql-bin.000011';

+-----------------------------+------+----------------+-----------+-------------+-------------------------------------------------------------------+

+-----------------------------+------+----------------+-----------+-------------+-------------------------------------------------------------------+

| jhl_master-mysql-bin.000011 | 4 | Format_desc | 11701 | 123 | Server ver: 5.7.24-log, Binlog ver: 4 |

| jhl_master-mysql-bin.000011 | 123 | Previous_gtids | 11701 | 190 | b3f6377f-52c5-11ea-92c4-be6f2b61965c:1-6 |

| jhl_master-mysql-bin.000011 | 190 | Gtid | 11701 | 251 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1' |

| jhl_master-mysql-bin.000011 | 251 | Query | 11701 | 310 | BEGIN |

| jhl_master-mysql-bin.000011 | 310 | View_change | 11701 | 489 | view_id=15826159969082953:1 |

| jhl_master-mysql-bin.000011 | 489 | Query | 11701 | 554 | COMMIT |

| jhl_master-mysql-bin.000011 | 554 | Gtid | 11701 | 615 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:2' |

| jhl_master-mysql-bin.000011 | 615 | Query | 11701 | 711 | use `jhl`; create table t1(id int) |

| jhl_master-mysql-bin.000011 | 711 | Gtid | 11701 | 772 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:3' |

| jhl_master-mysql-bin.000011 | 772 | Query | 11701 | 881 | use `jhl`; create table t2(id int)engine=myisam |

| jhl_master-mysql-bin.000011 | 881 | Gtid | 11701 | 942 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:4' |

| jhl_master-mysql-bin.000011 | 942 | Query | 11701 | 1063 | use `jhl`; create table t3(id int primary key)engine=myisam |

| jhl_master-mysql-bin.000011 | 1063 | Gtid | 11701 | 1124 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:5' |

| jhl_master-mysql-bin.000011 | 1124 | Query | 11701 | 1232 | use `jhl`; create table t4(id int primary key) |

| jhl_master-mysql-bin.000011 | 1232 | Gtid | 11701 | 1293 | SET @@SESSION.GTID_NEXT= 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:6' |

| jhl_master-mysql-bin.000011 | 1293 | Query | 11701 | 1365 | BEGIN |

| jhl_master-mysql-bin.000011 | 1365 | Table_map | 11701 | 1405 | table_id: 112 (jhl.t4) |

| jhl_master-mysql-bin.000011 | 1405 | Write_rows | 11701 | 1441 | table_id: 112 flags: STMT_END_F |

| jhl_master-mysql-bin.000011 | 1441 | Xid | 11701 | 1468 | COMMIT /* xid=105 */ |

+-----------------------------+------+----------------+-----------+-------------+-------------------------------------------------------------------+

需要关注以下3行

BEGIN

View_change view_id=15294216022242634:1

COMMIT

组复制中，每个决策都需要组中大多数节点达成一致，包括新节点加组、离组的决定。实际上，组复制中内置了一个组成员服务，这个服务负责组成员的配置以及动态捕获组中成员列表，这个成员列表成为成员视图。每个视图都有一个view id，view id的第一部分是创建组时随机生成的，只要组不停止，这部分就不改变，第二部分是从1开始的单调递增的数值。每当有成员加组、离组时，都会触发这个服务对组成员进行重新配置，每次组成员的重新配置，view id的第二部分都会单调递增地加1，表示这是新的成员视图，新的组成员视图需要得到组中大多数节点的同意，所以这个消息要在组中进行传播。如何传播？就是通过将视图更改的事件作为一个事务写进binlog中，然后在组中到处复制，这样每个节点都可收到视图变化的消息，并对此做出回应，同意之后再commit这个事务。如果足够细心，会发现这个事务的提交和下面插入数据的提交(COMMIT /* xid=63 */)方式不一样。如果不理解也没关系，这个理论并不影响组复制的使用。

再仔细一看，还可以发现MySQL中的DDL语句是没有事务的。所以，绝不允许不同节点上对同一个对象并发执行"DDL+DML"和"DDL+DDL"，冲突检测机制会探测到这样的冲突。

添加第二个节点

配置文件和节点一类似

datadir=/data

socket=/data/mysql.sock

server-id=11701 # 必须

gtid_mode=on # 必须

enforce_gtid_consistency=on # 必须

log-bin=/data/master-bin # 必须

binlog_format=row # 必须

binlog_checksum=none # 必须

master_info_repository=TABLE # 必须

relay_log_info_repository=TABLE # 必须

relay_log=/data/relay-log # 必须，如果不给，将采用默认值

log_slave_updates=ON # 必须

sync-binlog=1 # 建议

log-error=/data/error.log

pid-file=/data/mysqld.pid

#MGR

transaction_write_set_extraction=XXHASH64

loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"

loose-group_replication_start_on_boot=off

loose-group_replication_member_weigth = 20

loose-group_replication_local_address="10.16.208.4:26005"

loose-group_replication_group_seeds="10.16.208.5:26005,10.16.208.4:26005"

这里和s1的配置文件相比，只修改了server-id和group_replication_local_address以及权重值。

change master to

master_user='repl',

master_password='P@ssword1!'

for channel 'group_replication_recovery';

这时，就已经选择好donor，并和donor建立通道连接了。如果去s1上查看，可以看到这个通道的连接。下面的查询结果中，第二行就是和s2建立的连接，通道为group_replication_recovery。

(root@g1-db-test-v06:6005)[(none)]>select * from mysql.slave_master_info\G

*************************** 1. row ***************************

Number_of_lines: 25

Master_log_name: jhl_master-mysql-bin.000011

Master_log_pos: 1468

Host: 10.16.208.5

User_name: dmrepl

User_password: hn%u0)M9

Port: 6005

Connect_retry: 60

Enabled_ssl: 0

Ssl_ca:

Ssl_capath:

Ssl_cert:

Ssl_cipher:

Ssl_key:

Ssl_verify_server_cert: 0

Heartbeat: 30

Bind:

Ignored_server_ids: 0

Uuid: b3f6377f-52c5-11ea-92c4-be6f2b61965c

Retry_count: 86400

Ssl_crl:

Ssl_crlpath:

Enabled_auto_position: 1

Channel_name:

Tls_version:

*************************** 2. row ***************************

Number_of_lines: 25

Master_log_name:

Master_log_pos: 4

Host:

User_name: dmrepl

User_password: hn%u0)M9

Port: 3306

Connect_retry: 60

Enabled_ssl: 0

Ssl_ca:

Ssl_capath:

Ssl_cert:

Ssl_cipher:

Ssl_key:

Ssl_verify_server_cert: 0

Heartbeat: 0

Bind:

Ignored_server_ids: 0

Uuid:

Retry_count: 86400

Ssl_crl:

Ssl_crlpath:

Enabled_auto_position: 0

Channel_name: group_replication_recovery

Tls_version:

安装组复制插件,启动组复制功能

install plugin group_replication soname 'group_replication.so';

(root@g1-db-test-v06:6005)[(none)]>start group_replication;

ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.

最后发现是一个参数没有改

binlog_checksum=none

然后启动,还是报错

突然想到这个从库之前有单独做过一些操作,GTID和主库不一致,比主库多

然后将GTID重新设置为主库的gtid集合

(root@g1-db-test-v06:6005)[(none)]>set global gtid_purged='6a3aff53-6516-11e9-adbc-6c0b84be13e4:1-12,b3f6377f-52c5-11ea-92c4-be6f2b61965c:1-6';

再启动,就没问题了,具体细节以后再研究

(root@g1-db-test-v06:6005)[(none)]>start group_replication;

Query OK, 0 rows affected (4.68 sec)

----------------------------

参考wiki:

weixin_39629969

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
mysql 的节点组是什么_【MySQL 组复制】1.组复制技术简介

组复制有两种模式单主模式(single-primary/single-master)下自动选举出一个主节点，从而只允许在同一时刻只有该主节点可以更新数据。对于MySQL的高级使用人员，可以通过复制组实现多主模型(multi-primary)，这种模型下，所有的主节点都可以在同一时刻接受更新操作，即并发写。MySQL组复制有一个内置的组成员服务(group membership service)，该...
复制链接

扫一扫