联机配置MySQL的GTID复制(XtraBackup)

XtraBackup介绍：

• 支持在线热备份，对主库影响小
• 物理备份，性能高

1. 准备

1.1 在主库建立复制专属用户

# 主库
create user 'repl'@'%' identified with mysql_native_password by '123456';
grant replication client,replication slave on *.* to 'repl'@'%';
flush privileges;

1.2 在主、从库安装XtraBackup

yum install https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.25-17/binary/redhat/7/x86_64/percona-xtrabackup-80-8.0.25-17.1.el7.x86_64.rpm
···
Is this ok [y/d/N]: y

https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.25-17/binary/redhat/7/x86_64/percona-xtrabackup-80-8.0.25-17.1.el7.x86_64.rpm：即安装包网址（不同MySQL数据版本对应的XtraBackup版本不同，这里是两边的版本都是8.0.25）

1.3 配置主库到从库的SSH免密码连接

ssh-keygen
···
ssh-copy-id 192.168.0.196 # 从库

1.4 停止从库的MySQL实例，以及清空其数据目录

1）停止从库的MySQL实例

mysqladmin -u root -p123456 shutdown

2）清空数据目录

rm -rf /var/lib/mysql/*

---

2. 环境检查

2.1 检查主库中是否有不支持GTID的操作

set global enforce_gtid_consistency=warn

1. 此步骤是为了保证主库中的没有不支持GTID的操作。
2. 设置完成后，建议先在正常情况下运行一段时间。如果错误日志中存在警告，根据警告调整应用程序，保证与GTID有关的警告不再生成。

2.2 在主库联机设置GTID参数

# 启用基于gtid的复制后，将设置enforce_gtid_consistency为true，保证事务不违反gtid一致性
# enforce_gtid_consistency仅在语句进行二进制日志记录时生效
set global enforce_gtid_consistency=true;
# 逐步设置gtid_mode的值，否则将报错
set global gtid_mode=off_permissive;
set global gtid_mode=on_permissive;
# global gtid_mode=on只能复制匿名事务
set global gtid_mode=on;

---

3. 备份

3.1 主库备份并传输备份文件至从库

xtrabackup -uroot -p123456 --socket=/tmp/mysql.sock --no-lock --backup
 --compress --stream=xbstream --parallel=4 --target-dir=./ 
 | ssh 192.168.0.196 "xbstream -x -C /var/lib/mysql/ --decompress"

此步骤用于连接主库，并行压缩流式备份，同时将备份通过管道操作符传输到从库，并直接压缩至从库的数据目录。

• xtrabackup 使用物理备份，主库中的数据文件和二进制日志文件都会被复制到从库
• 在从库恢复备份、启动实例复制后，可以使用gtid的自动定位功能找到初始复制点

3.2 从库根据备份文件进行数据恢复

xtrabackup --prepare --target-dir=/var/lib/mysql/  

3.3 修改从库配置文件

添加如下配置信息至/etc/my.cnf

server_id=1126
read_only=on #从库只读
gtid_mode=on #启用gtid
enforce-gtid-consistency=true #强制gtid一致

[root@slave1 ~]# vi /etc/my.cnf
[root@slave1 ~]# cat /etc/my.cnf
[mysqld]
datadir=/var/lib/mysql
socket=/tmp/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
server_id=1126
read_only=on #从库只读
gtid_mode=on #启用gtid
enforce-gtid-consistency=true #强制gtid一致
[mysqld_safe]
log-error=/usr/local/mysql/log/mariadb.log
pid-file=/usr/local/mysql/run/mariadb.pid

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
[client]
port=3306
socket=/tmp/mysql.sock

3.4 启动从库

/usr/local/mysql/bin/mysqld --user=root

3.5 启动从库复制

mysql> show slave status\G
Empty set, 1 warning (0.04 sec)

mysql> change master to
    -> master_host = '192.168.0.192',
    -> master_port=3306,
    -> master_user='repl',
    -> master_password='123456',
    -> master_auto_position=1;
Query OK, 0 rows affected, 8 warnings (0.16 sec)

mysql> start replica; # start slave;都可以，后续都会将salve改为replica
Query OK, 0 rows affected (0.01 sec)

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.0.192
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: binlog.000016
          Read_Master_Log_Pos: 196
               Relay_Log_File: slave1-relay-bin.000002
                Relay_Log_Pos: 365
        Relay_Master_Log_File: binlog.000016
             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: 196
              Relay_Log_Space: 575
              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: 1125
                  Master_UUID: 2fd11126-c350-11eb-b436-000c298903dc
             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: 2fd11126-c350-11eb-b436-000c298903dc:1
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
       Master_public_key_path:
        Get_master_public_key: 0
            Network_Namespace:
1 row in set, 1 warning (0.01 sec)

3.5 主库配置文件修改

将GTID配置参数添加到主库的配置文件/etc/my.cnf中

gtid_mode=on
enforce-gtid-consistency=true

---

4. 报错处理

4.1 Unknown redo log format (4). Please follow the instructions at http://dev.mysql.com/doc/refman/8.0/en/ upgrading-downgrading.html.

• 原因：Xtrabackup版本低，不支持备份MySQL8.0.20

MySQL修改redo log格式版本的原因是在MySQL
8.0中，由于undo表空间ID值的变化,undo表空间修改的重做日志记录的大小增加了,导致需要额外的字节存储,redo log记录大小的变化导致写I/O较多的工作负载的性能下降(官方记录是10%),为了解决这个问题，对redo log日志格式进行了修改(优化)

• 处理：下载高版本Xtrabackup

• 命令：yum install https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.25-17/binary/redhat/7/x86_64/percona-xtrabackup-80-8.0.25-17.1.el7.x86_64.rpm 因为之前是 yum isntall的该文件，所以可以直接 yum isntall更新

[root@master ~]# yum install https://downloads.percona.com/downloads/Percona-XtraBackup-LATEST/Percona-XtraBackup-8.0.25-17/binary/redhat/7/x86_64/percona-xtrabackup-80-8.0.25-17.1.el7.x86_64.rpm
Loaded plugins: fastestmirror, langpacks
percona-xtrabackup-80-8.0.25-17.1.el7.x86_64.rpm                                                                                          |  13 MB  00:00:16
Examining /var/tmp/yum-root-xZ3Jfg/percona-xtrabackup-80-8.0.25-17.1.el7.x86_64.rpm: percona-xtrabackup-80-8.0.25-17.1.el7.x86_64
Marking /var/tmp/yum-root-xZ3Jfg/percona-xtrabackup-80-8.0.25-17.1.el7.x86_64.rpm as an update to percona-xtrabackup-80-8.0.6-1.el7.x86_64
Resolving Dependencies
--> Running transaction check
---> Package percona-xtrabackup-80.x86_64 0:8.0.6-1.el7 will be updated
---> Package percona-xtrabackup-80.x86_64 0:8.0.25-17.1.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

=================================================================================================================================================================
 Package                              Arch                  Version                           Repository                                                    Size
=================================================================================================================================================================
Updating:
 percona-xtrabackup-80                x86_64                8.0.25-17.1.el7                   /percona-xtrabackup-80-8.0.25-17.1.el7.x86_64                 59 M

Transaction Summary
=================================================================================================================================================================
Upgrade  1 Package

Total size: 59 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : percona-xtrabackup-80-8.0.25-17.1.el7.x86_64                                                                                                  1/2
  Cleanup    : percona-xtrabackup-80-8.0.6-1.el7.x86_64                                                                                                      2/2
  Verifying  : percona-xtrabackup-80-8.0.25-17.1.el7.x86_64                                                                                                  1/2
  Verifying  : percona-xtrabackup-80-8.0.6-1.el7.x86_64                                                                                                      2/2

Updated:
  percona-xtrabackup-80.x86_64 0:8.0.25-17.1.el7

Complete!

4.2 Error: failed to fetch query result SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status: Access denied; you need (at least one of) the BACKUP_ADMIN privilege(s) for this operation

• 原因：主库的root用户没有 BACKUP_ADMIN 权限
• 处理：在主库对该用户进行授权

• 命令：grant BACKUP_ADMIN on *.* to 'root'@'%';

4.3 xbstream: Can’t create/write to file ‘./provider_online/serviceproject.ibd’ (OS errno 17 - File exists) xbstream: failed to create file.

• 原因：从库的数据文件夹在几次错误操作后未清空
• 处理：清空该文件夹

• 命令：rm -rf /var/lib/mysql/*

4.4 XtraBackup备份时一直卡在210630 00:16:10 >> log scanned up to (79502555)

• 原因：主库到从库未配置免密连接
• 处理：配置ssh免密连接

• 命令：ssh-copy-id 192.168.0.196

4.5 主从复制从库报错：Slave failed to initialize relay log info structure from the repository

以下是从库日志：

2021-06-30T08:05:14.925480Z 0 [ERROR] [MY-010544] [Repl] Failed to open the relay log './localhost-relay-bin.000001' (relay_log_pos 4).
2021-06-30T08:05:14.925715Z 0 [ERROR] [MY-011059] [Repl] Could not find target log file mentioned in relay log info in the index file './slave2-relay-bin.index' during relay log initialization.
2021-06-30T08:05:14.926403Z 0 [ERROR] [MY-010426] [Repl] Slave: Failed to initialize the master info structure for channel ''; its record may still be present in 'mysql.slave_master_info' table, consider deleting it.
2021-06-30T08:05:14.926577Z 0 [ERROR] [MY-010529] [Repl] Failed to create or recover replication info repositories.
2021-06-30T08:05:14.929654Z 0 [System] [MY-010931] [Server] /usr/local/mysql-8.0.25-linux-glibc2.12-x86_64/bin/mysqld: ready for connections. Version: '8.0.25'  socket: '/tmp/mysql.sock'  port: 3306  MySQL Community Server - GPL.
2021-06-30T08:07:12.581231Z 8 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL '' executed'. Previous state master_host='', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='192.168.0.192', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''.
2021-06-30T08:07:18.423400Z 8 [ERROR] [MY-013124] [Repl] Slave SQL for channel '': Slave failed to initialize relay log info structure from the repository, Error_code: MY-013124
2021-06-30T08:08:19.710940Z 8 [System] [MY-010597] [Repl] 'CHANGE MASTER TO FOR CHANNEL '' executed'. Previous state master_host='192.168.0.192', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''. New state master_host='192.168.0.192', master_port= 3306, master_log_file='', master_log_pos= 4, master_bind=''.

• 原因：从库到主库的复制链路有冲突

• 处理：删除主从复制链路

• 命令：

  mysql> reset slave;
  Query OK, 0 rows affected, 1 warning (0.01 sec)
  

slave reset执行候做了这样几件事：
1、删除slave_master_info ，slave_relay_log_info两个表中数据；
2、删除所有relay log文件，并重新创建新的relay log文件；
3、不会改变gtid_executed 或者 gtid_purged的值

---

5. 参考引用

《Xtrabackup版本低，不支持备份MySQL8.0.20，提示Unknown redo log format (4).》
《xtrabackup mysql8.0_xtrabackup-8.0.11备份mysql-8.0.21失败处理》
《Access denied； you need (at least one of) the BACKUP_ADMIN privilege(s) for this operation》