数据库学习案例20240122-MySQL——GTID复制如何用xtrabackup恢复slave数据库

1 主备环境master-salve

   脱机方案：

   1 关闭mysql进程。

   2 cp数据目录到备份主机，在启动slave时，注意一点  1server id，和auto.cnf文件清除，很重要 

  3 启动salve 

   我们的数据库使用的是GTID复制，今天老任为了避免单点利用备份文件恢复搭建从库的时候遇到了一些问题，所以就写了这篇笔记，加深学习理解。
大家都知道，在搭建从库的时候，基本都是利用最近的一份xtrabackup备份文件，解压 apply对应的log之后会生成下图的一些相关文件。

#可以看到解压应用后的关于备份位点信息的文件如下图所示
$ ls -l xtrabackup*
-rw-r--r--. 1 mysql mysql          400 8月  11 21:25 xtrabackup_binlog_info
-rw-r--r--. 1 mysql mysql           27 8月  12 01:19 xtrabackup_binlog_pos_innodb
-rw-r-----. 1 mysql mysql          107 8月  12 01:19 xtrabackup_checkpoints
-rw-r--r--. 1 mysql mysql         1024 8月  11 21:03 xtrabackup_info
-rw-r--r--. 1 mysql mysql 143608250368 8月  12 01:19 xtrabackup_logfile
-rw-r--r--. 1 mysql mysql            1 8月  12 01:19 xtrabackup_master_key_id
-rw-r--r--. 1 mysql mysql           39 8月  12 01:19 xtrabackup_tablespaces

这里重点说我们要用到的文件，其他可以自行百度：

xtrabackup_binlog_info 这个是我们主要用到文件，会记录一些位点信息以及gtidset信息，在主库备份就用这个文件
xtrabackup_slave_info 这个文件虽然图上没有，但是这个文件如果在slave上备份并且加上了--slave-info的话，就会生成该文件，我们也将使用该文件。
简单总结来说：

在主库上做了xtrabackup备份，就用xtrabackup_binlog_info里面的文件和位点以及GTID set进行change master搭建从库

在从库上做xtrabackup备份的话，而且加上了---slave-info的话，就是用xtrabackup_slave_info文见里面的东西change master。

正文

好了上面只是简单介绍了一下背景，这里开始介绍我们恢复的流程

1.查看位点以及gtid set
$ cat xtrabackup_binlog_info
mysql-bin.001460    225454    dd3ce11f-30f4-11ea-86b2-42010a8e0014:1-1211761271

#搭建同步
#两种方法
2.1 传统方法
使用binlog+位点的方式 change master去恢复

reset master

1 如果当前数据库为master，千万不要进行reset master；

2 如果进行reset，则需要设置gtid_purged.

MASTER_AUTO_POSITION=1

MASTER_AUTO_POSITION的原理：

MySQL Server记录了所有已经执行了的事务的GTID，包括复制过来的（可以通过select @@global.gtid_executed查看）。

Slave记录了所有从Master接收过来的事务的GTID（可以通过Retrieve_gtid_set查看）。

Slave连接到Master时，会把gtid_executed中的gtid发给Master，Master会自动跳过这些事务，只将没有复制的事务发送到Slave去

SALVE端操作

2.2基于GTID复制的恢复（老任使用的方法）
#清空当前机器保留的GTID_executed和gtid_purged值

sql>set global gtid_purged='dd3ce11f-30f4-11ea-86b2-42010a8e0014:1-1211761271'; 

ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
>reset master;
#设置gtid_purged变量为xtrabackup_binlog_info文件中的值
sql>set global gtid_purged='dd3ce11f-30f4-11ea-86b2-42010a8e0014:1-1211761271'; 
#搭建复制,不需要指定位点和密码
  CHANGE MASTER TO
  MASTER_HOST='$IP',
  MASTER_USER='$DBuser,
  MASTER_PASSWORD='$PASS',
  MASTER_PORT=$Port,
  MASTER_AUTO_POSITION=1;
sql> start slave;
sql>show slave status\G；

#查看复制状态是否正常就结束了

