From f6367086cd6819e80c890dbdd121d9e6b4adf2f5 Mon Sep 17 00:00:00 2001 From: diandian Date: Wed, 2 Apr 2025 16:21:31 +0800 Subject: [PATCH] =?UTF-8?q?=E6=9B=B4=E6=96=B0=20'mysql-MD/MySQl=5F80=5F?= =?UTF-8?q?=E7=BB=84=E5=A4=8D=E5=88=B6.md'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ySQl组复制.md => MySQl_80_组复制.md} | 382 +++++++++--------- 1 file changed, 191 insertions(+), 191 deletions(-) rename mysql-MD/{MySQl组复制.md => MySQl_80_组复制.md} (97%) diff --git a/mysql-MD/MySQl组复制.md b/mysql-MD/MySQl_80_组复制.md similarity index 97% rename from mysql-MD/MySQl组复制.md rename to mysql-MD/MySQl_80_组复制.md index deb06b7..5763dab 100644 --- a/mysql-MD/MySQl组复制.md +++ b/mysql-MD/MySQl_80_组复制.md @@ -1,191 +1,191 @@ -# MySQl组复制 - -### 组复制部署 - -**环境准备** -至少需要3台服务器，每台服务器上已经完成MySQL 8.0安装 - -``` -192.168.26.160 master -192.168.26.128 node1 -192.168.26.130 node2 -``` - -组复制可以以单主或多主模式运行，默认是单主模式，这里选取192.168.26.160（主机名master）作为单主读写服务器，其他2台为只读服务器。 - -**查询主库uuid** - -3台机器配置文件中的uuid需要一样,在主库使用select uuid()查询,使用主库的uuid即可 - -```bash -mysql> select uuid(); -+--------------------------------------+ -| uuid() | -+--------------------------------------+ -| a71de24e-0bae-11f0-af42-000c29649a9e | -+--------------------------------------+ -1 row in set (0.00 sec) -``` - -**修改配置文件** - -组复制的事务传递是基于GTID的，且与部分引擎不兼容，因此需要修改相应的参数内容。 - -修改3台机器配置文件,新增下列参数： - -```bash -#----------------认证插件----------------------- -#8.0默认使用的认证插件需要ssl认证,这里修改了认证插件不使用ssl -default_authentication_plugin=mysql_native_password - -#----------------Storage_engine---------------- -# 组复制的数据必须存储在事务型引擎中。在多主模式下，事务冲突监测的机制是乐观型，即先执行事务，再检测冲突。如果有冲突则所有的成员都必须回滚，因此无法执行回滚的非事务型的存储引擎和组复制不兼容，需要禁用。 -disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" - -#----------------Replication---------------- -server_id=1 #三台机器不一样 -gtid_mode=on -enforce_gtid_consistency=on -binlog_checksum=none -log_bin=mysql-bin -log_slave_updates=on -binlog_format=row - -#----------------Group replication---------------- -plugin_load_add='group_replication.so' -group_replication_group_name="6afcf923-0ba5-11f0-8fad-000c29649a9e" -group_replication_start_on_boot=off # 在MySQL启动时不会自动启动组复制 -group_replication_local_address= "192.168.26.160:33061" #修改成每个节点的ip即可 -group_replication_group_seeds= "192.168.26.160:33061, 192.168.26.128:33061, 192.168.26.130:33061" -group_replication_bootstrap_group=off # 设置是否引导组服务（即创建一个组），一定要设置为off，否则每次重启都会引导一个新组出来。 -``` - -**重启服务** - -重启服务并通过show plugins命令确认组复制插件已安装： - -```bash -mysql> show plugins; -``` - -**设置分布式恢复服务的用户凭证** -当有新成员加入组复制时，会通过分布式恢复进程（Distributed Recovery Process）来同步数据。分布式恢复进程会先找一个数据的捐赠者（Donor）,并通过一个名为group_replication_reocvery的通道将捐赠者binlog中的事务发送给新成员。在这里需要一个授权用户凭证来建立分布式恢复的连接。这个用户在所有的组成员上都必须存在。 - -在主库执行下列命令创建连接用户： - -```sql -set sql_log_bin=0; -create user repuser@'%' identified with 'mysql_native_password' by 'reppassword'; -grant replication slave on *.* to repuser@'%'; -grant connection_admin on *.* to repuser@'%'; -grant backup_admin on *.* to repuser@'%'; -flush privileges; -set sql_log_bin=1; -``` - -创建好用户后，将用户凭证指定为分布式恢复进程使用： - -```sql -change master to master_user='repuser', master_password='reppassword' for channel 'group_replication_recovery'; -``` - -**组复制引导** -第一次启动组复制称作引导，引导会创建一个组出来。通过group_replication_bootstrap_group参数来控制引导动作。引导组复制必须由单一服务器完成且只需要执行一次。如果group_replication_bootstrap_group设置为on，则每次重启都会创建出一个同名新组，这也是前面参数中将其设置为off的原因。 - -执行下列命令引导组复制： - -```sql -set global group_replication_bootstrap_group=on; -start group_replication; -set global group_replication_bootstrap_group=off; -``` - -**注意**:只有在第一次启动组复制时，才需要设置group_replication_bootstrap_group，后续成员加入时都不能设置此变量，否则会产生经典的分布式系统问题 --- 脑裂（split brain）。 - -一旦start group_replication;语句成功返回后，组复制就成功启动了，可以通过下列语句确认引导结果： - ------------------------------------------------- - -```sql -select * from performance_schema.replication_group_members; -``` - -查询结果显示member_state为online，member_role为primary，说明组复制已经引导成功了。 - -在主库运行一些事务,mysql8.0默认开始事务： - -```sql -create database test; -use test; -create table t1(id int auto_increment primary key); -insert into t1 values(null); -insert into t1 values(null); -insert into t1 values(null); -commit; -``` - -然后可以通过show binlog events in '日志名';查看二进制日志中的内容,可以看到日志已写入二进制日志，此时主库可以作为捐赠者（Donor），可以将这些事务变更同步给后加入的成员。 - -**将其他成员加入组复制** -完成前面操作后，已经创建出了一个组，并且其中已有1台主库在运行了，下面需将另外两个成员也加入组复制。 - -新成员加入组时会有一个数据恢复的动作，如果加入时组内数据已经很大了，那么这个过程可能会耗费很长时间，并且如果主库purge过二进制日志，那么恢复会失败。此时应使用备份恢复工具（mysqldump/xtrabackup等）将待加入的成员数据状态还原至离主库较近的时间点，以缩短加入后的数据恢复时间。 - -本示例是全新环境，数据变更很少，且主库具有所有变更的日志，可以将新成员直接加入，由分布式恢复进程来同步数据。 - -所有从服务器重启服务并创建分布式恢复凭证 - -``` -set sql_log_bin=0; -create user repuser@'%' identified with 'mysql_native_password' by 'reppassword'; -grant replication slave on *.* to repuser@'%'; -grant connection_admin on *.* to repuser@'%'; -grant backup_admin on *.* to repuser@'%'; -flush privileges; -set sql_log_bin=1; -change master to master_user='repuser', master_password='reppassword' for channel 'group_replication_recovery'; -``` - -启动组复制，加入组 - -```sql -# 注意不需要再引导组了 -mysql> start group_replication; -mysql> select * from performance_schema.replication_group_members; -------+--------------+-------------+----------------+----------------------------+ -| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | -+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+ -| group_replication_applier | 0a7b9277-0bab-11f0-8d9d-000c29649a9e | master | 3306 | ONLINE | PRIMARY | 8.0.41 | XCom | -| group_replication_applier | aad69d1c-0bab-11f0-bee6-000c29f67e93 | node2 | 3306 | ONLINE | SECONDARY | 8.0.41 | XCom | -| group_replication_applier | b0021552-0baa-11f0-bd9f-000c29b36e90 | node1 | 3306 | ONLINE | SECONDARY | 8.0.41 | XCom | -+---------------------------+--------------------------------------+-------------+------- -``` - -此时我们看到第二和第三个成员已经成功加入组复制，成员角色为secondary，状态为online。 - -### 组复制容错测试 - -为了测试组复制的容错，在主库上直接杀掉MySQL进程（非正常关闭），模拟服务器宕机。 - -```sql -killall mysqld -``` - -**观察角色切换** - -在原来的从库上查询成员状态（kill命令在两次查询之间执行），注意此时服务器node1的角色自动从secondary变为primay，表示其被提升为新的主库： - -```sql -select * from performance_schema.replication_group_members; -``` - -**原主库重新加入组复制** - -将原主库重新启动，并加入组复制，注意此时宕机的主库将以从库的身份加入组复制（不会自动恢复主库身份），主库依然是上次切换的node1 - -```sql -#主库运行下列指令 -start group_replication; -select * from performance_schema.replication_group_members; -``` - +# MySQl组复制 + +### 组复制部署 + +**环境准备** +至少需要3台服务器，每台服务器上已经完成MySQL 8.0安装 + +``` +192.168.26.160 master +192.168.26.128 node1 +192.168.26.130 node2 +``` + +组复制可以以单主或多主模式运行，默认是单主模式，这里选取192.168.26.160（主机名master）作为单主读写服务器，其他2台为只读服务器。 + +**查询主库uuid** + +3台机器配置文件中的uuid需要一样,在主库使用select uuid()查询,使用主库的uuid即可 + +```bash +mysql> select uuid(); ++--------------------------------------+ +| uuid() | ++--------------------------------------+ +| a71de24e-0bae-11f0-af42-000c29649a9e | ++--------------------------------------+ +1 row in set (0.00 sec) +``` + +**修改配置文件** + +组复制的事务传递是基于GTID的，且与部分引擎不兼容，因此需要修改相应的参数内容。 + +修改3台机器配置文件,新增下列参数： + +```bash +#----------------认证插件----------------------- +#8.0默认使用的认证插件需要ssl认证,这里修改了认证插件不使用ssl +default_authentication_plugin=mysql_native_password + +#----------------Storage_engine---------------- +# 组复制的数据必须存储在事务型引擎中。在多主模式下，事务冲突监测的机制是乐观型，即先执行事务，再检测冲突。如果有冲突则所有的成员都必须回滚，因此无法执行回滚的非事务型的存储引擎和组复制不兼容，需要禁用。 +disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY" + +#----------------Replication---------------- +server_id=1 #三台机器不一样 +gtid_mode=on +enforce_gtid_consistency=on +binlog_checksum=none +log_bin=mysql-bin +log_slave_updates=on +binlog_format=row + +#----------------Group replication---------------- +plugin_load_add='group_replication.so' +group_replication_group_name="6afcf923-0ba5-11f0-8fad-000c29649a9e" +group_replication_start_on_boot=off # 在MySQL启动时不会自动启动组复制 +group_replication_local_address= "192.168.26.160:33061" #修改成每个节点的ip即可 +group_replication_group_seeds= "192.168.26.160:33061, 192.168.26.128:33061, 192.168.26.130:33061" +group_replication_bootstrap_group=off # 设置是否引导组服务（即创建一个组），一定要设置为off，否则每次重启都会引导一个新组出来。 +``` + +**重启服务** + +重启服务并通过show plugins命令确认组复制插件已安装： + +```bash +mysql> show plugins; +``` + +**设置分布式恢复服务的用户凭证** +当有新成员加入组复制时，会通过分布式恢复进程（Distributed Recovery Process）来同步数据。分布式恢复进程会先找一个数据的捐赠者（Donor）,并通过一个名为group_replication_reocvery的通道将捐赠者binlog中的事务发送给新成员。在这里需要一个授权用户凭证来建立分布式恢复的连接。这个用户在所有的组成员上都必须存在。 + +在主库执行下列命令创建连接用户： + +```sql +set sql_log_bin=0; +create user repuser@'%' identified with 'mysql_native_password' by 'reppassword'; +grant replication slave on *.* to repuser@'%'; +grant connection_admin on *.* to repuser@'%'; +grant backup_admin on *.* to repuser@'%'; +flush privileges; +set sql_log_bin=1; +``` + +创建好用户后，将用户凭证指定为分布式恢复进程使用： + +```sql +change master to master_user='repuser', master_password='reppassword' for channel 'group_replication_recovery'; +``` + +**组复制引导** +第一次启动组复制称作引导，引导会创建一个组出来。通过group_replication_bootstrap_group参数来控制引导动作。引导组复制必须由单一服务器完成且只需要执行一次。如果group_replication_bootstrap_group设置为on，则每次重启都会创建出一个同名新组，这也是前面参数中将其设置为off的原因。 + +执行下列命令引导组复制： + +```sql +set global group_replication_bootstrap_group=on; +start group_replication; +set global group_replication_bootstrap_group=off; +``` + +**注意**:只有在第一次启动组复制时，才需要设置group_replication_bootstrap_group，后续成员加入时都不能设置此变量，否则会产生经典的分布式系统问题 --- 脑裂（split brain）。 + +一旦start group_replication;语句成功返回后，组复制就成功启动了，可以通过下列语句确认引导结果： + +------------------------------------------------ + +```sql +select * from performance_schema.replication_group_members; +``` + +查询结果显示member_state为online，member_role为primary，说明组复制已经引导成功了。 + +在主库运行一些事务,mysql8.0默认开始事务： + +```sql +create database test; +use test; +create table t1(id int auto_increment primary key); +insert into t1 values(null); +insert into t1 values(null); +insert into t1 values(null); +commit; +``` + +然后可以通过show binlog events in '日志名';查看二进制日志中的内容,可以看到日志已写入二进制日志，此时主库可以作为捐赠者（Donor），可以将这些事务变更同步给后加入的成员。 + +**将其他成员加入组复制** +完成前面操作后，已经创建出了一个组，并且其中已有1台主库在运行了，下面需将另外两个成员也加入组复制。 + +新成员加入组时会有一个数据恢复的动作，如果加入时组内数据已经很大了，那么这个过程可能会耗费很长时间，并且如果主库purge过二进制日志，那么恢复会失败。此时应使用备份恢复工具（mysqldump/xtrabackup等）将待加入的成员数据状态还原至离主库较近的时间点，以缩短加入后的数据恢复时间。 + +本示例是全新环境，数据变更很少，且主库具有所有变更的日志，可以将新成员直接加入，由分布式恢复进程来同步数据。 + +所有从服务器重启服务并创建分布式恢复凭证 + +``` +set sql_log_bin=0; +create user repuser@'%' identified with 'mysql_native_password' by 'reppassword'; +grant replication slave on *.* to repuser@'%'; +grant connection_admin on *.* to repuser@'%'; +grant backup_admin on *.* to repuser@'%'; +flush privileges; +set sql_log_bin=1; +change master to master_user='repuser', master_password='reppassword' for channel 'group_replication_recovery'; +``` + +启动组复制，加入组 + +```sql +# 注意不需要再引导组了 +mysql> start group_replication; +mysql> select * from performance_schema.replication_group_members; +------+--------------+-------------+----------------+----------------------------+ +| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK | ++---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+ +| group_replication_applier | 0a7b9277-0bab-11f0-8d9d-000c29649a9e | master | 3306 | ONLINE | PRIMARY | 8.0.41 | XCom | +| group_replication_applier | aad69d1c-0bab-11f0-bee6-000c29f67e93 | node2 | 3306 | ONLINE | SECONDARY | 8.0.41 | XCom | +| group_replication_applier | b0021552-0baa-11f0-bd9f-000c29b36e90 | node1 | 3306 | ONLINE | SECONDARY | 8.0.41 | XCom | ++---------------------------+--------------------------------------+-------------+------- +``` + +此时我们看到第二和第三个成员已经成功加入组复制，成员角色为secondary，状态为online。 + +### 组复制容错测试 + +为了测试组复制的容错，在主库上直接杀掉MySQL进程（非正常关闭），模拟服务器宕机。 + +```sql +killall mysqld +``` + +**观察角色切换** + +在原来的从库上查询成员状态（kill命令在两次查询之间执行），注意此时服务器node1的角色自动从secondary变为primay，表示其被提升为新的主库： + +```sql +select * from performance_schema.replication_group_members; +``` + +**原主库重新加入组复制** + +将原主库重新启动，并加入组复制，注意此时宕机的主库将以从库的身份加入组复制（不会自动恢复主库身份），主库依然是上次切换的node1 + +```sql +#主库运行下列指令 +start group_replication; +select * from performance_schema.replication_group_members; +``` +