MySQL 5.7 组复制配置实践

MySQL组复制的配置实践
第一步是部署三个MySQL Server实例。Group Replication是MySQL Server 5.7.17及更新版本提供的内置MySQL插件。
下面的过程使用一台物理机器,因此每个MySQL服务器实例都需要一个特定的数据目录。在名为mysqldata的目录中创建数据目录,并对每个目录进行初始化。
创建三个数据目录

[mysql@localhost mysqldata]$ mkdir mysql1
[mysql@localhost mysqldata]$ mkdir mysql2
[mysql@localhost mysqldata]$ mkdir mysql3
[mysql@localhost mysqldata]$ ll
total 0
drwxr-xr-x. 2 mysql mysql 6 Jan 16 08:54 mysql1
drwxr-xr-x. 2 mysql mysql 6 Jan 16 08:55 mysql2
drwxr-xr-x. 2 mysql mysql 6 Jan 16 08:55 mysql3

创建三个实例的参数文件

[mysql@localhost mysql]# vi mysql1.cnf
[mysqld]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql1
bind-address=0.0.0.0
user=mysql
port=3306
log-error=/mysqldata/mysql1/mysql.err
pid-file=/mysqldata/mysql1/mysqld.pid
socket = /mysqldata/mysql1/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB

[mysql@localhost mysql]$ vi mysql2.cnf
[mysqld]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql2
bind-address=0.0.0.0
user=mysql
port=3307
log-error=/mysqldata/mysql2/mysql.err
pid-file=/mysqldata/mysql2/mysqld.pid
socket = /mysqldata/mysql2/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB


[mysql@localhost mysql]$ vi mysql3.cnf
[mysqld]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql3
bind-address=0.0.0.0
user=mysql
port=3308
log-error=/mysqldata/mysql3/mysql.err
pid-file=/mysqldata/mysql3/mysqld.pid
socket = /mysqldata/mysql3/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB

初始化三个实例

[root@localhost ~]# cd /mysqlsoft/mysql/bin
[root@localhost bin]# ./mysqld  --defaults-file=/mysqlsoft/mysql/mysql1.cnf --initialize -basedir=/mysqlsoft/mysql --

datadir=/mysqldata/mysql1 --user=mysql
[root@localhost bin]# ./mysqld  --defaults-file=/mysqlsoft/mysql/mysql2.cnf --initialize -basedir=/mysqlsoft/mysql --

datadir=/mysqldata/mysql2 --user=mysql
[root@localhost bin]# ./mysqld  --defaults-file=/mysqlsoft/mysql/mysql3.cnf --initialize -basedir=/mysqlsoft/mysql --

datadir=/mysqldata/mysql3 --user=mysql

[mysql@localhost mysql1]$ cat mysql.err
2025-01-16T02:45:38.125723Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --

explicit_defaults_for_timestamp server option (see documentation for more details).
2025-01-16T02:45:38.126190Z 0 [ERROR] Can't find error-message file 'asedir=/mysqlsoft/mysql/share/errmsg.sys'. Check error-

message file location and 'lc-messages-dir' configuration directive.
2025-01-16T02:45:38.535031Z 0 [Warning] InnoDB: New log files created, LSN=45790
2025-01-16T02:45:38.597593Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2025-01-16T02:45:38.658289Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this 

server has been started. Generating a new UUID: f81625c0-d3b3-11ef-9c8d-005056a390e6.
2025-01-16T02:45:38.659975Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2025-01-16T02:45:38.661884Z 1 [Note] A temporary password is generated for root@localhost: LplkX((&j1&u

[mysql@localhost mysql2]$ cat mysql.err
2025-01-16T02:45:51.143320Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --

explicit_defaults_for_timestamp server option (see documentation for more details).
2025-01-16T02:45:51.143570Z 0 [ERROR] Can't find error-message file 'asedir=/mysqlsoft/mysql/share/errmsg.sys'. Check error-

message file location and 'lc-messages-dir' configuration directive.
2025-01-16T02:45:51.439385Z 0 [Warning] InnoDB: New log files created, LSN=45790
2025-01-16T02:45:51.502171Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2025-01-16T02:45:51.561336Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this 

server has been started. Generating a new UUID: ffc6ff15-d3b3-11ef-9e2d-005056a390e6.
2025-01-16T02:45:51.562821Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2025-01-16T02:45:51.564054Z 1 [Note] A temporary password is generated for root@localhost: OM,#w?fll2iT


[mysql@localhost mysql3]$ cat mysql.err
2025-01-16T02:46:03.815721Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --

explicit_defaults_for_timestamp server option (see documentation for more details).
2025-01-16T02:46:03.815972Z 0 [ERROR] Can't find error-message file 'asedir=/mysqlsoft/mysql/share/errmsg.sys'. Check error-

message file location and 'lc-messages-dir' configuration directive.
2025-01-16T02:46:04.113214Z 0 [Warning] InnoDB: New log files created, LSN=45790
2025-01-16T02:46:04.171088Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
2025-01-16T02:46:04.230517Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this 

server has been started. Generating a new UUID: 07542900-d3b4-11ef-a088-005056a390e6.
2025-01-16T02:46:04.232171Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
2025-01-16T02:46:04.233327Z 1 [Note] A temporary password is generated for root@localhost: wlh%+FHw(7Sk

如果想服务能够部署自动支持安全连接,使用mysql_ssl_rsa_setup工具来创建缺省SSL与RSA文件

[root@localhost bin]# ./mysql_ssl_rsa_setup --datadir=/mysqldata/mysql1
Generating a 2048 bit RSA private key
...........+++
................................+++
writing new private key to 'ca-key.pem'
-----
Generating a 2048 bit RSA private key
.+++
.......................+++
writing new private key to 'server-key.pem'
-----
Generating a 2048 bit RSA private key
...............................+++
........................+++
writing new private key to 'client-key.pem'
-----
[root@localhost bin]# ./mysql_ssl_rsa_setup --datadir=/mysqldata/mysql2
Generating a 2048 bit RSA private key
........................+++
........................................................+++
writing new private key to 'ca-key.pem'
-----
Generating a 2048 bit RSA private key
................................+++
......................+++
writing new private key to 'server-key.pem'
-----
Generating a 2048 bit RSA private key
........................+++
......................................................................+++
writing new private key to 'client-key.pem'
-----
[root@localhost bin]# ./mysql_ssl_rsa_setup --datadir=/mysqldata/mysql3
Generating a 2048 bit RSA private key
........................................................................................................+++
...................+++
writing new private key to 'ca-key.pem'
-----
Generating a 2048 bit RSA private key
..................................+++
.......................................................................+++
writing new private key to 'server-key.pem'
-----
Generating a 2048 bit RSA private key
..............................................+++
........................+++
writing new private key to 'client-key.pem'
-----

配置启动脚本

[mysql@localhost mysql]$ cat my.cnf
[mysqld_multi]
mysqld=/mysqlsoft/mysql/bin/mysqld_safe
mysqladmin =/mysqlsoft/mysql/bin/mysqladmin
log =/mysqlsoft/mysql/mysqld_multi.log

[mysqld1]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql1
bind-address=0.0.0.0
user=mysql
port=3306
log-error=/mysqldata/mysql1/mysql.err
pid-file=/mysqldata/mysql1/mysqld.pid
socket = /mysqldata/mysql1/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB
explicit_defaults_for_timestamp = true


[mysqld2]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql2
bind-address=0.0.0.0
user=mysql
port=3307
log-error=/mysqldata/mysql2/mysql.err
pid-file=/mysqldata/mysql2/mysqld.pid
socket = /mysqldata/mysql2/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB
explicit_defaults_for_timestamp = true


[mysqld3]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql3
bind-address=0.0.0.0
user=mysql
port=3308
log-error=/mysqldata/mysql3/mysql.err
pid-file=/mysqldata/mysql3/mysqld.pid
socket = /mysqldata/mysql3/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB
explicit_defaults_for_timestamp = true

[mysql@localhost mysql]$ mysqld_multi start 1,2,3


[mysql@localhost mysql]$ tail -f mysqld_multi.log 
mysqld_multi log file version 2.16; run: Thu Jan 16 11:12:08 2025



Starting MySQL servers

2025-01-16T03:17:42.956897Z mysqld_safe Logging to '/mysqldata/mysql1/mysql.err'.
2025-01-16T03:17:42.968830Z mysqld_safe Logging to '/mysqldata/mysql3/mysql.err'.
2025-01-16T03:17:42.971621Z mysqld_safe Logging to '/mysqldata/mysql2/mysql.err'.
2025-01-16T03:17:42.978298Z mysqld_safe Logging to '/mysqldata/mysql1/mysql.err'.
2025-01-16T03:17:42.984997Z mysqld_safe Logging to '/mysqldata/mysql2/mysql.err'.
2025-01-16T03:17:42.999744Z mysqld_safe Logging to '/mysqldata/mysql3/mysql.err'.
2025-01-16T03:17:43.014252Z mysqld_safe A mysqld process already exists
2025-01-16T03:17:43.026350Z mysqld_safe Starting mysqld daemon with databases from /mysqldata/mysql3
2025-01-16T03:17:43.026973Z mysqld_safe Starting mysqld daemon with databases from /mysqldata/mysql2
2025-01-16T03:17:43.032460Z mysqld_safe A mysqld process already exists
2025-01-16T03:17:43.042893Z mysqld_safe Starting mysqld daemon with databases from /mysqldata/mysql2
2025-01-16T03:17:43.058374Z mysqld_safe Starting mysqld daemon with databases from /mysqldata/mysql3

组复制服务器设置
要安装和使用组复制插件,您必须正确配置MySQL服务器实例。建议将配置存储在实例的配置文件中。下面为mysql1服务器配置。

[mysql@localhost mysql]$ cat mysql1.cnf
[mysqld]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql1
bind-address=0.0.0.0
user=mysql
port=3306
log-error=/mysqldata/mysql1/mysql.err
pid-file=/mysqldata/mysql1/mysqld.pid
socket = /mysqldata/mysql1/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB

这些设置将MySQL服务器配置为使用前面创建的数据目录,以及服务器应该打开哪个端口并开始侦听传入的连接。

复制框架
以下设置根据“MySQL Group replication”的要求配置复制。

server_id=1
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

这些设置将服务器配置为使用唯一标识符1,以启用全局事务标识符,并将复制元数据存储在系统表而不是文件中。此外,它指示服务器打开二进制日志记录,使用基于行的格式并禁用二进制日志事件校验和。

组复制设置
此时,mysql1.cnf文件确保配置了服务器,并指示在给定配置下实例化复制基础结构。以下部分为服务器配置组复制设置。

transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="2366d798-4dc1-421a-a9de-3c825bfada7d"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24901"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off

上面用于group_replication变量的loose前缀指示,如果在服务器启动时没有加载Group Replication插件,则服务器继续启动。
.第1行指示服务器,对于每个事务,它必须收集写集,并使用XXHASH64散列算法将其编码为散列。

.第2行告诉插件它要加入或创建的组的名称为“2366d798-4dc1-421a-a9de-3c825bfada7d”。

.第3行指示插件在服务器启动时不要自动启动操作。

.第4行告诉插件使用IP地址127.0.0.1或localhost和端口24901来处理来自组中其他成员的传入连接。
服务器在这个端口上监听成员到成员的连接。此端口绝对不能用于用户应用程序,必须在运行组复制时为组的不同成员之间的通信保留该端口。

group_replication_local_address配置的本地地址必须对所有组成员都可访问。例如,如果每个服务器实例都在不同的机器上,则使用该机器的IP和端口,例如10.0.0.1:33061。group_replication_local_address的推荐端口是33061,但是在本教程中,我们使用在一台机器上运行的三个服务器实例,因此使用端口24901到24903。

.第5行告诉插件,如果需要加入组,应该联系这些主机和端口上的以下成员。这些是种子成员,当该成员想要连接到组时使用。在加入时,服务器首先与其中一个(种子)联系,然后要求组重新配置以允许加入服务器被组接受。请注意,此选项不需要列出组中的所有成员,而是在此服务器希望加入组时应该联系的服务器列表。

启动组的服务器不使用此选项,因为它是初始服务器,因此它负责引导组。第二个服务器加入要求组中唯一的成员加入,然后扩展组。第三个服务器加入可以请求这两个服务器中的任何一个加入,然后这个群组再次扩展。后续服务器在加入时重复此过程。

当同时加入多个服务器时,确保它们指向已经在组中的种子成员。不要使用正在加入组的成员作为种子,因为他们在联系时可能还不在组中。

最好的做法是先启动bootstrap成员,然后让它创建组。然后将其作为其他加入的成员的种子成员。这确保在加入其他成员时形成一个组。

不支持创建群组并同时加入多个成员。它可能会起作用,但很可能是操作竞争,然后加入组的行为以错误或超时告终。

.第6行指示插件是否启动组
此选项在任何时候都只能在一个服务器实例上使用,通常是在您第一次引导组时(或者在整个组被关闭并重新启动的情况下)。如果您多次引导组,例如当多个服务器实例设置了此选项时,那么它们可能会创建一个人工分裂的大脑场景,其中存在两个具有相同名称的不同组。在第一个服务器实例联机后禁用此选项。

组中所有服务器的配置非常相似。需要修改每个服务器的具体信息(例如server_id、datadir、group_replication_local_address)。

用户凭证
“组复制”通过异步复制协议实现分布式恢复,在组成员加入组之前先同步组成员。分布式恢复进程依赖于一个名为group_replication_recovery的复制区域通道,该区域通道用于在组成员之间传输事务。因此,需要设置具有相应权限的复制用户,以便Group replication建立成员间直接恢复复制通道。

[mysql@localhost mysql]$ mysqld --defaults-file=/mysqlsoft/mysql/mysql1.cnf &

创建一个具有REPLICATION-SLAVE权限的MySQL用户。不应该在二进制日志中捕获此过程,以避免将更改传播到其他服务器实例。在下面的示例中,显示了用户rpl_user和密码password。在配置服务器时,请使用合适的用户名和密码。连接到服务器mysql1,发出以下语句:

[root@localhost bin]# mysql -h 10.138.130.250 -P 3306 -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE USER rpl_user@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)

按照上述方式配置用户后,使用CHANGE MASTER TO语句配置服务器,以便在下一次需要从另一个成员恢复其状态时,为group_replication_recovery复制通道使用给定的凭据。执行以下命令,将rpl_user和password替换为创建用户时使用的值。

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.03 sec)

分布式恢复是加入组的服务器所采取的第一步。如果这些凭据设置不正确,服务器将无法运行恢复过程并获得与其他组成员的同步,因此最终无法加入组成员。类似地,如果成员不能通过服务器的主机名正确识别其他成员,则恢复过程可能会失败。建议运行MySQL的操作系统使用正确配置的唯一主机名,可以使用DNS或本地设置。这个主机名可以在performance_schema.replication_group_members表的Member_host列中进行验证。如果多个组成员外部化操作系统设置的默认主机名,则成员有可能无法解析到正确的成员地址,从而无法加入组。在这种情况下,使用report_host配置一个唯一的主机名,由每个服务器外部化。

启动组复制
配置并启动服务mysql1后,安装Group Replication插件。连接到服务器并发出以下命令:

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.06 sec)

重点:
mysql.session在加载组复制之前必须已经存在。mysql.ession在MySQL 5.7.19版本中被添加。如果您的数据字典是使用较早版本初始化的,则必须运行mysql_upgrade过程。如果不执行升级,则启动“组复制”失败,并提示错误信息

There was an error when trying to access the server with
user: mysql.session@localhost. Make sure the user is present
in the server and that mysql_upgrade was ran after a server
update..

要检查插件是否已成功安装,请执行SHOW PLUGINS;然后检查输出。它应该显示如下内容:

mysql> SHOW PLUGINS;
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
| binlog                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| mysql_native_password      | ACTIVE   | AUTHENTICATION     | NULL                 | GPL     |
| sha256_password            | ACTIVE   | AUTHENTICATION     | NULL                 | GPL     |
| CSV                        | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| MEMORY                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| InnoDB                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| INNODB_TRX                 | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_LOCKS               | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_LOCK_WAITS          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP                 | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP_RESET           | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMPMEM              | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMPMEM_RESET        | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP_PER_INDEX       | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP_PER_INDEX_RESET | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_BUFFER_PAGE         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_BUFFER_PAGE_LRU     | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_BUFFER_POOL_STATS   | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_TEMP_TABLE_INFO     | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_METRICS             | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_DEFAULT_STOPWORD | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_DELETED          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_BEING_DELETED    | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_CONFIG           | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_INDEX_CACHE      | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_INDEX_TABLE      | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_TABLES          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_TABLESTATS      | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_INDEXES         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_COLUMNS         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_FIELDS          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_FOREIGN         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_FOREIGN_COLS    | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_TABLESPACES     | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_DATAFILES       | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_VIRTUAL         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| MyISAM                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| MRG_MYISAM                 | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| PERFORMANCE_SCHEMA         | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| ARCHIVE                    | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| BLACKHOLE                  | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| FEDERATED                  | DISABLED | STORAGE ENGINE     | NULL                 | GPL     |
| partition                  | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| ngram                      | ACTIVE   | FTPARSER           | NULL                 | GPL     |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.01 sec)