2 如果是双主集群 MASTER-MASTER (GTID）

1 slave端 删除auto.CNF重新生成对应的UUID。

多此一举其实没有必要去手动删除，因为xtbackup新生成的目录里面是根本 没有 auto.cnf文件的

。备份过来的库就是需要你新生成UUID。

我重新同步了slave，由于要设置 gtid_purged，需要进行reset master。

如果还用原来的UUID那么切主之后新生成的事务为老UUID：1-XXXXXXX，传输到原来主库则可能显示未pugred状态。

如果之前切换过，

那么gtid_purged值有可能包含原来salve端对应的uuid：1-33执行过，而reset master导致原来的事务号从1开始 ，而purged已经包含UUID：1-33 已经purge

mysqldb1    master   uuid a                                                mysqldb2 salve  uuid b

a：1-1000                                                                            xtrabackup对应的

gtid_purged=a:1-100,b:1-200                                             gtid_purged=a:1-100,b:1-200                                      

如果修改b的uuid则通过上述的配置方案：

2 如果是双主集群 MASTER-MASTER (binglong+POS）

一、问题背景

业务数据库使用的 MySQL+keepalived 双主架构。

因某种原因，MySQL主从同步除了问题，而之前没有监控，一般操作已经无法让从同步主库了。

使用XtraBackup，可以在不影响主库工作的同时，让从库数据库恢复同步主库

二、实验环境

mysql01    192.168.1.110

mysql02    192.168.1.120

vip              192.168.1.130

 mysql安装教程

数据库root密码:MySQL@123

主从同步用户密码：repluser/Repl@123

三、下载安装XtraBackup

在mysql01和mysql02服务器

# wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

#  yum -y localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

四、数据同步操作

1. 停止主库mysql01与从库mysql02相互的数据同步

在mysql01 和mysql02 服务器上：

# mysql  -u  root  -p "MySQL@123"

> stop slave

2. 在主库mysql01上备份

#  /usr/bin/innobackupex  --defaults-file=/etc/my.cnf  --user=root  --password="MySQL@123"  --parallel=4   /opt/mysql_backup

#  /usr/bin/innobackupex  --apply-log  --user=root  --password="MySQL@123"   /opt/mysql_backup/2021-03-22_20-33-22  

注：

1. mysql_backup 如果不存在，还自动创建

2. 2021-03-22_20-33-22  执行上述备份命令产生的目录名，跟执行的日期时间有关

3. 停止从库mysql02的mysql进程，删除或者重命名mysql02数据目录

在从库mysql02服务器上：

# systemctl stop mysqld

# cp -pr   /opt/mysqldata  /opt/mysqldata_bak

# rm -rf   /opt/mysqldata/*

4. 使用主库应用mysql二进制日志还原从库数据

4.1 在mysql01服务器，拷贝主库备份目录到从库服务器一个临时目录（注意磁盘空间）

# scp  -r    /opt/mysql_backup/2021-03-22_20-33-22/    192.168.1.120:/opt/mnt/

注：192.168.1.120为从库mysql02的IP

4.2 在mysql02服务器上，执行从库数据还原操作

# chown -R  mysql:mysql    /opt/mnt/2021-03-22_20-33-2/

# /usr/bin/innobackupex  --defaults-file=/etc/my.cnf   --copy-back     /opt/mnt/2021-03-22_20-33-2/

# chown -R mysql:mysql    /opt/mysqldata/

4.3 修改mysql02从库data目录属组权限

#  chown -R mysql:mysql /opt/mysqldata

4.4 启动从库mysql02进程

# systemctl start mysqld

4.5 登录mysql02，记录master_log_file和master_log_pos值

# mysql -u root -p"MySQL@123"

> show master status\G;

4.6 在mysql02查看数据信息，记录master_log_file和master_log_pos值

#  cat /opt/mnt/2021-03-22_20-33-22/xtrabackup_binlog_info 

4.7 在mysql02从库上建立主从复制用户和授权

# mysql -u root -p"MySQL@123"

> GRANT REPLICATION SLAVE ON *.*  to  'repluser'@192.168.1.110 identified by 'Repl@123';

注：192.168.1.110为主库mysql01的IP

4.8 在mysql02上开启同步mysql01操作

# mysql -u root -p"MySQL@123"

> change master to

master_host='192.168.1.110',

master_port=3306,

master_user='repluser',

master_password='Repl@123',

master_log_file='mysqld_bin.xxx',     # 使用4.6步骤查到的数据

master_log_pos=xxx;                        # 使用4.6步骤查到的数据

> start slave;

4.9 主库同步从库操作

在mysql02服务器，在从上查看主从状态并记录

# mysql -u root -p"MySQL@123"

> show slave status\G;

注：此时的从库的pos位置信息(master_log_pos值)应该不变

在mysql01 服务器

# mysql -u root -p"MySQL@123"

> change master to

master_host='192.168.1.120',

master_port=3306,

master_user='repluser',

master_password='Repl@123',

master_log_file='mysqld_bin.xxx',      # 使用4.6步骤查到的数据

master_log_pos=xxx;                           # 使用4.5步骤查到的数据

>start slave;

五、查看主库从库的数据同步状态

在mysql01 和 mysql02 服务器

# mysql -u root -p"MySQL@123"   -e  "show slave status\G;"

Slave_IO_Running和Slave_SQL_Running均显示Yes表示数据复制正常。