要启动组,请指示服务器mysql1引导组,然后启动组复制。这个引导应该只由单个服务器完成,即启动组的服务器,并且只能一次。这就是为什么引导配置选项的值没有保存在配置文件中。如果将其保存在配置文件中,则重启后服务器将自动引导具有相同名称的第二个组。这将导致两个具有相同名称的不同组。同样的道理也适用于将此选项设置为ON时停止和重新启动插件。

mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (2.09 sec)

mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)

一旦START GROUP_REPLICATION语句返回,这个组就已经启动了。你可以检查组现在已经创建,并且里面有一个成员:

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | f81625c0-d3b3-11ef-9c8d-005056a390e6 | mysqlcs     |        3306 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
1 row in set (0.01 sec)

该表中的信息确认组中有一个具有唯一标识符f81625c0-d3b3-11ef-9c8d-005056a390e6的成员,它是ONLINE的,并且在mysqlcs上监听端口3306上的客户端连接。
为了演示服务器确实在一个组中,并且它能够处理负载,创建一个表并向其中添加一些内容。

mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.01 sec)

mysql> USE test;
Database changed
mysql> CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO t1 VALUES (1, 'Luis');
Query OK, 1 row affected (0.04 sec)

检查表t1和二进制日志的内容。

mysql> SELECT * FROM t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
1 row in set (0.00 sec)


mysql> SHOW BINLOG EVENTS;
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |   4 | Format_desc    |         1 |         123 | Server ver: 5.7.26-log, Binlog ver: 4                              |
| binlog.000001 | 123 | Previous_gtids |         1 |         150 |                                                                    |
| binlog.000001 | 150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'f81625c0-d3b3-11ef-9c8d-005056a390e6:1'  |
| binlog.000001 | 211 | Query          |         1 |         301 | CREATE DATABASE test                                               |
| binlog.000001 | 301 | Gtid           |         1 |         362 | SET @@SESSION.GTID_NEXT= 'f81625c0-d3b3-11ef-9c8d-005056a390e6:2'  |
| binlog.000001 | 362 | Query          |         1 |         486 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 | 486 | Gtid           |         1 |         547 | SET @@SESSION.GTID_NEXT= 'f81625c0-d3b3-11ef-9c8d-005056a390e6:3'  |
| binlog.000001 | 547 | Query          |         1 |         615 | BEGIN                                                              |
| binlog.000001 | 615 | Table_map      |         1 |         658 | table_id: 108 (test.t1)                                            |
| binlog.000001 | 658 | Write_rows     |         1 |         700 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 | 700 | Xid            |         1 |         727 | COMMIT /* xid=23 */                                                |
+---------------+-----+----------------+-----------+-------------+--------------------------------------------------------------------+
11 rows in set (0.00 sec)

如上所述,创建了数据库和表对象,并将它们对应的DDL语句写入二进制日志。此外,还将数据插入表并写入二进制日志。下一节将说明二进制日志条目的重要性,当组增长时,当新成员试图赶上并联机时,将执行分布式恢复。
向组中添加实例
此时,组中有一个成员服务器mysql1,其中包含一些数据。现在是时候通过添加前面配置的另外两个服务器来扩展组了。
添加第二个实例
为了添加第二个实例,服务器mysql2,首先为它创建配置文件。该配置类似于服务器mysql1所使用的配置,除了数据目录的位置、mysql2将要侦听的端口或其server_id等内容。这些不同的行在下面的清单中突出显示。
[mysql@localhost mysql]$ vi mysql2.cnf
[mysqld]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql2
bind-address=0.0.0.0
user=mysql
port=3307
log-error=/mysqldata/mysql2/mysql.err
pid-file=/mysqldata/mysql2/mysqld.pid
socket = /mysqldata/mysql2/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB

server_id=2
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

transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="2366d798-4dc1-421a-a9de-3c825bfada7d"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24902"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off

与服务器mysql1的过程类似,配置文件就绪后启动服务器

[mysql@localhost mysql]$ mysqld --defaults-file=/mysqlsoft/mysql/mysql2.cnf &

然后配置恢复凭据,如下所示。这些命令与将服务器mysql1设置为用户在组内共享时使用的命令相同。在mysql2上发表以下声明。

[root@localhost /]#  mysql -h 10.138.130.250 -P 3307 -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE USER rpl_user@'%';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

安装Group Replication插件并启动将服务器加入组的过程。下面的示例以与部署服务器mysql1时相同的方式安装插件。

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.01 sec)

mysql> SHOW PLUGINS;
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
| binlog                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| mysql_native_password      | ACTIVE   | AUTHENTICATION     | NULL                 | GPL     |
| sha256_password            | ACTIVE   | AUTHENTICATION     | NULL                 | GPL     |
| CSV                        | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| MEMORY                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| InnoDB                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| INNODB_TRX                 | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_LOCKS               | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_LOCK_WAITS          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP                 | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP_RESET           | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMPMEM              | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMPMEM_RESET        | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP_PER_INDEX       | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_CMP_PER_INDEX_RESET | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_BUFFER_PAGE         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_BUFFER_PAGE_LRU     | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_BUFFER_POOL_STATS   | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_TEMP_TABLE_INFO     | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_METRICS             | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_DEFAULT_STOPWORD | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_DELETED          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_BEING_DELETED    | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_CONFIG           | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_INDEX_CACHE      | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_FT_INDEX_TABLE      | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_TABLES          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_TABLESTATS      | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_INDEXES         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_COLUMNS         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_FIELDS          | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_FOREIGN         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_FOREIGN_COLS    | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_TABLESPACES     | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_DATAFILES       | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| INNODB_SYS_VIRTUAL         | ACTIVE   | INFORMATION SCHEMA | NULL                 | GPL     |
| MyISAM                     | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| MRG_MYISAM                 | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| PERFORMANCE_SCHEMA         | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| ARCHIVE                    | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| BLACKHOLE                  | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| FEDERATED                  | DISABLED | STORAGE ENGINE     | NULL                 | GPL     |
| partition                  | ACTIVE   | STORAGE ENGINE     | NULL                 | GPL     |
| ngram                      | ACTIVE   | FTPARSER           | NULL                 | GPL     |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.01 sec)

将服务器mysql2加入组。

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (5.85 sec)

与之前在mysql1在执行的步骤不相同,差异在于没有执行SET GLOBAL group_replication_bootstrap_group=ON;在启动组复制之前,因为组已经创建并且由服务器mysql1启动。所以这时服务器mysql2只需要被加入到现有的组中。

当组复制成功启动并且服务器加入组时,它会检查super_read_only变量。通过在成员的配置文件中将super_read_only设置为ON,可以确保在启动Group Replication时由于任何原因而失败的服务器不接受事务。如果服务器应该作为读写实例加入组,例如作为单主组中的主实例或作为多主组的成员,当super_read_only变量设置为ON时,则在加入组时将其设置为OFF。

检查performance_schema.replication_group_members表再次显示,现在组中有两个ONLINE服务器。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | f81625c0-d3b3-11ef-9c8d-005056a390e6 | mysqlcs     |        3306 | ONLINE       |
| group_replication_applier | ffc6ff15-d3b3-11ef-9e2d-005056a390e6 | mysqlcs     |        3307 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
2 rows in set (0.00 sec)

由于服务器mysql2也被标记为ONLINE,它一定已经自动赶上了服务器mysql1。验证它确实已与服务器mysql1同步,如下所示。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
5 rows in set (0.00 sec)

mysql> select * from test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
1 row in set (0.00 sec)

mysql> SHOW BINLOG EVENTS;
+---------------+-----+----------------+-----------+-------------+---------------------------------------+
| Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                  |
+---------------+-----+----------------+-----------+-------------+---------------------------------------+
| binlog.000001 |   4 | Format_desc    |         2 |         123 | Server ver: 5.7.26-log, Binlog ver: 4 |
| binlog.000001 | 123 | Previous_gtids |         2 |         150 |                                       |
+---------------+-----+----------------+-----------+-------------+---------------------------------------+
2 rows in set (0.00 sec)

如上所述,第二台服务器已添加到组中,并且它自动复制了服务器mysql1的更改。根据分布式恢复过程,这意味着在加入组之后,在被声明为在线之前,服务器mysql2已经自动连接到服务器mysql1,并从中获取丢失的数据。换句话说,它从它缺失的二进制日志mysql1中复制事务,直到它加入组的时间点。

添加其他实例
向组中添加更多实例的步骤基本上与添加第二台服务器时相同,只是配置需要像为服务器mysql2 操作那样进行更改。要总结所需的命令:
1.修改配置文件

[mysql@localhost mysql]$ vi mysql3.cnf
[mysqld]
basedir=/mysqlsoft/mysql
datadir=/mysqldata/mysql3
bind-address=0.0.0.0
user=mysql
port=3308
log-error=/mysqldata/mysql3/mysql.err
pid-file=/mysqldata/mysql3/mysqld.pid
socket = /mysqldata/mysql3/mysql.sock
character-set-server=utf8mb4
default-storage-engine=INNODB

server_id=3
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

transaction_write_set_extraction=XXHASH64
loose-group_replication_group_name="2366d798-4dc1-421a-a9de-3c825bfada7d"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "127.0.0.1:24903"
loose-group_replication_group_seeds= "127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903"
loose-group_replication_bootstrap_group= off

2.启动服务器

[mysql@localhost mysql]$ mysqld --defaults-file=/mysqlsoft/mysql/mysql3.cnf &

3.配置group_replication_recovery通道的恢复凭据。

[root@mysqlcs ~]# mysql -h 10.138.130.250 -P 3308 -u root -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)

mysql> CREATE USER rpl_user@'%';
ERROR 1396 (HY000): Operation CREATE USER failed for 'rpl_user'@'%'
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY '123456';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

4.安装Group Replication插件并启动它。

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.29 sec)

此时,服务器mysql3已经启动并运行,加入了组,并赶上了组中的其他服务器。查询performance_schema。Replication_group_members表再次

证实了这一点。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 07542900-d3b4-11ef-a088-005056a390e6 | mysqlcs     |        3308 | ONLINE       |
| group_replication_applier | f81625c0-d3b3-11ef-9c8d-005056a390e6 | mysqlcs     |        3306 | ONLINE       |
| group_replication_applier | ffc6ff15-d3b3-11ef-9e2d-005056a390e6 | mysqlcs     |        3307 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
3 rows in set (0.00 sec)

在服务器mysql2或服务器mysql1上执行相同的查询会产生相同的结果。此外,您可以验证服务器mysql3也赶上了:

mysql> SHOW DATABASES LIKE 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+
1 row in set (0.00 sec)

mysql> SELECT * FROM test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
1 row in set (0.00 sec)

mysql> SHOW BINLOG EVENTS;
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| Log_name      | Pos  | Event_type     | Server_id | End_log_pos | Info                                                               |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
| binlog.000001 |    4 | Format_desc    |         3 |         123 | Server ver: 5.7.26-log, Binlog ver: 4                              |
| binlog.000001 |  123 | Previous_gtids |         3 |         150 |                                                                    |
| binlog.000001 |  150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= 'f81625c0-d3b3-11ef-9c8d-005056a390e6:1'  |
| binlog.000001 |  211 | Query          |         1 |         301 | CREATE DATABASE test                                               |
| binlog.000001 |  301 | Gtid           |         1 |         362 | SET @@SESSION.GTID_NEXT= 'f81625c0-d3b3-11ef-9c8d-005056a390e6:2'  |
| binlog.000001 |  362 | Query          |         1 |         486 | use `test`; CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL) |
| binlog.000001 |  486 | Gtid           |         1 |         547 | SET @@SESSION.GTID_NEXT= 'f81625c0-d3b3-11ef-9c8d-005056a390e6:3'  |
| binlog.000001 |  547 | Query          |         1 |         606 | BEGIN                                                              |
| binlog.000001 |  606 | Table_map      |         1 |         649 | table_id: 108 (test.t1)                                            |
| binlog.000001 |  649 | Write_rows     |         1 |         691 | table_id: 108 flags: STMT_END_F                                    |
| binlog.000001 |  691 | Xid            |         1 |         718 | COMMIT /* xid=26 */                                                |
| binlog.000001 |  718 | Gtid           |         1 |         779 | SET @@SESSION.GTID_NEXT= '2366d798-4dc1-421a-a9de-3c825bfada7d:1'  |
| binlog.000001 |  779 | Query          |         1 |         838 | BEGIN                                                              |
| binlog.000001 |  838 | View_change    |         1 |         977 | view_id=17375148526840614:1                                        |
| binlog.000001 |  977 | Query          |         1 |        1042 | COMMIT                                                             |
| binlog.000001 | 1042 | Gtid           |         1 |        1103 | SET @@SESSION.GTID_NEXT= '2366d798-4dc1-421a-a9de-3c825bfada7d:2'  |
| binlog.000001 | 1103 | Query          |         1 |        1162 | BEGIN                                                              |
| binlog.000001 | 1162 | View_change    |         1 |        1341 | view_id=17375148526840614:2                                        |
| binlog.000001 | 1341 | Query          |         1 |        1406 | COMMIT                                                             |
| binlog.000001 | 1406 | Gtid           |         1 |        1467 | SET @@SESSION.GTID_NEXT= '2366d798-4dc1-421a-a9de-3c825bfada7d:3'  |
| binlog.000001 | 1467 | Query          |         1 |        1526 | BEGIN                                                              |
| binlog.000001 | 1526 | View_change    |         1 |        1705 | view_id=17375148526840614:3                                        |
| binlog.000001 | 1705 | Query          |         1 |        1770 | COMMIT                                                             |
+---------------+------+----------------+-----------+-------------+--------------------------------------------------------------------+
23 rows in set (0.00 sec)

MySQL组复制组名不是有效的UUID

在使用 启动MySQL Group Replication 时,遇到如下错误信息

mysql> 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.

err.log文件中:

2025-01-22T02:14:04.090619Z 4 [ERROR] Plugin group_replication reported: 'The group name 'repl_group1' is not a valid UUID'

“Plugin group_replication reported: ‘The group name ‘repl_group1’ is not a valid UUID'” 通常意味着你在配置组复制时使用了不正确的组名格式。在 MySQL 的 Group Replication 中,组名必须是一个有效的 UUID。
解决步骤
1.生成一个有效的 UUID:
可以使用在线工具或者命令行来生成一个 UUID。例如,在 Linux 系统中,你可以使用 uuidgen 命令:

[mysql@localhost mysql]$ uuidgen
2366d798-4dc1-421a-a9de-3c825bfada7d

这将输出一个形如 2366d798-4dc1-421a-a9de-3c825bfada7d 的 UUID。

2.修改配置文件:
在你的 MySQL 配置文件(通常是 my.cnf 或 my.ini)中,将 group_replication_group_name 的值设置为上一步生成的 UUID。例如:

[mysql@localhost mysql]$ vi mysql1.cnf
loose-group_replication_group_name="2366d798-4dc1-421a-a9de-3c825bfada7d"

3.重启 MySQL 服务:
修改配置后,需要重启 MySQL 服务以使更改生效。可以使用如下命令:

[mysql@localhost mysql]$  mysqld --defaults-file=/mysqlsoft/mysql/mysql1.cnf

4.验证配置:
在 MySQL 命令行中,你可以使用以下命令来检查组复制的配置:

mysql> SHOW GLOBAL VARIABLES LIKE 'group_replication_%';
+----------------------------------------------------+-------------------------------------------------+
| Variable_name                                      | Value                                           |
+----------------------------------------------------+-------------------------------------------------+
| group_replication_allow_local_disjoint_gtids_join  | OFF                                             |
| group_replication_allow_local_lower_version_join   | OFF                                             |
| group_replication_auto_increment_increment         | 7                                               |
| group_replication_bootstrap_group                  | OFF                                             |
| group_replication_components_stop_timeout          | 31536000                                        |
| group_replication_compression_threshold            | 1000000                                         |
| group_replication_enforce_update_everywhere_checks | OFF                                             |
| group_replication_exit_state_action                | READ_ONLY                                       |
| group_replication_flow_control_applier_threshold   | 25000                                           |
| group_replication_flow_control_certifier_threshold | 25000                                           |
| group_replication_flow_control_mode                | QUOTA                                           |
| group_replication_force_members                    |                                                 |
| group_replication_group_name                       | 2366d798-4dc1-421a-a9de-3c825bfada7d            |
| group_replication_group_seeds                      | 127.0.0.1:24901,127.0.0.1:24902,127.0.0.1:24903 |
| group_replication_gtid_assignment_block_size       | 1000000                                         |
| group_replication_ip_whitelist                     | AUTOMATIC                                       |
| group_replication_local_address                    | 127.0.0.1:24903                                 |
| group_replication_member_weight                    | 50                                              |
| group_replication_poll_spin_loops                  | 0                                               |
| group_replication_recovery_complete_at             | TRANSACTIONS_APPLIED                            |
| group_replication_recovery_reconnect_interval      | 60                                              |
| group_replication_recovery_retry_count             | 10                                              |
| group_replication_recovery_ssl_ca                  |                                                 |
| group_replication_recovery_ssl_capath              |                                                 |
| group_replication_recovery_ssl_cert                |                                                 |
| group_replication_recovery_ssl_cipher              |                                                 |
| group_replication_recovery_ssl_crl                 |                                                 |
| group_replication_recovery_ssl_crlpath             |                                                 |
| group_replication_recovery_ssl_key                 |                                                 |
| group_replication_recovery_ssl_verify_server_cert  | OFF                                             |
| group_replication_recovery_use_ssl                 | OFF                                             |
| group_replication_single_primary_mode              | ON                                              |
| group_replication_ssl_mode                         | DISABLED                                        |
| group_replication_start_on_boot                    | OFF                                             |
| group_replication_transaction_size_limit           | 0                                               |
| group_replication_unreachable_majority_timeout     | 0                                               |
+----------------------------------------------------+-------------------------------------------------+
36 rows in set (0.01 sec)

确保 group_replication_group_name 的值是你设置的 UUID。

5.初始化组复制:
如果这是第一次设置组复制,确保每个服务器都已经正确配置并且可以相互通信。然后,你可以初始化组复制:

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.29 sec)

确保 repl_user 和 123456是正确设置的复制用户和密码。
通过以上步骤,你应该能够解决因组名格式不正确导致的错误,并成功设置 MySQL 的 Group Replication。如果问题仍然存在,请检查网络设置和防火墙规则是否允许服务器之间的通信。

MySQL 5.7 延迟复制

延迟复制
MySQL 5.7支持延迟复制,这样从服务器就会故意滞后于主服务器至少一段指定的时间。缺省值为0秒。使用MASTER_DELAY选项更改MASTER TO将 延迟设置为N秒:
CHANGE MASTER TO MASTER_DELAY = N;

从主机接收到的事件至少要比它在主机上的执行晚N秒才执行。例外情况是,格式描述事件或日志文件旋转事件没有延迟,它们只影响SQL线程的 内部状态。

延迟复制可用于以下几个目的:
.防止用户在主机上出错。DBA可以将延迟的从服务器回滚到灾难发生之前的时间

.测试系统在出现延迟时的行为。例如,在应用程序中,延迟可能是由从属服务器上的沉重负载引起的。但是,很难生成这种负载级别。延迟复 制可以模拟延迟,而不必模拟负载。它还可以用于调试与滞后从机相关的条件。

.检查数据库很久以前的样子,而无需重新加载备份。例如,如果延迟是一周,DBA需要查看数据库在最后几天的开发之前是什么样子,那么可以 检查延迟的从属服务器。

START SLAVE和STOP SLAVE立即生效并忽略任何延迟。RESET SLAVE将延迟复位为0。

SHOW SLAVE STATUS有三个字段提供延迟信息:
.SQL_Delay: 一个非负整数,表示从服务器必须滞后于主服务器的秒数

.SQL_Remaining_Delay: 当Slave_SQL_Running_State为Waiting until MASTER_DELAY seconds after master executed event,该字段包含一 个整数,表示延迟剩余的秒数。在其他时候,该字段为NULL。

.Slave_SQL_Running_State:指示SQL线程状态的字符串(类似于Slave_IO_State)。该值与SHOW PROCESSLIST显示的SQL线程的State值相同。

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.138.130.243
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000010
          Read_Master_Log_Pos: 2099
               Relay_Log_File: localhost-relay-bin.000003
                Relay_Log_Pos: 877
        Relay_Master_Log_File: binlog.000010
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 2099
              Relay_Log_Space: 1689
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2
                  Master_UUID: 684e1f7d-6f47-11ef-a6d5-005056a3a162
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set: 684e1f7d-6f47-11ef-a6d5-005056a3a162:9-11,
bb8b95d1-6f47-11ef-9592-005056a390e6:9-10,
ca006ef3-6f46-11ef-8203-005056b9a980:1-5
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.01 sec)

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
     Id: 38
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 2046
  State: Slave has read all relay log; waiting for more updates
   Info: NULL
*************************** 2. row ***************************
     Id: 39
   User: root
   Host: localhost
     db: jycs
Command: Query
   Time: 0
  State: starting
   Info: SHOW PROCESSLIST
*************************** 3. row ***************************
     Id: 40
   User: system user
   Host:
     db: NULL
Command: Connect
   Time: 3682
  State: Waiting for master to send event
   Info: NULL
3 rows in set (0.00 sec)

当从SQL线程在执行事件之前等待延迟结束时,SHOW PROCESSLIST将其State值显示为waiting until MASTER_DELAY seconds after master executed event。

在从服务器上设置延迟复制时间为60秒:

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: Connecting to master
                  Master_Host: 10.138.130.243
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000010
          Read_Master_Log_Pos: 2659
               Relay_Log_File: localhost-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: binlog.000010
             Slave_IO_Running: Connecting
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 2659
              Relay_Log_Space: 154
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2
                  Master_UUID: 684e1f7d-6f47-11ef-a6d5-005056a3a162
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 60 --延迟复制时间为60秒
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set: 684e1f7d-6f47-11ef-a6d5-005056a3a162:9-11,
bb8b95d1-6f47-11ef-9592-005056a390e6:9-10,
ca006ef3-6f46-11ef-8203-005056b9a980:1-5
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.00 sec)

主服务器上插入数据

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2024-12-20 17:22:37 |
+---------------------+
1 row in set (0.00 sec)

mysql> insert into t_cs values(6,'ij');
Query OK, 1 row affected (0.03 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2024-12-20 17:22:56 |
+---------------------+
1 row in set (0.00 sec)

从服务器上验证延迟复制

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2024-12-20 17:14:31 |
+---------------------+
1 row in set (0.00 sec)

mysql> select * from t_cs;
+------+------+
| id   | name |
+------+------+
|    1 | cs   |
|    2 | ab   |
|    3 | cd   |
|    4 | ef   |
|    5 | gh   |
+------+------+
5 rows in set (0.00 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2024-12-20 17:14:37 |
+---------------------+
1 row in set (0.00 sec)

mysql> select * from t_cs;
+------+------+
| id   | name |
+------+------+
|    1 | cs   |
|    2 | ab   |
|    3 | cd   |
|    4 | ef   |
|    5 | gh   |
+------+------+
5 rows in set (0.00 sec)

mysql> select now();
+---------------------+
| now()               |
+---------------------+
| 2024-12-20 17:14:51 |
+---------------------+
1 row in set (0.00 sec)

在延迟1分钟后,主服务器上插入的新记录被复制到从服务器

mysql> select * from t_cs;
+------+------+
| id   | name |
+------+------+
|    1 | cs   |
|    2 | ab   |
|    3 | cd   |
|    4 | ef   |
|    5 | gh   |
|    6 | ij   |
+------+------+
6 rows in set (0.01 sec)

MySQL 5.7 半同步复制

半同步复制
除了内置的异步复制之外,MySQL 5.7还支持一个通过插件实现的半同步复制接口。本节讨论什么是半同步复制以及它是如何工作的。以下部分 将介绍半同步复制的管理接口,以及如何安装、配置和监视它。

默认情况下,MySQL的复制是异步的。主服务器将事件写入其二进制日志,但不知道从服务器是否或何时检索并处理了这些事件。使用异步复制 时,如果主服务器崩溃,则它提交的事务可能没有传输到任何从服务器。因此,在这种情况下,从主服务器到从服务器的故障转移可能导致故障 转移到一个相对于主服务器缺少事务的服务器。

半同步复制可以作为异步复制的替代方案:
.从节点表示它连接到主节点时是否具有半同步能力

.如果在主端启用了半同步复制,并且至少有一个半同步从端,那么在主端执行事务提交的线程将阻塞并等待,直到至少一个半同步从端确认它 已接收到该事务的所有事件,或者直到超时发生。

.从属服务器只有在将事务事件写入其中继日志并刷新到磁盘后,才会确认接收到事务事件。

.如果超时发生,而从服务器没有确认事务,则主服务器恢复到异步复制。当至少有一个半同步从端赶上时,主端返回到半同步复制。

.必须在主端和从端同时启用半同步复制。如果在主端禁用了半同步复制,或者在主端启用了半同步复制,但没有从端,则主端使用异步复制

当主服务器阻塞(等待从服务器的确认)时,它不会返回到执行该事务的会话。当阻塞束时,主程序返回到会话,然后可以继续执行其他语句。 此时,事务已在主端提交,并且至少有一个从端已确认其事件的接收。

从MySQL 5.7.3开始,主服务器在处理每个事务之前必须接收的从服务器应答的数量可以使用rpl_semi_sync_master_wait_for_slave_count系统 变量进行配置。缺省值为1。

在写入二进制日志的回滚之后也会发生阻塞,当回滚修改非事务性表的事务时也会发生阻塞。回滚的事务被记录下来,即使它对事务性表没有影 响,因为对非事务性表的修改不能回滚,必须发送到从表。

对于不在事务上下文中出现的语句(即,当没有使用START transaction或SET autocommit = 0启动事务时),启用自动提交,并且每个语句都 隐式提交。对于半同步复制,主程序阻塞每个这样的语句,就像它对显式事务提交所做的那样。

为了理解“半同步复制”中的“semi”是什么意思,将其与异步复制和全同步复制进行比较:
.使用异步复制,主服务器将事件写入其二进制日志,从服务器在准备好时请求事件。不能保证任何事件都会同步到任何一个从服务器。
.使用完全同步复制,当主服务器提交事务时,所有从服务器也将在主服务器返回到执行事务的会话之前提交该事务。这样做的缺点是完成事务 可能会有很多延迟。
.半同步复制介于异步复制和全同步复制之间。主服务器只等待至少一个从服务器接收并记录事件。它不等待所有从服务器确认接收,它只需要 接收,而不需要在从服务器端完全执行和提交事件。

与异步复制相比,半同步复制提供了更好的数据完整性,因为当提交成功返回时,可以知道数据至少存在于两个位置。在半同步主服务器收到 rpl_semi_sync_master_wait_for_slave_count配置的从服务器数量的确认之前,事务处于暂停状态,不会提交。

半同步复制还通过限制二进制日志事件从主服务器发送到从服务器的速度,对繁忙会话设置了速率限制。当一个用户太忙时,这将降低其速度, 这在某些部署情况下很有用。

半同步复制确实有一些性能影响,因为由于需要等待从,提交速度较慢。这是为了提高数据完整性而进行的权衡。减慢的时间至少是TCP/IP往返 时间,从服务器发送提交到从服务器并等待从服务器确认接收。这意味着,对于通过快速网络通信的近距离服务器,半同步复制效果最好,而对 于通过慢速网络通信的远程服务器,效果最差。

rpl_semi_sync_master_wait_point系统变量控制半同步复制主服务器在向提交事务的客户机返回状态之前等待从服务器确认事务接收的时间点 。这些值是允许的:
.AFTER_SYNC(默认值):主服务器将每个事务写入其二进制日志和从服务器,并将二进制日志同步到磁盘。同步完成后,主服务器等待从服务器对 事务接收的确认。接收到确认后,主服务器将事务提交给存储引擎,并将结果返回给客户端,然后客户端就可以继续进行了。
.AFTER_COMMIT:主服务器将每个事务写入其二进制日志和从服务器,同步二进制日志,并将事务提交给存储引擎。在提交之后,主服务器等待从 服务器对事务接收的确认。接收到确认后,主服务器将结果返回给客户端,然后客户端可以继续进行。

这些设置的复制特性区别如下:
.使用AFTER_SYNC,所有客户端同时看到提交的事务:在它被从服务器确认并提交到主服务器上的存储引擎之后。因此,所有客户端都在主服务 器上看到相同的数据。
在主服务器发生故障时,主服务器上提交的所有事务都被复制到从服务器(保存到其中继日志中)。主服务器崩溃和故障转移到从服务器是无损 的,因为从服务器是最新的。

.使用AFTER_COMMIT,发出事务的客户端只有在服务器提交到存储引擎并收到从服务器的确认后才能获得返回状态。在提交之后,在slave确认之 前,其他客户端可以在提交之前看到已提交的事务。
如果出现问题,从服务器无法处理事务,那么在主服务器崩溃并故障转移到从服务器的情况下,这些客户端可能会看到相对于在主服务器上看到 的数据丢失。

半同步复制管理接口
半同步复制的管理接口有几个组件:
.两个插件实现了半同步功能。主端有一个插件,从端有一个插件。
.系统变量控制插件的行为。一些例子:
.rpl_semi_sync_master_enabled
控制是否在主服务器上启用半同步复制。要启用或禁用插件,请分别将该变量设置为1或0。默认值为0(关闭)。
.rpl_semi_sync_master_timeout
一个以毫秒为单位的值,用于控制主服务器在超时并恢复到异步复制之前等待从服务器确认提交的时间。缺省值是10000(10秒)。
.rpl_semi_sync_slave_enabled
类似于rpl_semi_sync_master_enabled,但是控制从属插件。
.状态变量启用半同步复制监控。一些例子:
.Rpl_semi_sync_master_clients
半同步从机的数量
.Rpl_semi_sync_master_status
主端上的半同步复制当前是否正在运行。如果插件已启用且未发生提交确认,则该值为1。如果插件未启用或主服务器由于提交确认超时而退回 到异步复制,则该值为0。
.Rpl_semi_sync_master_no_tx
从服务器未成功确认的提交数。
.Rpl_semi_sync_master_yes_tx
从服务器成功确认的提交数。
.Rpl_semi_sync_slave_status
从端是否正在进行半同步复制。如果插件已启用并且从I/O线程正在运行,则该值为1,否则为0。

系统变量和状态变量只有在使用install plugin安装了适当的主插件或从插件时才可用。

半同步复制是使用插件实现的,因此必须将插件安装到服务器中以使其可用。安装插件后,您可以通过与它关联的系统变量来控制它。在安装相 关插件之前,这些系统变量不可用。

下面介绍如何安装半同步复制插件
使用半同步复制,需要满足以下条件:
.必须安装MySQL 5.5或更高版本。

.安装插件的能力需要MySQL服务器支持动态加载。要验证这一点,请检查系统变量have_dynamic_loading的值是否为YES。二进制发行版应该支 持动态加载

mysql> show variables like 'have_dynamic_loading';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| have_dynamic_loading | YES   |
+----------------------+-------+
1 row in set (0.01 sec)

.复制必须已经在工作

.不能配置多个复制区域通道。半同步复制只兼容默认复制区域通道。

要设置半同步复制,请使用以下说明。这里提到的INSTALL PLUGIN、SET GLOBAL、STOP SLAVE和START SLAVE语句需要SUPER权限。

MySQL发行版包括主端和从端的半同步复制插件文件。

为了能够被主服务器或从服务器使用,适当的插件库文件必须位于MySQL插件目录中(由plugin_dir系统变量命名的目录)。如果有必要,在服 务器启动时设置plugin_dir的值,告诉服务器插件目录的位置。

插件库文件基名为semiync_master和semiync_slave。文件名后缀因平台而异(例如,Unix和类Unix系统为.so, Windows为.dll)。

主插件库文件必须存在于主服务器的插件目录中。从属插件库文件必须存在于每个从属服务器的插件目录中。

要加载插件,请在主服务器和每个半同步的从服务器上使用INSTALL PLUGIN语句(根据需要调整平台的。so后缀)。

主服务器:

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

Query OK, 0 rows affected (0.06 sec)

每个从服务器:

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
Query OK, 0 rows affected (0.03 sec)

如果尝试在Linux上安装插件导致类似于下面所示的错误,你必须安装libimf:

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
ERROR 1126 (HY000): Can't open shared library
'/usr/local/mysql/lib/plugin/semisync_master.so'
(errno: 22 libimf.so: cannot open shared object file:
No such file or directory)

您可以从http://dev.mysql.com/downloads/os-linux.html获取libimf。

要查看安装了哪些插件,请使用SHOW PLUGINS语句,或查询INFORMATION_SCHEMA.PLUGINS表。

要验证插件安装,请检查INFORMATION_SCHEMA。PLUGINS表或使用SHOW PLUGINS语句。

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
+----------------------+---------------+
| PLUGIN_NAME          | PLUGIN_STATUS |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE        |
+----------------------+---------------+
1 row in set (0.00 sec)

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
+---------------------+---------------+
| PLUGIN_NAME         | PLUGIN_STATUS |
+---------------------+---------------+
| rpl_semi_sync_slave | ACTIVE        |
+---------------------+---------------+
1 row in set (0.00 sec)

如果插件初始化失败,请检查服务器错误日志以获取诊断消息。

安装了半同步复制插件后,默认情况下是禁用的。必须在主端和从端同时启用插件才能启用半同步复制。如果只启用了一方,复制将是异步的。

要控制是否启用已安装的插件,请设置适当的系统变量。您可以在运行时使用SET GLOBAL设置这些变量,或者在服务器启动时在命令行或选项文 件中设置这些变量。

在运行时,这些主端系统变量是可用的:

SET GLOBAL rpl_semi_sync_master_enabled = {0|1};
SET GLOBAL rpl_semi_sync_master_timeout = N;

在从属端,这个系统变量是可用的:

SET GLOBAL rpl_semi_sync_slave_enabled = {0|1};

主服务器:

mysql> SET GLOBAL rpl_semi_sync_master_enabled =1;
Query OK, 0 rows affected (0.00 sec)

mysql> SET GLOBAL rpl_semi_sync_master_timeout =1000;
Query OK, 0 rows affected (0.00 sec)

从服务器:

mysql> SET GLOBAL rpl_semi_sync_slave_enabled =1;
Query OK, 0 rows affected (0.01 sec)

对于rpl_semi_sync_master_enabled或rpl_semi_sync_slave_enabled,取值为1表示开启半同步复制,取值为0表示关闭半同步复制。默认情况 下,这些变量被设置为0。

对于rpl_semi_sync_master_timeout,值N以毫秒为单位给出。缺省值是10000 (10秒)。

如果在运行时在从服务器上启用半同步复制,还必须启动从服务器I/O线程 (如果它已经在运行,首先停止它),使从服务器连接到主服务器, 并注册为半同步从服务器:
从服务器:

mysql> STOP SLAVE IO_THREAD;
Query OK, 0 rows affected (0.00 sec)

mysql> START SLAVE IO_THREAD;
Query OK, 0 rows affected (0.00 sec)

主服务器日志:

2024-12-20T08:06:51.512468Z 158 [Note] Stop asynchronous binlog_dump to slave (server_id: 3)
2024-12-20T08:06:51.512514Z 160 [Note] Start binlog_dump to master_thread_id(160) slave_server(3), pos(binlog.000010, 1539)
2024-12-20T08:06:51.512665Z 160 [Note] Start semi-sync binlog_dump to slave (server_id: 3), pos(binlog.000010, 1539)

从服务器日志:

2024-12-16T16:34:53.943377Z 29 [Note] Aborted connection 29 to db: 'jycs' user: 'root' host: 'localhost' (Got timeout reading  communication packets)
2024-12-20T07:57:17.825164Z 37 [Note] Slave I/O thread killed while reading event for channel ''
2024-12-20T07:57:17.825246Z 37 [Note] Slave I/O thread exiting for channel '', read up to log 'binlog.000010', position 1539
2024-12-20T07:57:34.529684Z 40 [Note] Slave I/O thread: Start semi-sync replication to master 'repl@10.138.130.243:3306' in  log 'binlog.000010' at position 1539
2024-12-20T07:57:34.529748Z 40 [Warning] Storing MySQL user name or password information in the master info repository is not  secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see  the 'START SLAVE Syntax' in the MySQL Manual for more information.
2024-12-20T07:57:42.404410Z 40 [Note] Slave I/O thread for channel '': connected to master  'repl@10.138.130.243:3306',replication started in log 'binlog.000010' at position 1539

如果I/O线程已经在运行,而您没有重新启动它,从服务器将继续使用异步复制。
在服务器启动时,可以将控制半同步复制的变量设置为命令行选项或选项文件。选项文件中列出的设置在每次服务器启动时生效。例如,您可以 在主端和从端my.cnf文件中设置如下变量。
主服务器:

[mysql@localhost mysql]$ vi my.cnf
......
[mysqld]
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000 # 1 second

从服务器:

[mysql@localhost mysql]$ vi my.cnf
......
[mysqld]
rpl_semi_sync_slave_enabled=1

半同步复制监控
用于半同步复制功能的插件公开了几个系统和状态变量,您可以检查这些变量以确定其配置和操作状态。

系统变量反映了如何配置半同步复制。要查看它们的值,请使用show variables:
主服务器:

mysql> show variables like 'rpl_semi_sync%';
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | ON         |
| rpl_semi_sync_master_timeout              | 1000       |
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.01 sec)

从服务器:

mysql> show variables like 'rpl_semi_sync%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled     | ON    |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
2 rows in set (0.01 sec)

通过状态变量,可以监控半同步复制的运行情况。要查看它们的值,使用show status:
主服务器:

mysql> show status like 'rpl_semi_sync%';
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients               | 1     |
| Rpl_semi_sync_master_net_avg_wait_time     | 0     |
| Rpl_semi_sync_master_net_wait_time         | 0     |
| Rpl_semi_sync_master_net_waits             | 1     |
| Rpl_semi_sync_master_no_times              | 0     |
| Rpl_semi_sync_master_no_tx                 | 0     |
| Rpl_semi_sync_master_status                | ON    |
| Rpl_semi_sync_master_timefunc_failures     | 0     |
| Rpl_semi_sync_master_tx_avg_wait_time      | 1507  |
| Rpl_semi_sync_master_tx_wait_time          | 1507  |
| Rpl_semi_sync_master_tx_waits              | 1     |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0     |
| Rpl_semi_sync_master_wait_sessions         | 0     |
| Rpl_semi_sync_master_yes_tx                | 1     |
+--------------------------------------------+-------+
14 rows in set (0.00 sec)

从服务器:

mysql> show status like 'rpl_semi_sync%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Rpl_semi_sync_slave_status | ON    |
+----------------------------+-------+
1 row in set (0.01 sec)

当主服务器由于提交阻塞超时或从服务器追赶而在异步或半同步复制之间切换时,它会适当地设置Rpl_semi_sync_master_status状态变量的值 。在主服务器上从半同步复制自动回退到异步复制意味着,即半同步复制实际上目前没有运行,rpl_semi_sync_master_enabled系统变量在主服 务器端的值也可能为1。可以监视Rpl_semi_sync_master_status状态变量,以确定主服务器当前使用的是异步复制还是半同步复制。

要查看连接了多少个半同步从服务器,请检查Rpl_semi_sync_master_clients。

Rpl_semi_sync_master_yes_tx和Rpl_semi_sync_master_no_tx变量表示从服务器成功或不成功确认的提交数量。

从服务器上的Rpl_semi_sync_slave_status表示半同步复制当前是否处于运行状态。

MySQL 5.7 禁用GTID联机事务

在线禁用GTID事务
如何在已经在线的服务器上禁用GTID事务。此过程不需要使服务器离线,适合在生产环境中使用。但是,如果您有可能在禁用GTIDs模式时 使服务器离线,那么这个过程会更容易。

该过程类似于在服务器在线时启用GTID事务,但步骤相反。唯一不同的是等待已记录事务复制的时间点。

在开始之前,请确保服务器满足以下前提条件:
.拓扑中的所有服务器必须使用MySQL 5.7.6或更高版本。您不能在任何一台服务器上在线禁用GTID事务,除非拓扑中的所有服务器都使用此版本 。

.所有服务器都将gtid_mode设置为ON。

1.在每个从服务器上执行以下命令,如果您使用多源复制,请为每个通道执行此操作,并包含for channel channel子句:

STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE = file,MASTER_LOG_POS = position [FOR CHANNEL 'channel'];
START SLAVE [FOR CHANNEL 'channel'];


mysql> stop slave for channel 'master-1';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> stop slave for channel 'master-2';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE ='binlog.000008',MASTER_LOG_POS=194 for channel 'master-1';
Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE ='binlog.000007',MASTER_LOG_POS=194 for channel 'master-2';
Query OK, 0 rows affected (0.00 sec)

mysql> start slave for channel 'master-1';
Query OK, 0 rows affected (0.00 sec)

mysql> start slave for channel 'master-2';
Query OK, 0 rows affected (0.00 sec)

2.在每个服务器上执行:

SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;

mysql> SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
Query OK, 0 rows affected (0.01 sec)

3.在每个服务器上执行:

SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

mysql> SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
Query OK, 0 rows affected (0.03 sec)

4.在每个服务器上,等待变量@@GLOBAL。GTID_OWNED等于空字符串。可以使用以下命令检查:

mysql> SELECT @@GLOBAL.GTID_OWNED;
+---------------------+
| @@GLOBAL.GTID_OWNED |
+---------------------+
|                     |
+---------------------+
1 row in set (0.00 sec)

在复制从机上,从理论上讲,它可能是空的,然后又变为非空的。这不是问题,空一次就足够了。

5.等待当前存在于任何二进制日志中的所有事务复制到所有从属日志
1.在主服务器执行:

SHOW MASTER STATUS;

主库1:10.18.30.50

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+---------------+----------+--------------+------------------+-------------------------------------------+
| binlog.000010 |      194 |              |                  | bb8b95d1-6f47-11ef-9592-005056a390e6:1-10 |
+---------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)


主库2:10.18.30.43

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+---------------+----------+--------------+------------------+-------------------------------------------+
| binlog.000009 |      194 |              |                  | 684e1f7d-6f47-11ef-a6d5-005056a3a162:1-11 |
+---------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

记下“文件和位置”列中的值

2.在每个从属服务器上,使用来自主服务器的文件和位置信息执行:

SELECT MASTER_POS_WAIT('source_log_file', source_log_pos [, timeout][, channel])

从库:10.18.30.39

mysql> SELECT MASTER_POS_WAIT('binlog.000010',194,0,'master-1');
+---------------------------------------------------+
| MASTER_POS_WAIT('binlog.000007',194,0,'master-1') |
+---------------------------------------------------+
|                                                 0 |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT MASTER_POS_WAIT('binlog.000009',194,0,'master-2');
+---------------------------------------------------+
| MASTER_POS_WAIT('binlog.000006',194,0,'master-2') |
+---------------------------------------------------+
|                                                 0 |
+---------------------------------------------------+
1 row in set (0.00 sec)

返回值为0 ,代表从库已经应用了主库1binlog.000010 194与 主库2binlog.000009 194位置的数据。

如果有一个主服务器和多层的从服务器,或者换句话说,有从服务器的从服务器,那么在每层都重复第2步,从主服务器开始,然后是所有的直 接从服务器,然后是所有从服务器的从服务器,以此类推。

6.如果您将二进制日志用于复制以外的其他用途,例如执行时间点备份或恢复:请等到不需要具有GTID事务的旧二进制日志时再使用。

例如,在步骤5完成之后,可以在进行备份的服务器上执行FLUSH LOGS。然后,要么显式地进行备份,要么等待您可能设置的任何定期备份例程 的下一次迭代。

理想情况下,等待服务器清除步骤5完成时存在的所有二进制日志。还要等待步骤5之前所做的备份过期。

这是整个过程中最重要的一点。重要的是要理解,包含GTID事务的日志在下一步之后不能使用。在继续之前,必须确保GTID事务不存在于拓扑中 的任何位置。

7.在每个服务器上执行:

mysql> SET @@GLOBAL.GTID_MODE = OFF;
Query OK, 0 rows affected (0.01 sec)

8.在每个服务器上,在my.cnf文件中设置gtid-mode=OFF
如果你想设置enforce_gtid_consistency=OFF,现在就可以这样做。设置好后,你应该在你的配置文件中添加enforce_gtid_consistency=OFF。

如果您想降级到MySQL的早期版本,现在就可以这样做,使用正常的降级过程。

MySQL 5.7 启用GTID联机事务

启用GTID联机事务
如何在已经在线并使用匿名事务的服务器上启用GTID事务,以及可选的自动定位功能。此过程不需要使服务器离线,适合在生产环境中 使用。但是,如果您可以在启用GTID事务时使服务器脱机,那么处理就会更容易。

在开始安之前,请确保服务器满足以下前提条件:
.拓扑中的所有服务器必须使用MySQL 5.7.6或更高版本。您不能在任何一台服务器上在线启用GTID事务,除非拓扑中的所有服务器都使用此版本 。

.所有服务器都将gtid_mode设置为默认值OFF

启用GTID事务:
1.在每个服务器上执行:

SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;

主库1:10.18.30.50

mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
Query OK, 0 rows affected (0.01 sec)

主库2:10.18.30.43

mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
Query OK, 0 rows affected (0.01 sec)

从库:10.18.30.39

mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
Query OK, 0 rows affected (0.01 sec)

让服务器在正常工作负载下运行一段时间,并监视日志。如果此步骤导致日志中出现任何警告,请调整应用程序,使其只使用gtid兼容的特性, 而不生成任何警告。

这是重要的第一步。在进入下一步之前,必须确保错误日志中没有生成警告。

2.在每个服务器上执行:

SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;

主库1:10.18.30.50

mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
Query OK, 0 rows affected (0.00 sec)

主库2:10.18.30.43

mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
Query OK, 0 rows affected (0.00 sec)

从库:10.18.30.39

mysql> SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
Query OK, 0 rows affected (0.00 sec)

3.在每个服务器上执行:

SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

主库1:10.18.30.50

mysql> SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
Query OK, 0 rows affected (0.01 sec)

主库2:10.18.30.43

mysql> SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
Query OK, 0 rows affected (0.01 sec)

从库:10.18.30.39

mysql> SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
Query OK, 0 rows affected (0.01 sec)

哪个服务器首先执行此语句并不重要,但重要的是,所有服务器都要在任何服务器开始下一步之前完成此步骤。

4.在每个服务器上执行:

SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;

主库1:10.18.30.50

mysql> SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
Query OK, 0 rows affected (0.01 sec)

主库2:10.18.30.43

mysql> SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
Query OK, 0 rows affected (0.01 sec)


从库:10.18.30.39

mysql> SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
Query OK, 0 rows affected (0.01 sec)

哪个服务器先执行该语句并不重要。

5.在每个服务器上,等待状态变量ONGOING_ANONYMOUS_TRANSACTION_COUNT为零。可以使用以下命令进行检查:

SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';

主库1:10.18.30.50

mysql> SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
+-------------------------------------+-------+
| Variable_name                       | Value |
+-------------------------------------+-------+
| Ongoing_anonymous_transaction_count | 0     |
+-------------------------------------+-------+
1 row in set (0.01 sec)

主库2:10.18.30.43

mysql> SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
+-------------------------------------+-------+
| Variable_name                       | Value |
+-------------------------------------+-------+
| Ongoing_anonymous_transaction_count | 0     |
+-------------------------------------+-------+
1 row in set (0.01 sec)

从库:10.18.30.39

mysql> SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
+-------------------------------------+-------+
| Variable_name                       | Value |
+-------------------------------------+-------+
| Ongoing_anonymous_transaction_count | 0     |
+-------------------------------------+-------+
1 row in set (0.01 sec)

注意:在复制从机上,理论上有可能显示为零,然后再次显示为非零。这不是问题,它显示一次零就足够了。

6.等待步骤5之前生成的所有事务复制到所有服务器。您可以在不停止更新的情况下执行此操作:唯一重要的是所有匿名事务都会被复制。
1.在主服务器执行:

SHOW MASTER STATUS;

主库1:10.18.30.50

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+---------------+----------+--------------+------------------+-------------------------------------------+
| binlog.000007 |      194 |              |                  | bb8b95d1-6f47-11ef-9592-005056a390e6:1-10 |
+---------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)


主库2:10.18.30.43

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------------------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                         |
+---------------+----------+--------------+------------------+-------------------------------------------+
| binlog.000006 |      194 |              |                  | 684e1f7d-6f47-11ef-a6d5-005056a3a162:1-10 |
+---------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec)

记下“文件和位置”列中的值

2.在每个从属服务器上,使用来自主服务器的文件和位置信息执行:

SELECT MASTER_POS_WAIT('source_log_file', source_log_pos [, timeout][, channel])

从库:10.18.30.39

mysql> SELECT MASTER_POS_WAIT('binlog.000007',194,0,'master-1');
+---------------------------------------------------+
| MASTER_POS_WAIT('binlog.000007',194,0,'master-1') |
+---------------------------------------------------+
|                                                 0 |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT MASTER_POS_WAIT('binlog.000006',194,0,'master-2');
+---------------------------------------------------+
| MASTER_POS_WAIT('binlog.000006',194,0,'master-2') |
+---------------------------------------------------+
|                                                 0 |
+---------------------------------------------------+
1 row in set (0.00 sec)


mysql> SELECT MASTER_POS_WAIT('binlog.000006',195,0,'master-2');
+---------------------------------------------------+
| MASTER_POS_WAIT('binlog.000006',194,0,'master-2') |
+---------------------------------------------------+
|                                                 0 |
+---------------------------------------------------+
1 row in set (0.00 sec)

返回值为0 ,代表从库已经应用了主库1binlog.000007 194与 主库2binlog.000006 194位置的数据。

如果有一个主服务器和多层的从服务器,或者换句话说,有从服务器的从服务器,那么在每层都重复第2步,从主服务器开始,然后是所有的直 接从服务器,然后是所有从服务器的从服务器,以此类推。

如果使用循环复制拓扑,其中多个服务器可能有写客户端,则对每个主从连接执行步骤2,直到完成整个循环。重复整个过程,这样你就可以完 成整个循环两次。

例如,假设你有3个服务器A、B和C,它们在一个循环中复制A -> B -> C -> A。过程如下:

? Do step 1 on A and step 2 on B.
? Do step 1 on B and step 2 on C.
? Do step 1 on C and step 2 on A.
? Do step 1 on A and step 2 on B.
? Do step 1 on B and step 2 on C.
? Do step 1 on C and step 2 on A.

7.如果您将二进制日志用于除了复制之外的任何事情,例如时间点备份和恢复,请等待,直到您不需要具有没有gtid的事务的旧二进制日志。

例如,在步骤6完成后,可以在正在备份的服务器上执行FLUSH LOGS。然后,要么显式地进行备份,要么等待您可能设置的任何定期备份例程的 下一次迭代。理想情况下,等待服务器清除步骤6完成时存在的所有二进制日志。还要等待步骤6之前所做的备份过期。

这是第二点。理解包含匿名事务的二进制日志(没有gtid)在下一步中是无法使用的,这一点至关重要。在此步骤之后,您必须确保没有GTIDs的 事务在拓扑中不存在。

8.在每个服务器上

mysql> SET @@GLOBAL.GTID_MODE = ON;
Query OK, 0 rows affected (10.06 sec)

9.在每个服务器的my.cnf文件中加上gtid-mode=ON
现在可以保证所有的事务都有一个GTID(除了第5步或更早阶段生成的事务,它们已经被处理过)。要开始使用GTID协议以便稍后执行自动故障转 移,请在每个从服务器上执行以下操作。如果使用多源复制,可选地对每个通道执行此操作,并包括for channel channel子句:

STOP SLAVE [FOR CHANNEL 'channel'];
CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel'];
START SLAVE [FOR CHANNEL 'channel'];


mysql> stop slave for channel 'master-1';
Query OK, 0 rows affected (0.02 sec)

mysql> stop slave for channel 'master-2';
Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO MASTER_AUTO_POSITION = 1 for channel 'master-1';
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO MASTER_AUTO_POSITION = 1 for channel 'master-2';
Query OK, 0 rows affected (0.00 sec)

mysql> start slave for channel 'master-1';
Query OK, 0 rows affected (0.01 sec)

mysql> start slave for channel 'master-2';
Query OK, 0 rows affected (0.00 sec)

MySQL 5.7 多源复制

MySQL多源复制
MySQL多源复制,它使您能够从多个直接主服务器并行复制。介绍多源复制的配置、监控和故障排除方法。

MySQL多源复制概述
MySQL多源复制允许复制从服务器同时接收来自多个源的事务。多源复制可以将多台服务器备份到一台服务器,可以合并表分片,也可以将多台服务器的数据合并到一台服务器。在应用事务时,多源复制不实现任何冲突的检测或解决,如果需要,这些任务将留给应用程序。在多源复制拓扑中,从节点为应该从其接收事务的每个主节点创建复制通道。

配置多源复制
介绍多源复制拓扑的配置方法,以及配置主从拓扑的详细信息。这样的拓扑至少需要配置两个主节点和一个从节点。

可以将多源复制拓扑中的主机配置为使用基于全局事务标识符(GTID)的复制或基于二进制日志位置的复制。

多源复制拓扑中的从服务器需要基于TABLE的存储库。多源复制与基于文件的存储库不兼容。mysqld使用的存储库类型可以在启动时配置,也可以动态配置。

多源复制
主库1:10.18.30.25
主库2:10.18.30.43
从库: 10.18.30.39

1.在主库中创建用于复制的用户
主库1:10.18.30.25

[root@localhost mysql]#  mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'slavepass';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
Query OK, 0 rows affected (0.01 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)

主库2:10.18.30.43
[root@localhost mysql]#  mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'slavepass';
Query OK, 0 rows affected (0.01 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
Query OK, 0 rows affected (0.01 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.02 sec)

2.对主库进行复制相关参数的设置
2.1 配置二进制日志和服务器ID选项

log-bin=mysql-bin
server-id=1

2.2 要配置复制从服务器启动时使用的存储库类型,请使用以下选项启动mysqld:

master-info-repository=TABLE
relay-log-info-repository=TABLE

要修改一个使用FILE存储库的复制从库,使其使用TABLE存储库,需要执行以下命令动态转换现有的复制存储库:

STOP SLAVE;
SET GLOBAL master_info_repository = 'TABLE';
SET GLOBAL relay_log_info_repository = 'TABLE';


mysql> stop slave;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    5
Current database: undo

Query OK, 0 rows affected (0.10 sec)

mysql> SET GLOBAL master_info_repository = 'TABLE';
Query OK, 0 rows affected (0.01 sec)

mysql> SET GLOBAL relay_log_info_repository = 'TABLE';
Query OK, 0 rows affected (0.00 sec)

2.3 如果使用基于全局事务标识符(GTID)的复制,还要检查全局事务标识符(GTID)的设置

mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 1                                    |
| server_id_bits | 32                                   |
| server_uuid    | f044fd89-6b6c-11ef-9f9f-005056a390e6 |
+----------------+--------------------------------------+
3 rows in set (0.01 sec)


mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 2                                    |
| server_id_bits | 32                                   |
| server_uuid    | 3f706e9b-6b6b-11ef-a6e3-005056a3a162 |
+----------------+--------------------------------------+
3 rows in set (0.01 sec)


mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 3                                    |
| server_id_bits | 32                                   |
| server_uuid    | b064fda1-6b68-11ef-8226-005056b9a980 |
+----------------+--------------------------------------+
3 rows in set (0.01 sec)

3.向多源复制从端添加基于GTID的主端
假设您已经使用gtid_mode= on在主服务器上启用了基于GTID的事务,启用了复制用户,并确保从服务器使用基于TABLE的复制存储库。使用CHANGE MASTER TO语句通过使用FOR channel通道子句向通道添加一个新的主通道。

mysql> CHANGE MASTER TO MASTER_HOST='10.18.30.25',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='slavepass',MASTER_AUTO_POSITION=1 FOR CHANNEL 'master-1';
Query OK, 0 rows affected, 2 warnings (0.05 sec)




mysql> CHANGE MASTER TO MASTER_HOST='10.18.30.43',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='slavepass',MASTER_AUTO_POSITION=1 FOR CHANNEL 'master-2';
Query OK, 0 rows affected, 2 warnings (0.01 sec)

启动多源复制从服务器
添加了想要用作复制主机的所有通道后,使用START SLAVE thread_types语句启动复制。当您在从属服务器上启用了多个通道时,您可以选择启动所有通道,或者选择要启动的特定通道。

.启动所有当前配置的复制区域通道

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

从库日志信息显示如下:

2024-09-09T09:16:09.641054Z 11 [Note] Slave I/O thread for channel 'master-1': connected to master 'repl@10.18.30.25:3306',replication started in log 'binlog.000002' at position 1841
2024-09-09T09:16:09.645067Z 13 [Note] Slave I/O thread for channel 'master-2': connected to master 'repl@10.18.30.43:3306',replication started in log 'binlog.000002' at position 1841

主库日志信息显示如下:
主库1:10.18.30.25

2024-09-10T08:40:48.526865Z 4 [Warning] IP address '10.18.30.39' could not be resolved: Temporary failure in name resolution
2024-09-10T08:40:48.534271Z 4 [Note] Start binlog_dump to master_thread_id(4) slave_server(3), pos(binlog.000004, 194)

主库2:10.18.30.43

2024-09-10T08:33:01.936331Z 7 [Warning] IP address '10.18.30.39' could not be resolved: Temporary failure in name resolution
2024-09-10T08:33:01.943408Z 7 [Note] Start binlog_dump to master_thread_id(7) slave_server(3), pos(binlog.000003, 194)

查看从库日志发现出错了。

2024-09-10T07:55:34.529867Z 4 [ERROR] Slave SQL for channel 'master-1': Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9'', Error_code: 1396
2024-09-10T07:55:34.529945Z 4 [Warning] Slave: Operation ALTER USER failed for 'root'@'localhost' Error_code: 1396
2024-09-10T07:55:34.529980Z 4 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'binlog.000002' position 154.
2024-09-10T07:55:34.530177Z 6 [ERROR] Slave SQL for channel 'master-2': Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9'', Error_code: 1396
2024-09-10T07:55:34.530231Z 6 [Warning] Slave: Operation ALTER USER failed for 'root'@'localhost' Error_code: 1396
2024-09-10T07:55:34.530249Z 6 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'binlog.000002' position 154.


2024-09-10T07:55:34.529867Z 4 [ERROR] Slave SQL for channel 'master-1': Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9'', Error_code: 1396
2024-09-10T07:55:34.529945Z 4 [Warning] Slave: Operation ALTER USER failed for 'root'@'localhost' Error_code: 1396
2024-09-10T07:55:34.529980Z 4 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'binlog.000002' position 154.
2024-09-10T07:55:34.530177Z 6 [ERROR] Slave SQL for channel 'master-2': Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9'', Error_code: 1396
2024-09-10T07:55:34.530231Z 6 [Warning] Slave: Operation ALTER USER failed for 'root'@'localhost' Error_code: 1396
2024-09-10T07:55:34.530249Z 6 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'binlog.000002' position 154.

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.18.30.25
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000004
          Read_Master_Log_Pos: 194
               Relay_Log_File: localhost-relay-bin-master@002d1.000002
                Relay_Log_Pos: 361
        Relay_Master_Log_File: binlog.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1396
                   Last_Error: Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9''
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 3214
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1396
               Last_SQL_Error: Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9''
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: bb8b95d1-6f47-11ef-9592-005056a390e6
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 240910 15:55:34
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: bb8b95d1-6f47-11ef-9592-005056a390e6:1-8
            Executed_Gtid_Set: ca006ef3-6f46-11ef-8203-005056b9a980:1-5
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name: master-1
           Master_TLS_Version:
*************************** 2. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.18.30.43
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000003
          Read_Master_Log_Pos: 194
               Relay_Log_File: localhost-relay-bin-master@002d2.000002
                Relay_Log_Pos: 361
        Relay_Master_Log_File: binlog.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1396
                   Last_Error: Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9''
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 2766
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1396
               Last_SQL_Error: Error 'Operation ALTER USER failed for 'root'@'localhost'' on query. Default database: ''. Query: 'ALTER USER 'root'@'localhost' IDENTIFIED WITH 'mysql_native_password' AS '*6BB4837EB74329105EE4568DDA7DC67ED2CA2AD9''
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2
                  Master_UUID: 684e1f7d-6f47-11ef-a6d5-005056a3a162
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 240910 15:55:34
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 684e1f7d-6f47-11ef-a6d5-005056a3a162:1-8
            Executed_Gtid_Set: ca006ef3-6f46-11ef-8203-005056b9a980:1-5
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name: master-2
           Master_TLS_Version:
2 rows in set (0.00 sec)

因为使用基于gtid事务复制,于是尝试使用基于二进制日志的复制

mysql> stop slave;
Query OK, 0 rows affected (0.02 sec)

mysql> reset slave;
Query OK, 0 rows affected (0.02 sec)

mysql> change master to master_auto_position=0;
ERROR 3079 (HY000): Multiple channels exist on the slave. Please provide channel name as an argument.
mysql> change master to master_auto_position=0 for channel 'master-1';
Query OK, 0 rows affected (0.01 sec)

mysql> change master to master_auto_position=0 for channel 'master-2';
Query OK, 0 rows affected (0.01 sec)

mysql> CHANGE MASTER TO   MASTER_HOST='10.18.30.25',MASTER_USER='repl',MASTER_PASSWORD='slavepass',MASTER_LOG_FILE='binlog.000004',MASTER_LOG_POS=194 FOR CHANNEL 'master-1';
Query OK, 0 rows affected, 2 warnings (0.01 sec)

mysql> CHANGE MASTER TO   MASTER_HOST='10.18.30.43',MASTER_USER='repl',MASTER_PASSWORD='slavepass',MASTER_LOG_FILE='binlog.000003',MASTER_LOG_POS=194 FOR CHANNEL 'master-2';
Query OK, 0 rows affected, 2 warnings (0.00 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

查看从库日志

2024-09-10T08:24:19.657675Z 2 [Note] 'CHANGE MASTER TO FOR CHANNEL 'master-1' executed'. Previous state master_host='10.18.30.25', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='10.18.30.25', master_port= 3306, master_log_file='binlog.000004', master_log_pos= 194, master_bind=''.
2024-09-10T08:24:32.746649Z 2 [Note] 'CHANGE MASTER TO FOR CHANNEL 'master-2' executed'. Previous state master_host='10.18.30.43', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='10.18.30.43', master_port= 3306, master_log_file='binlog.000003', master_log_pos= 194, master_bind=''.
2024-09-10T08:24:40.193771Z 7 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2024-09-10T08:24:40.200216Z 8 [Note] Slave SQL thread for channel 'master-1' initialized, starting replication in log 'binlog.000004' at position 194, relay log './localhost-relay-bin-master@002d1.000001' position: 4
2024-09-10T08:24:40.200505Z 9 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2024-09-10T08:24:40.203240Z 10 [Note] Slave SQL thread for channel 'master-2' initialized, starting replication in log 'binlog.000003' at position 194, relay log './localhost-relay-bin-master@002d2.000001' position: 4
2024-09-10T08:24:47.987545Z 9 [Note] Slave I/O thread for channel 'master-2': connected to master 'repl@10.18.30.43:3306',replication started in log 'binlog.000003' at position 194
2024-09-10T08:24:47.987835Z 7 [Note] Slave I/O thread for channel 'master-1': connected to master 'repl@10.18.30.25:3306',replication started in log 'binlog.000004' at position 194

测试同步
主库1:10.18.30.25

mysql> create table t_cs(id int ,name varchar(30));
Query OK, 0 rows affected (0.03 sec)

mysql> insert into t_cs values(1,'cs');
Query OK, 1 row affected (0.01 sec)

mysql> select * from t_cs;
+------+------+
| id   | name |
+------+------+
|    1 | cs   |
+------+------+
1 row in set (0.00 sec)

从库:

mysql> select * from t_cs;
+------+------+
| id   | name |
+------+------+
|    1 | cs   |
+------+------+
1 row in set (0.00 sec)

主库2:10.18.30.43

mysql> create table t_repl(t_id int,t_name varchar(50));
Query OK, 0 rows affected (0.19 sec)

mysql> insert into t_repl values(1,'jy');
Query OK, 1 row affected (0.01 sec)

mysql> select * from t_repl;
+------+--------+
| t_id | t_name |
+------+--------+
|    1 | jy     |
+------+--------+
1 row in set (0.00 sec)

从库:

mysql> select * from t_repl;
+------+--------+
| t_id | t_name |
+------+--------+
|    1 | jy     |
+------+--------+
1 row in set (0.00 sec)



mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.18.30.25
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000004
          Read_Master_Log_Pos: 662
               Relay_Log_File: localhost-relay-bin-master@002d1.000002
                Relay_Log_Pos: 785
        Relay_Master_Log_File: binlog.000004
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 662
              Relay_Log_Space: 1009
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: bb8b95d1-6f47-11ef-9592-005056a390e6
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: bb8b95d1-6f47-11ef-9592-005056a390e6:9-10
            Executed_Gtid_Set: 684e1f7d-6f47-11ef-a6d5-005056a3a162:9-10,
bb8b95d1-6f47-11ef-9592-005056a390e6:9-10,
ca006ef3-6f46-11ef-8203-005056b9a980:1-5
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name: master-1
           Master_TLS_Version:
*************************** 2. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.18.30.43
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000003
          Read_Master_Log_Pos: 669
               Relay_Log_File: localhost-relay-bin-master@002d2.000002
                Relay_Log_Pos: 792
        Relay_Master_Log_File: binlog.000003
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 669
              Relay_Log_Space: 1016
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2
                  Master_UUID: 684e1f7d-6f47-11ef-a6d5-005056a3a162
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 684e1f7d-6f47-11ef-a6d5-005056a3a162:9-10
            Executed_Gtid_Set: 684e1f7d-6f47-11ef-a6d5-005056a3a162:9-10,
bb8b95d1-6f47-11ef-9592-005056a390e6:9-10,
ca006ef3-6f46-11ef-8203-005056b9a980:1-5
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name: master-2
           Master_TLS_Version:

MySQL 5.7 使用全局事务标识符(GTIDs)进行主从复制

使用全局事务标识符进行复制
下面解释使用全局事务标识符(GTIDs)进行基于事务的复制。当使用GTIDs时,每个事务都可以被识别和跟踪,因为它是在原始服务器上提交的, 并由任何从服务器应用;这意味着在启动一个新的slave或故障转移到一个新的master时,使用gtid时不需要引用日志文件或这些文件中的位置, 这大大简化了这些任务。因为基于gtid的复制完全是基于事务的,所以很容易确定主节点和从节点是否一致;只要在主节点上提交的所有事务也 在从节点上提交,就可以保证两者之间的一致性。你可以在GTIDs中使用基于语句或基于行的复制;不过,为了获得最佳效果,我们建议您使用基 于行的格式。

GTID概念
全局事务标识符(GTID)是与原始服务器(主服务器)上提交的每个事务相关联的唯一标识符。此标识符不仅对其发起的服务器是唯一的,而且在给 定复制设置中的所有服务器上也是唯一的。在所有事务和所有gtid之间存在1对1的映射。

以下段落提供了gtid的基本描述。更高级的概念将在后面的章节中介绍:
.GTID集

.mysql.gtid_executed表

.mysql.gtid_executed表压缩

GTID表示为一对坐标,由冒号(:)分隔,如下所示:
GTID = source_id:transaction_id

source_id标识原始服务器。通常,服务器的server_uuid用于此目的。transaction_id是一个序号,由事务在此服务器上提交的顺序决定;例如 ,要提交的第一个事务的transaction_id为1,在同一个原始服务器上要提交的第10个事务的transaction_id为10。在GTID中,事务不可能有0作 为序号。例如,在服务器上提交的第23个事务的UUID是3E11FA47-71CA-11E1-9E33-C80AA9429562,其GTID是这样的:
3E11FA47-71CA-11E1-9E33-C80AA9429562:23

这种格式用于在SHOW SLAVE STATUS等语句的输出以及二进制日志中表示gtid。当使用mysqlbinlog –base64-output=DECODE-ROWS查看日志文件 或在SHOW BINLOG EVENTS的输出中也可以看到它们。

正如在SHOW MASTER STATUS或SHOW SLAVE STATUS等语句的输出中所写的那样,来自同一服务器的gtid序列可以折叠成单个表达式,如下所示。

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

刚才显示的示例表示在server_uuid为3E11FA47-71CA-11E1-9E33-C80AA9429562的MySQL服务器上发起的第一个到第五个事务。

这种格式还用于提供START SLAVE选项所需的参数SQL_BEFORE_GTIDS和SQL_AFTER_GTIDS。

GTID集
GTID集合是全局事务标识符的集合,表示如下:

gtid_set:
uuid_set [, uuid_set] ...
| ''
uuid_set:
uuid:interval[:interval]...
uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
h:
[0-9|A-F]
interval:
n[-n]
(n >= 1)

GTID集在MySQL服务器中有多种使用方式。例如,gtid_executed和gtid_purged系统变量存储的值表示为GTID集合。此外,函数GTID_SUBSET()和 GTID_SUBTRACT()也要求输入GTID集合。当GTID集从服务器变量返回时,uuid按字母顺序排列,数值区间合并并升序排列。

gtid总是保存在master和slave之间。这意味着您总是可以通过检查任何从属服务器上应用的任何事务的二进制日志来确定其来源。此外,一旦 具有给定GTID的事务在给定服务器上提交,该服务器将忽略具有相同GTID的后续事务。因此,在主节点上提交的事务只能在从节点上应用一次, 这有助于保证一致性。

当使用gtid时,从节点不需要任何非本地的数据,例如主节点上一个文件的名称和在该文件中的位置。所有与主节点同步的必要信息都可以直接 从复制数据流中获得。GTIDs替换了之前用来确定在主从之间启动、停止或恢复数据流的点的文件偏移量对。因此,不要在CHANGE MASTER TO语 句中包含MASTER_LOG_FILE或MASTER_LOG_POS选项,这些选项用于指导从主机进行复制;相反,只需要启用MASTER_AUTO_POSITION选项。

GTID的生成和生命周期包括以下步骤:
1. 事务在主服务器上执行和提交
这个事务使用主服务器的UUID和最小的非零事务序列号分配一个GTID;GTID被写入到master的二进制日志中(紧跟在事务本身之前)。

2.在二进制日志数据传输到从服务器并存储到从服务器的中继日志之后(使用针对该进程建立的机制),从服务器读取GTID,并将其gtid_next系 统变量的值设置为该GTID。这告诉从服务器必须使用这个GTID记录下下一个事务。

注意slave在会话上下文中设置gtid_next是很重要的。

3.从服务器验证这个GTID是否已经被用来在它自己的二进制日志中记录事务。如果这个GTID没有被使用,从服务器就会写入GTID,应用事务,并 将事务写入它的二进制日志。在处理事务本身之前,通过首先读取和检查事务的GTID,从服务器不仅保证没有先前拥有该GTID的事务应用于从服 务器,而且还保证没有其他会话已经读取该GTID但尚未提交相关事务。换句话说,不允许多个客户端并发地应用相同的事务。

4.因为gtid_next不为空,所以从服务器并不试图为该事务生成一个GTID,而是将存储在该变量中的GTID,即从主服务器获得的GTID,在其二进 制日志中紧接在事务之前。

mysql.gtid_executed表
mysql.gtid_execute表是在MySQL服务器安装或升级时创建的(如果它不存在),使用如下所示的create table语句:
CREATE TABLE gtid_executed (
source_uuid CHAR(36) NOT NULL,
interval_start BIGINT(20) NOT NULL,
interval_end BIGINT(20) NOT NULL,
PRIMARY KEY (source_uuid, interval_start)
)

警告
与其他MySQL系统表一样,不要尝试自己创建或修改该表。

只有当gtid_mode为ON或ON_PERMISSIVE时,gtid才会存储在mysql.gtid_executed表中。表中存储的gtid与是否启用二进制日志记录无关。但它 们存储的方式取决于log_bin是开启还是关闭。
.如果二进制日志被禁用(log_bin为OFF),服务器将属于每个事务的GTID与表中的事务一起存储。

此外,当二进制日志被禁用时,该表会以用户可配置的速率定期压缩;看mysql.gtid_executed表压缩,以获取更多信息。

.如果启用了二进制日志记录(打开log_bin),那么除了将gtid存储在mysql.gtid_executed表之外,每当二进制日志被轮换或服务器关闭时,服 务器都会将所有写入前一个二进制日志的事务的GTIDs写入到新的二进制日志中。

在服务器意外停止的情况下,之前的二进制日志中的gtid集合不会保存到mysql中。gtid_executed表。在这种情况下,这些gtid会被添加到表中 ,并在恢复期间被添加到gtid_executed系统变量中的gtid集合中。

当启用二进制日志记录时,mysql。gtid_executed表没有提供所有已执行事务的GTIDs的完整记录。该信息由gtid_executed系统变量的全局值提供。

mysql.gtid_executed表被RESET MASTER重置。

mysql.gtid_executed表压缩
随着时间的推移,mysql.gtid_execute表可能会被许多行填充,这些行引用来自同一服务器上的单个gtid,并且其事务id组成一个序列,类似于 下面所示:

mysql> SELECT * FROM mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
|--------------------------------------+----------------+--------------|
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37             | 37           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 38             | 38           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 39             | 39           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 40             | 40           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 41             | 41           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 42             | 42           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 43             | 43           |
...

如果将该表定期压缩,可以将每组这样的行替换为跨越整个事务标识符间隔的单行,这样可以节省相当大的空间,如下所示:

+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
|--------------------------------------+----------------+--------------|
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 |             37 | 43           |
...

当启用GTIDs时,服务器会对mysql.gtid_executed表周期性地执行这种类型的压缩。通过设置executed_gtids_compression_period系统变量, 可以控制压缩表之前允许发生的事务数,从而控制压缩率。这个变量的默认值是1000;这意味着,默认情况下,每1000个事务之后都会对表进行 压缩。将executed_gtid_compression_period设置为0将禁止执行压缩;但是,用户应该做好准备,如果这样做,gtid_executed表可能会需要大 量的磁盘空间

注意:
当启用二进制日志记录时,不使用executed_gtids_compression_period时。每次二进制日志轮换时,mysql.gtid_executed表都会被压缩。

压缩mysql.gtid_execute表是由一个名为thread/sql/compress_gtid_table的专用前台线程执行。这个线程没有在SHOW PROCESSLIST的输出中列 出,但是它可以被看作是线程表中的一行,如下所示:

mysql> SELECT * FROM performance_schema.threads WHERE NAME LIKE '%gtid%'\G
*************************** 1. row ***************************
          THREAD_ID: 26
               NAME: thread/sql/compress_gtid_table
               TYPE: FOREGROUND
     PROCESSLIST_ID: 1
   PROCESSLIST_USER: NULL
   PROCESSLIST_HOST: NULL
     PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Daemon
   PROCESSLIST_TIME: 631286
  PROCESSLIST_STATE: Suspending
   PROCESSLIST_INFO: NULL
   PARENT_THREAD_ID: 1
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: NULL
       THREAD_OS_ID: 24594
1 row in set (0.00 sec)

thread/sql/compress_gtid_table线程通常休眠,直到executed_gtids_compression_period事务被执行,如前所述,然后唤醒执行 mysql.gtid_performed表压缩。然后它休眠,直到另一个executed_gtids_compression_period事务发生,然后唤醒再次执行压缩,无限地重复 这个循环。当禁用二进制日志记录时,将此值设置为0意味着线程始终处于睡眠状态,永远不会醒来。

使用gtid设置复制
对于最简单的GTID复制拓扑(由一个主节点和一个从节点组成),启动过程中的关键步骤如下:
1.如果复制已经在运行,则通过将两台服务器设置为只读来同步它们。

2.停止两个服务器。

3.启用gtid并配置正确的选项并重新启动两个服务器。
启动所描述的服务器所需的mysqld选项将在本节后面的示例中讨论。

注意:
server_uuid必须存在,gtid才能正常工作。

4.指示从服务器使用主服务器作为复制数据源并使用自动定位,然后启动从服务器。完成此步骤所需的SQL语句将在本节后面的示例中描述。

5.做一个新的备份。包含没有gtid的事务的二进制日志不能在启用gtid的服务器上使用,因此在此之前进行的备份不能用于您的新配置。

6.启动从属服务器,然后在两台服务器上再次启用读取模式,以便它们可以接受更新。

在下面的示例中,三台服务器已经分别作为主服务器和从服务器运行,使用MySQL的二进制日志基于位置的复制协议。下面的例子展示了如何在 服务器的选项文件中存储mysqld启动选项。

下面的大多数步骤都需要使用MySQL root帐户或其他具有SUPER权限的MySQL用户帐户。mysqladmin shutdown需要SUPER权限或SHUTDOWN特权。

步骤1:同步服务器。对于已经在进行复制而不是使用gtid方式的服务器才需要执行此步骤。对于新服务器,请继续执行步骤3。通过在每个服务 器上发出以下命令,设置read_only系统变量为ON使服务器只读:

mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 1                                    |
| server_id_bits | 32                                   |
| server_uuid    | 7877044c-a8f0-11ec-be08-005056a390e6 |
+----------------+--------------------------------------+
3 rows in set (0.01 sec)

mysql> SET @@global.read_only = ON;
Query OK, 0 rows affected (0.00 sec)


mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 2                                    |
| server_id_bits | 32                                   |
| server_uuid    | 1c5eb4fb-9479-11ec-8f21-005056a390e6 |
+----------------+--------------------------------------+
3 rows in set (0.06 sec)

mysql> SET @@global.read_only = ON;
Query OK, 0 rows affected (0.00 sec)


mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 3                                    |
| server_id_bits | 32                                   |
| server_uuid    | f08c0957-3d11-11ef-bea6-005056b9a980 |
+----------------+--------------------------------------+
3 rows in set (0.05 sec)

mysql> SET @@global.read_only = ON;
Query OK, 0 rows affected (0.00 sec)

等待所有正在进行的事务提交或回滚。然后,让从服务器追上主服务器。在继续工作之前,确保从服务器已经处理了所有的更新是极其重要的。

如果您将二进制日志用于除复制之外的任何事情,例如执行时间点备份和恢复,请等待,直到您不需要包含没有gtid的事务的旧二进制日志。理 想情况下,应该等待服务器清除所有二进制日志,并等待任何现有的备份过期。

重点
重要的是要理解,包含没有gtid的事务的日志不能在启用了gtid的服务器上使用。在继续之前,必须确保没有gtid的事务在拓扑中的任何位置都 不存在。

步骤2:
停止所有服务器。使用如下所示的mysqladmin停止每个服务器,其中username是MySQL用户的用户名,该用户有足够的权限关闭服务器:

shell> mysqladmin -uusername -p shutdown

然后在提示符下输入该用户的密码。

关闭主库

[root@localhost ~]# mysqladmin -uroot -pxxzx7817600 shutdown
mysqladmin: [Warning] Using a password on the command line interface can be insecure.

关闭两个从库

[root@localhost /]# mysqladmin -uroot -pxxzx7817600 shutdown
mysqladmin: [Warning] Using a password on the command line interface can be insecure.

[root@localhost mysql]# mysqladmin -uroot -pxxzx7817600 shutdown
mysqladmin: [Warning] Using a password on the command line interface can be insecure.

步骤3:启动所有启用gtid的服务器。要启用基于GTID的复制,每个服务器必须以启用GTID模式的方式启动,即通过将gtid_mode变量设置为ON, 并启用enforce_gtid_consistency变量以确保只记录适用于基于GTID复制的语句。此外,在配置从服务器设置之前,应以“–skip-slave-start ”选项启动从服务器。

为了使用gtid,并不是必须启用二进制日志记录,因为在MySQL 5.7.5添加了mysql.gtid_execute表,这意味着从服务器可以只使用gtid而不需要 二进制日志记录。主服务器必须始终启用二进制日志记录,以便能够进行复制。例如,要启动启用gtid但没有二进制日志记录的从服务器,请在 服务器的选项文件中配置这些变量:

gtid_mode=ON
enforce-gtid-consistency=true

修改主服务器的参数配置

[root@localhost ~]# vi /mysqlsoft/mysql/my.cnf
gtid_mode=ON
enforce-gtid-consistency=true

修改两个从服务器的参数配置

[root@localhost /]# vi /mysqlsoft/mysql/my.cnf
gtid_mode=ON
enforce-gtid-consistency=true
skip-slave-start=1

[root@localhost mysql]# vi /mysqlsoft/mysql/my.cnf
gtid_mode=ON
enforce-gtid-consistency=true
skip-slave-start=1

根据您的配置,为mysqld提供额外的选项。

启动主服务器

[root@localhost ~]# service mysqld start
Starting MySQL.... SUCCESS!

启动两个从服务器

[root@localhost /]# service mysqld start
Starting MySQL.. SUCCESS!

[root@localhost mysql]# service mysqld start
Starting MySQL.. SUCCESS!

步骤4:配置从服务器使用基于gtid的自动定位。告诉从服务器使用基于GTID事务的主服务器作为复制数据源,并使用基于GTID的自动定位,而 不是基于文件的定位。在从服务器上发出CHANGE MASTER TO语句,包括MASTER_AUTO_POSITION选项告诉从服务器,主服务器的事务是由gtid标识 的。

您可能还需要为主服务器的主机名和端口号提供适当的值,以及用于从服务器连接到主服务器的复制用户帐户的用户名和密码;如果在步骤1之前 已经设置了这些选项,并且不需要进行进一步的更改,则可以安全地从这里显示的语句中省略相应的选项。

对所有从服务器执行以下命令

mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 2                                    |
| server_id_bits | 32                                   |
| server_uuid    | 1c5eb4fb-9479-11ec-8f21-005056a390e6 |
+----------------+--------------------------------------+
3 rows in set (0.06 sec)

mysql> CHANGE MASTER TO  MASTER_HOST='10.138.130.250',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='slavepass',MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.03 sec)



mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 3                                    |
| server_id_bits | 32                                   |
| server_uuid    | f08c0957-3d11-11ef-bea6-005056b9a980 |
+----------------+--------------------------------------+
3 rows in set (0.00 sec)


mysql> CHANGE MASTER TO  MASTER_HOST='10.138.130.250',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='slavepass',MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

MASTER_LOG_FILE选项和MASTER_LOG_POS选项都不能在MASTER_AUTO_POSITION设置为1时使用。尝试这样做会导致CHANGE MASTER to语句失败并出现错误。

步骤5:做一个新的备份。在启用gtid之前所做的现有备份不能再在启用gtid后的这些服务器上使用。此时进行新的备份,这样就不会没有可用 的备份。

例如,您可以在进行备份的服务器上执行FLUSH LOGS。然后,要么显式地进行备份,要么等待您可能设置的任何定期备份例程的下一次迭代。
对主库执行备份

mysql> FLUSH LOGS;
Query OK, 0 rows affected (0.01 sec)

[root@localhost ~]# mysqldump -uroot -pxxzx7817600 --all-databases --master-data > dbdump20240711.db
mysqldump: [Warning] Using a password on the command line interface can be insecure.
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that  changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete  dump, pass --all-databases --triggers --routines --events.

步骤6:启动从服务器并禁用只读模式。像这样启动slave:

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

只有在步骤1中将服务器配置为只读时,才需要执行以下步骤。要允许服务器再次开始接受更新,请发出以下语句:
从库

mysql> SET @@global.read_only = OFF;
Query OK, 0 rows affected (0.00 sec)

mysql> SET @@global.read_only = OFF;
Query OK, 0 rows affected (0.00 sec)

主库

mysql> SET @@global.read_only = OFF;
Query OK, 0 rows affected (0.00 sec)

基于gtid的复制现在应该正在运行,可以像以前一样在主服务器上开始(或恢复)进行操作。

下面来进行验证
主库

mysql> create table t5(id int primary key not null,name varchar(30),age int not null);
Query OK, 0 rows affected (0.07 sec)

mysql> desc t5;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | NO   | PRI | NULL    |       |
| name  | varchar(30) | YES  |     | NULL    |       |
| age   | int(11)     | NO   |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

从库
1.

mysql> desc t5;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | NO   | PRI | NULL    |       |
| name  | varchar(30) | YES  |     | NULL    |       |
| age   | int(11)     | NO   |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

2.

mysql> desc t5;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | NO   | PRI | NULL    |       |
| name  | varchar(30) | YES  |     | NULL    |       |
| age   | int(11)     | NO   |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

主库:

mysql> insert into t5 values(1,'jingyong',39);
Query OK, 1 row affected (0.00 sec)

mysql> select * from t5;
+----+----------+-----+
| id | name     | age |
+----+----------+-----+
|  1 | jingyong |  39 |
+----+----------+-----+
1 row in set (0.01 sec)

从库
1.

mysql> select * from t5;
+----+----------+-----+
| id | name     | age |
+----+----------+-----+
|  1 | jingyong |  39 |
+----+----------+-----+
1 row in set (0.00 sec)

2.

mysql> select * from t5;
+----+----------+-----+
| id | name     | age |
+----+----------+-----+
|  1 | jingyong |  39 |
+----+----------+-----+
1 row in set (0.00 sec)

可以看到同步正常。

MySQL 5.7向主从复制环境增加从库

向复制环境添加从机
可以在不停止主复制的情况下向现有复制配置添加另一个从复制。相反,可以通过创建一个现有从属服务器的副本来设置新的从属服务器,只不 过要用不同的服务器id值来配置新的从属服务器。

复制一个已存在的从节点。
1.关闭现有从服务器:

[mysql@localhost ~]$ mysqladmin -uroot -pxxzx7817600 shutdown
mysqladmin: [Warning] Using a password on the command line interface can be insecure.

2.将数据目录从现有的从服务器复制到新的从服务器。您可以通过使用tar或WinZip创建存档,或者使用cp或rsync等工具执行直接复制来实现这 一点。确保还复制了日志文件和中继日志文件。

[root@localhost mysql]# rsync -avz * root@10.138.130.239:/mysqldata/mysql/
The authenticity of host '10.138.130.239 (10.138.130.239)' can't be established.
ECDSA key fingerprint is 7f:1f:9a:0f:8b:d1:e0:17:32:08:12:73:d8:1d:9c:da.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.138.130.239' (ECDSA) to the list of known hosts.
root@10.138.130.239's password:
sending incremental file list
binlog.006119
ib_buffer_pool
ib_logfile0
ibdata1
localhost-relay-bin.000004
localhost-relay-bin.000005
localhost-relay-bin.index
master.info
mysql.err
relay-log.info
.........

sent 86590 bytes  received 262429 bytes  4748.56 bytes/sec
total size is 22282098540  speedup is 63842.08

在添加新的复制从服务器时遇到的一个常见问题是,新的从服务器失败,并显示一系列警告和错误消息,如下所示:

071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
replication may break when this MySQL server acts as a slave and has his hostname
changed!! Please use '--relay-log=new_slave_hostname-relay-bin' to avoid this problem.
071118 16:44:10 [ERROR] Failed to open the relay log './old_slave_hostname-relay-bin.003525'
(relay_log_pos 22940879)
071118 16:44:10 [ERROR] Could not find target log during relay log initialization
071118 16:44:10 [ERROR] Failed to initialize the master info structure

发生这种问题最可能的原因是启动mysql时没有指明–relay-log参数,在没有指定这个参数的情况下relay log会默认以主机名为前缀生成日志 文件。如果不指定–relay-log-index,relay log index文件也是如此。

要避免这个问题,把新从库的–relay-log的值设置为与原来的从库一致。如果原来的从库没有设置这个参数,那么把新从库的–relay-log参 数设置为existing_slave_hostname-relay-bin。如果不能这样设置,把原来从库的relay log索引文件复制到新从库,并设置新从库的– relay-log-index与原来从库的这个参数一致。如果原来从库没有设置–relay-log-index,把新从库的–relay-log-index设置为 existing_slave_hostname-relay-bin.index。

[root@localhost mysql]# vi /mysqlsoft/mysql/my.cnf
relay-log=localhost-relay-bin
relay-log-index=localhost-relay-bin.index

如果已经执行了后边步骤,在启动新从库的时候遇到这个问题,请执行以下步骤:

a.在新从库和原从库上执行stop slave

b.复制原来的从库的relay log索引文件到新从库,确保覆盖新从库的relay log索引文件。

c.执行后边的步骤。

3.复制原来从库的master info和relay log info文件到新从库。(这两个也可能存在表里边,跟如何配置的有关)这两个文件保存了当前的主 库binlog的坐标和从库relay log的坐标。

4.start原来的从库

[root@localhost mysql]# service mysqld start
Starting MySQL.. SUCCESS!

5.编辑新从库的配置文件,给新从库配置一个不同于现在主从结构中服务器的server-id

[root@localhost mysql]# vi /mysqlsoft/mysql/my.cnf
server-id=3

6.启动新从库。从服务器使用其主信息存储库中的信息启动复制进程。

[root@localhost mysql]# service mysqld start
Starting MySQL.. SUCCESS!

但是原来的从库出现以下错误

2024-07-08T09:50:20.245669Z 5 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary  log: 'A slave with the same server_uuid/server_id as this slave has connected to the master; the first event 'binlog.000183'  at 1395, the last event read from '/mysqldata/mysql/binlog.000183' at 1848, the last byte read from  '/mysqldata/mysql/binlog.000183' at 1848.', Error_code: 1236


mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 2                                    |
| server_id_bits | 32                                   |
| server_uuid    | 1c5eb4fb-9479-11ec-8f21-005056a390e6 |
+----------------+--------------------------------------+
3 rows in set (0.00 sec)

mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 3                                    |
| server_id_bits | 32                                   |
| server_uuid    | 1c5eb4fb-9479-11ec-8f21-005056a390e6 |
+----------------+--------------------------------------+
3 rows in set (0.90 sec)

因为新从库是用原来的从库复制而来,所以在${data_dir}/auto.cnf中的server-uuid值是一样的,要处理该问题只需要删除新从库中的auto.cnf文件,就会自动创建和生成新的server-uuid值。

[root@localhost mysql]# ll auto.cnf
-rwxrwxr-x. 1 mysql mysql 56 Feb 23  2022 auto.cnf
[root@localhost mysql]# rm -rf auto.cnf
[root@localhost mysql]# ll auto.cnf
ls: cannot access auto.cnf: No such file or directory

[root@localhost mysql]# service mysqld start
Starting MySQL..... SUCCESS!
[root@localhost mysql]# ll auto.cnf
-rw-r-----. 1 mysql mysql 56 Jul  8 18:07 auto.cnf

mysql> show variables like '%server%id%';
+----------------+--------------------------------------+
| Variable_name  | Value                                |
+----------------+--------------------------------------+
| server_id      | 3                                    |
| server_id_bits | 32                                   |
| server_uuid    | f08c0957-3d11-11ef-bea6-005056b9a980 |
+----------------+--------------------------------------+
3 rows in set (0.00 sec)

验证主从同步
主库

mysql> create table t4(t_id int primary key not null,t_name varchar(30));
Query OK, 0 rows affected (0.02 sec)

mysql>  insert into t4 values(1,'jingyong');
Query OK, 1 row affected (0.01 sec)

mysql> select * from t4;
+------+----------+
| t_id | t_name   |
+------+----------+
|    1 | jingyong |
+------+----------+
1 row in set (0.00 sec)

原来从库

mysql> select * from t4;
+------+----------+
| t_id | t_name   |
+------+----------+
|    1 | jingyong |
+------+----------+
1 row in set (0.00 sec)

新从库

mysql> select * from t4;
+------+----------+
| t_id | t_name   |
+------+----------+
|    1 | jingyong |
+------+----------+
1 row in set (0.00 sec)

MySQL基于二进制日志文件的主从复制

基于二进制日志文件位置的复制配置概述
本节描述了基于二进制日志文件定位方法的MySQL服务器之间的复制,其中MySQL实例作为主(数据库更改的源)将更新和更改作为“事件”写入二 进制日志。根据记录的数据库变化,二进制日志中的信息以不同的日志格式存储。从节点被配置为从主节点读取二进制日志,并在从节点的本地 数据库上执行二进制日志中的事件。

每个从服务器接收二进制日志全部内容的副本。从服务器负责决定应该执行二进制日志中的哪些语句。除非您另行指定,否则主二进制日志中的 所有事件都在从二进制日志上执行。如果需要,可以将从服务器配置为只处理适用于特定数据库或表的事件。不能将主服务器配置为只记录某些事件

每个从服务器保存二进制日志坐标的记录:从服务器读取和处理的文件中的文件名和位置。这意味着可以将多个从服务器连接到主服务器,并执 行同一二进制日志的不同部分。因为从服务器控制这个过程,所以可以在不影响主服务器操作的情况下连接和断开各个从服务器。另外,由于每 个从服务器都在二进制日志中记录当前位置,因此有可能断开连接,重新连接,然后恢复处理。

主服务器和每个从服务器必须配置一个唯一的ID(使用server-id选项)。此外,每个从服务器必须配置有关主主机名、日志文件名和该文件中的 位置的信息。这些细节可以在从服务器上的MySQL会话中使用CHANGE MASTER TO的语句来控制。详细信息存储在从服务器的主信息存储库中,主 信息存储库可以是文件也可以是表。

设置基于二进制日志文件位置的复制
本节介绍如何设置MySQL服务器以使用基于二进制日志文件位置的复制。设置复制有许多不同的方法,具体使用哪种方法取决于设置复制的方式 ,以及主数据库中是否已经有数据。

有一些通用任务对所有设置都是通用的:
.在主服务器上,必须启用二进制日志记录并配置唯一的服务器ID。这可能需要重新启动服务器。

.在要连接到主服务器的每个从服务器上,必须配置唯一的服务器ID。这可能需要重新启动服务器。

.还可以为从服务器创建一个单独的用户,以便在与主服务器进行身份验证时读取二进制日志进行复制时使用。

.在创建数据快照或启动复制过程之前,应该在主服务器上记录二进制日志中的当前位置。在配置从服务器时需要这些信息,以便从服务器知道 在二进制日志的哪个位置开始执行事件。

.如果您已经在主服务器上有数据,并且希望使用它来同步从服务器,则需要创建数据快照将数据复制到从服务器上。您使用的存储引擎会影响 您创建快照的方式。在使用MyISAM时,必须停止处理主服务器上的语句以获得读锁,然后获取其当前二进制日志坐标并转储其数据,然后才允许 主服务器继续执行语句。如果不停止语句的执行,数据转储和主状态信息将不匹配,导致不一致。如果你使用的是InnoDB,你不需要一个读锁, 一个足够长的事务来传输数据快照就足够了。

.为从服务器配置连接到主服务器的设置,例如主机名、登录凭据、二进制日志文件名和位置。

注意:设置过程中的某些步骤需要SUPER权限。如果您没有此权限,则可能无法启用复制。

配置完基本选项后,选择您的场景:
.为不包含数据的主服务器和从服务器的新安装设置复制。

.使用现有MySQL服务器上的数据建立一个新的主服务器的复制。

.要向现有复制环境添加复制从节点。

设置复制主配置
要将主机配置为使用基于二进制日志文件位置的复制,必须启用二进制日志记录并建立唯一的服务器ID。如果还没有这样做,则需要重新启动服 务器。

必须在主服务器上启用二进制日志记录,因为二进制日志是将更改从主服务器复制到从服务器的基础。如果没有在使用log-bin选项的主机上启 用二进制日志记录,则无法进行复制。

复制组中的每个服务器必须配置唯一的服务器ID。该ID用于标识组内的各个服务器,必须是1 ~2的32次方?1之间的正整数。你如何组织和选择数 字是你的选择。

要配置二进制日志和服务器ID选项,请关闭MySQL服务器并编辑my.cnf或my.ini文件。在配置文件的[mysqld]部分中,添加log-bin和server-id 选项。如果这些选项已经存在,但是被注释掉了,取消这些选项的注释,并根据您的需要更改它们。例如,要使用日志文件名前缀mysql-bin启 用二进制日志记录,并配置服务器ID为1,使用以下行:

[mysqld]
log-bin=mysql-bin
server-id=1

进行更改后,重新启动服务器。

注意:
以下选项对该过程有影响:
.如果省略server-id(或将其显式设置为默认值0),主服务器将拒绝来自从服务器的任何连接。

.为了在使用InnoDB事务的复制设置中获得最大的持久性和一致性,您应该在主my.cnf文件中使用innodb_flush_log_at_trx_commit=1和 sync_binlog=1。

.确保在复制主机上未启用跳过网络连接选项。如果禁用网络连接,则从端无法与主端通信,导致复制失败。

创建复制用户
每个从服务器使用一个MySQL用户名和密码连接到主服务器,所以在主服务器上必须有一个从服务器可以用来连接的用户帐户。任何帐户都可以 用于此操作,前提是该帐户已被授予REPLICATION SLAVE特权。您可以选择为每个从服务器创建一个不同的帐户,或者为每个从服务器使用相同 的帐户连接到主服务器。

虽然不必专门为复制创建帐户,但应该知道复制用户名和密码以明文形式存储在主信息存储库文件或表中。因此,您可能需要创建一个单独的帐 户,该帐户仅对复制过程具有特权,以尽量减少危及其他帐户的可能性。

要创建一个新帐户,请使用create USER。要向该帐户授予复制所需的特权,请使用grant语句。如果仅为复制目的创建帐户,则该帐户只需要 replication SLAVE特权。例如,要设置一个新用户repl,它可以从任何主机连接进行复制,请在主服务器上发出以下语句:

mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'slavepass';
Query OK, 0 rows affected (0.00 sec)

mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
Query OK, 0 rows affected (0.01 sec)


[root@localhost mysql]# mysql -h 10.13.13.50 -P 3306 -urepl -pslavepass
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
+--------------------+
1 row in set (0.00 sec)

mysql> exit

获取复制主二进制日志坐标
要配置从服务器以在正确的点启动复制过程,您需要主服务器的二进制日志中的当前坐标。

如果master之前没有启用二进制日志,那么SHOW MASTER STATUS或mysqldump –master-data显示的日志文件名和位置值都是空的。在这种情况 下,你需要在稍后指定从服务器的日志文件和位置时使用空字符串(“)和4。

如果之前主服务器已经有二进制日志记录,可以使用下面的过程来获取主服务器的二进制日志坐标:

警告
这个过程使用了FLUSH TABLES WITH READ LOCK,阻塞了InnoDB表的COMMIT操作。

1.通过命令行客户端连接到主服务器,在主服务器上启动会话,并通过执行FLUSH TABLES WITH READ LOCK语句来清空所有表和阻塞写语句。

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.01 sec)

警告
让发出FLUSH TABLES语句的客户端继续运行,这样读锁仍然有效。如果退出客户端,锁将被释放。

2.在主服务器上的另一个会话中,使用SHOW MASTER STATUS语句来确定当前二进制日志文件名和位置:

[root@localhost ~]# mysql -uroot -ptest12345 mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 6
Server version: 5.7.26-log Source distribution

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000183 |      326 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

“File”列显示日志文件的名称,“Position”列显示在文件中的位置。在此例中,二进制日志文件为binlog.000183,位置是326。记录这些值 。稍后在设置slave时需要它们。它们表示从服务器开始处理来自主服务器的新更新的复制坐标。

现在,您已经获得了所需的信息,使从服务器能够从正确位置的二进制日志开始读取,从而开始复制。

下一步取决于您是否在主服务器上已有数据。选择下列选项之一:
.如果在开始复制之前有需要与从服务器同步的现有数据,请保持客户端运行,以便锁保持在适当位置。这可以防止任何进一步的更改,以便复 制到从服务器的数据与主服务器保持同步。

.如果您正在建立一个新的主从复制组,您可以退出第一个会话以释放读锁

选择数据快照的方法
如果主数据库包含现有数据,则有必要将这些数据复制到每个从数据库。从主数据库转储数据有不同的方法。以下部分描述了可能的选项。

要选择适当的转储数据库的方法,请在以下选项中进行选择:
.使用mysqldump工具创建要复制的所有数据库的转储。这是推荐的方法,特别是在使用InnoDB时。

.如果数据库存储在二进制可移植文件中,则可以将原始数据文件复制到从服务器。这可能比使用mysqldump并在每个slave上导入文件更有效, 因为它跳过了在重播INSERT语句时更新索引的开销。对于InnoDB这样的存储引擎,不建议这样做。

使用mysqldump创建数据快照
使用mysqldump工具对现有主数据库中的数据创建快照。完成数据转储后,在启动复制进程之前将该数据导入从服务器。

下面的例子将所有数据库转储到一个名为dbdump.db的文件中,并包含–masterdata选项,它会自动在slave上添加CHANGE MASTER TO语句以启动 复制过程:
[root@localhost ~]# mysqldump -uroot -ptest12345 –all-databases –master-data > dbdump.db
mysqldump: [Warning] Using a password on the command line interface can be insecure.
[root@localhost ~]# ll dbdump.db
-rw-r–r–. 1 root root 4657877334 Jul 2 16:49 dbdump.db
[root@localhost ~]# du -sh dbdump.db
4.5G dbdump.db

注意:
如果不使用–master-data,则必须手动锁定单独会话中的所有表。

使用mysqldump工具可以从转储中排除某些数据库。如果要选择转储中包含哪些数据库,请不要使用–all-databases。选择以下选项之一:
.使用–ignore-table选项排除数据库中的所有表

.使用–atabases选项只命名那些您想要转储的数据库

要导入数据,可以将转储文件复制到从服务器,或者在远程连接到从服务器时从主服务器访问该文件。

[root@localhost ~]# mysql -h 10.13.13.43 -P 3306 -uroot -ptest1234 < dbdump.db
mysql: [Warning] Using a password on the command line interface can be insecure.

使用原始数据文件创建数据快照
本节描述如何使用组成数据库的原始文件创建数据快照。对于使用具有复杂缓存或日志算法的存储引擎的表,使用这种方法需要额外的步骤来生 成完美的“时间点”快照:初始复制命令可能会忽略缓存信息和日志更新,即使您已经获得了全局读锁。存储引擎如何响应这取决于它的崩溃恢 复能力。

如果你使用的是InnoDB表,你可以使用MySQL企业版的mysqlbackup命令备份组件以生成一致性快照。该命令记录从机上要使用的快照对应的日志 名称和偏移量。

如果主服务器和从服务器的ft_stopword_file、ft_min_word_len或ft_max_word_len的值不同,并且您正在复制具有全文索引的表,那么这种方 法也不能可靠地工作。

假设上述异常不适用于您的数据库,请使用冷备份技术获取InnoDB表的可靠二进制快照:慢速关闭MySQL服务器,然后手动复制数据文件。

当您的MySQL数据文件存在于单个文件系统中时,要创建MyISAM表的原始数据快照,您可以使用标准的文件复制工具,如cp或copy,远程复制工 具,如scp或rsync,归档工具,如zip或tar,或文件系统快照工具,如dump。如果只复制某些数据库,则只复制与这些表相关的文件。对于 InnoDB,所有数据库中的所有表都存储在系统表空间文件中,除非你启用了innodb_file_per_table选项。

复制不需要以下文件:
.mysql数据库相关文件。

.主信息存储库文件(如果使用)。

.主机的二进制日志文件。

.任何中继日志文件。

根据您是否使用InnoDB表,选择以下一种:

如果你使用的是InnoDB表,并且想要获得与原始数据快照最一致的结果,请在此过程中关闭主服务器,如下所示:
1.获取读锁并获取主库状态

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

2.在一个单独的会话中,关闭主服务器:

shell> mysqladmin shutdown

3.复制MySQL数据文件。下面的示例展示了实现此目的的常用方法。你只需要选择其中一个:

shell> tar cf /tmp/db.tar ./data
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata

4.重新启动主服务器。

如果您不使用InnoDB表,您可以从主服务器获取系统快照,而无需关闭服务器,如下所示:
1.获取读锁并获取主库状态

mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

2.复制MySQL数据文件。下面的示例展示了实现此目的的常用方法。你只需要选择其中一个:

shell> tar cf /tmp/db.tar ./data
shell> zip -r /tmp/db.zip ./data
shell> rsync --recursive ./data /tmp/dbdata

3.在获取读锁的客户端,释放该锁:

mysql> UNLOCK TABLES;

创建了数据库的存档或副本之后,在启动从复制进程之前,将文件复制到每个从服务器。

设置复制从服务器
下面描述如何设置从服务器。在你继续之前,确保你有:
.用必要的配置属性配置MySQL主机。

.获取主库状态信息。

.在主服务器上,释放读锁。

mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)

设置复制从服务器配置
每个复制从服务器必须有一个唯一的服务器ID。如果还没有这样做,从服务器设置的这一部分需要重新启动服务器。

如果从服务器ID尚未设置,或者当前值与您为主服务器选择的值冲突,请关闭从服务器并编辑配置文件的[mysqld]部分以指定唯一的服务器ID。 例如:

[root@localhost ~]# service mysqld stop
Shutting down MySQL. SUCCESS!

[mysql@localhost mysql]$ vi my.cnf
[mysqld]
server-id=2

进行更改后,重新启动服务器。

[root@localhost mysql]# service mysqld start
Starting MySQL... SUCCESS!

如果要设置多个从服务器,则每个从服务器必须具有唯一的服务器id值,该值与主服务器和任何其他从服务器的服务器id值不同。

注意:
如果省略server-id(或将其显式设置为默认值0),从服务器将拒绝连接到主服务器。

您不必在从服务器上启用二进制日志记录,就可以设置复制。但是,如果在从属服务器上启用二进制日志记录,则可以使用从属服务器的二进制 日志进行数据备份和崩溃恢复,还可以将从属服务器用作更复杂的复制拓扑的一部分。例如,这个从服务器充当其他从服务器的主库。

在从服务器上设置主配置
要设置从服务器与主服务器通信以进行复制,请使用必要的连接信息配置从服务器。为此,在从属服务器上执行以下语句,将选项值替换为与系 统相关的实际值:

mysql> CHANGE MASTER TO   MASTER_HOST='10.13.13.50',MASTER_USER='repl',MASTER_PASSWORD='slavepass',MASTER_LOG_FILE='binlog.000183',MASTER_LOG_POS=326 ;
Query OK, 0 rows affected, 2 warnings (0.14 sec)

注意:
复制不能使用Unix套接字文件。你必须能连接到主服务器MySQL服务器使用TCP/IP。CHANGE MASTER TO语句还有其他选项。例如,可以使用SSL设置安全复制。

启动从线程:

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

在执行此过程之后,从服务器连接到主服务器,并复制自拍摄快照以来在主服务器上发生的任何更新。

如果没有正确设置主服务器的server-id选项,则从服务器无法连接到主服务器。类似地,如果你没有为slave设置正确的server-id选项,你会 在slave的错误日志中得到以下错误:

Warning: You should set server-id to a non-0 value if master_host
is set; we will force server id to 2, but this MySQL server will
not act as a slave.

如果由于任何其他原因无法复制,您还可以在从属服务器的错误日志中找到错误消息。

从节点在其主服务器的信息存储库中存储了用户配置的关于主节点的信息。主服务器的信息存储库可以是文件的形式,也可以是表的形式,这由 –masterinfo- repository的值决定。当一个从节点使用–master-info-repository=FILE时,数据目录中会存储两个文件,分别名为 master.info和relay-log.info。相反,如果–master-info-repository=TABLE,则该信息保存在mysql数据库的master_slave_info表中。无论 哪种情况,都不要删除或编辑文件或表。始终使用CHANGE MASTER TO语句更改复制参数。从节点可以使用语句中指定的值自动更新状态文件。

注意:
主服务器的信息存储库的内容覆盖在命令行或my.cnf中指定的一些服务器选项。

一个主服务器的快照就可以满足多个从服务器的需求。要设置额外的从服务器,请使用相同的主服务器快照,并遵循上述过程的从服务器部分。

[root@localhost mysql]# pwd
/mysqldata/mysql
[root@localhost mysql]# ll master.info

[root@localhost mysql]# ll relay-log.info
-rw-r-----. 1 mysql mysql 62 Jul  4 17:50 relay-log.info

在主库中向表t9插入数据

mysql> select * from t9;
Empty set (0.00 sec)

mysql> desc t9;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| c1    | int(11) | YES  |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
1 row in set (0.01 sec)

mysql> insert into t9 values(1),(2),(3);
Query OK, 3 rows affected (0.01 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from t9;
+------+
| c1   |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.00 sec)

在从库上执行查询看数据是否已经同步过来

mysql> select * from t9;
+------+
| c1   |
+------+
|    1 |
|    2 |
|    3 |
+------+
3 rows in set (0.01 sec)

主库日志文件内容如下:

[root@localhost ~]# tail -f /msyqldata/mysql/mysql.err
tail: cannot open ‘/msyqldata/mysql/mysql.err’ for reading: No such file or directory
tail: no files remaining
[root@localhost ~]# tail -f /mysqldata/mysql/mysql.err
2024-07-04T08:46:10.847512Z 9 [Warning] IP address '10.13.13.43' could not be resolved: Temporary failure in name  resolution
2024-07-04T08:46:10.859391Z 9 [Note] Start binlog_dump to master_thread_id(9) slave_server(2), pos(binlog.000183, 326)

从库日志文件内容如下:

[root@localhost ~]# tail -f /msyqldata/mysql/mysql.err
2024-07-04T07:57:29.132449Z 0 [Note] InnoDB: Buffer pool(s) load completed at 240704 15:57:29
2024-07-04T08:03:48.366164Z 2 [Note] 'CHANGE MASTER TO FOR CHANNEL '' executed'. Previous state master_host='', master_port=  3306, master_log_file='binlog.000183', master_log_pos= 326, master_bind=''. New state master_host='10.13.13.50',  master_port= 3306, master_log_file='binlog.000183', master_log_pos= 326, master_bind=''.
2024-07-04T08:44:33.000217Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 1981125ms. The settings might not be  optimal. (flushed=0 and evicted=0, during the time.)
2024-07-04T08:46:01.839437Z 3 [Warning] Storing MySQL user name or password information in the master info repository is not  secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see  the 'START SLAVE Syntax' in the MySQL Manual for more information.
2024-07-04T08:46:01.840179Z 4 [Warning] Slave SQL for channel '': If a crash happens this configuration does not guarantee  that the relay log info will be consistent, Error_code: 0
2024-07-04T08:46:01.840283Z 4 [Note] Slave SQL thread for channel '' initialized, starting replication in log 'binlog.000183'  at position 326, relay log './localhost-relay-bin.000001' position: 4
2024-07-04T08:46:10.062847Z 3 [Note] Slave I/O thread for channel '': connected to master  'repl@10.13.13.50:3306',replication started in log 'binlog.000183' at position 326