mysql数据恢复实战

最常见的数据库备份方式

中小型公司的常见备份玩法如下，不管是linux机器的数据备份

还是备份阿里云的RDS云数据库，都是这个思路，。都可以基于mysqldump远程备份

mysqldump -uroot -p -h -P ，适用于本地数据备份，也适用于远程备份阿里云的数据库。

mysql -uroot -p -h -P

1.核心思路，基于mysqldump备份时，加入-F参数，实现日志切割
每天一个binlog记录

2.crontab 每周一全量备份

3. 周一全量备份，以及日志中，获取数据截止点，也就是次日的开始。

4.截取binlog，次日数据是从，下一个GTID号码开始的。

5.找到删数据的GTID事务号，截取至前一个记录，即可截取数据恢复的区间。

全量备份

方案1：逻辑备份
基于mysqldump命令，使用-A参数，全部的库表备份 ,导出来的数据是一堆SQL语句，兼容性很强
--all-database 所有的库表
 
# -F 参数是干啥的？
# 全量备份的命令
# 日常人类日常思维，按天作为每一天的结束
# 数据备份，24h备份，每天全量备份


mysqldump -uroot -pwww.yuchaoit.cn -S /data/3306/mysql.sock -F -A  |gzip >/server/backup/mysqlbak_$(date+%F).sql.gz



方案2，直接物理备份
[root@tech-db-51 ~]#ls /linux0224/mysql_3306/

cp
tar
rsync

全量备份的参数

踩坑记录，不要携带GTID的数据导出

--set-gtid-purged=OFF

3306 GTID 

-F 备份数据且刷新binlog


--master-data=2


测试  -A  -F  --master-data=2  三个参数 和逻辑备份的关系

看看导出的SQL文件信息

另一个业务场景的基于GTID导出方式

正确逻辑备份玩法

[root@tech-db-51 ~]#mysqldump -uroot -p   --set-gtid-purged=OFF  -A -F --master-data=2  > /tmp/no-gtid-all-db-flush-log.sql
Enter password: 

写入数据，模拟增量备份，然后测试，能否，全量+增量恢复 所有的数据。

解读参数--set-gtid-purged=OFF

• 1. 机器A mysqldump 导出数据，不用该参数，导出的SQL数据，携带当前机器A的 binlog历史记录，且机器B导入该SQL的话，也不会再新记录binlog
• 2. 机器A mysqldump导出数据携带该参数，导出的只有SQL数据，且不包含GTID信息，这样，新机器B导入该SQL数据，就会重新自己记录binlog 事务记录。

两个备份，恢复场景

区分于，是否携带

GTID的历史信息

场景1：当前数据库的，备份，与恢复

老大给你一个RDS数据库

ip

port

让你去做好备份工作。

1. 全量备份

2. 给数据库开启binlog功能

3. 自主做更多的数据备份工作

给当前数据库服务器，进行数据备份，数据增量写入恢复。

# 当前机器，当前实例，进行数据，备份+恢复

1. 模拟夜里定时任务执行，进行全量数据备份，刷新binlog，记录上一次事务的截止点（用于数据恢复，截取binlog日志）
mysql> create table test_table(id int);
Query OK, 0 rows affected (0.00 sec)

mysql> 
mysql> show master status;
+----------------------+----------+--------------+------------------+------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+----------------------+----------+--------------+------------------+------------------------------------------+
| mysql-log-bin.000004 |      558 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-4 |
+----------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)



# 当前3306数据库，04日志 1-4 的事务记录

# --single-transaction，给所有数据库加锁，防止数据写入，导致备份错误
# --master-data 将binlog的信息以注释形式备份
# -R 导出mysql自定义函数
# -E 导出events事件 
# --triggers 导出所有数据表的触发器


# 创建一个目录，用于统一管理，mysql的备份数据
# 这个目录的数据，建议再用 rsync + inotify 试试同步到 备份服务器，最大化数据安全
#  备份 + 数据同步 
#  且是携带着当前事务ID的历史记录的

# 以及全量备份了，历史的binlog，没用了，次日，刷新新的binlog，记录第二天的所有新的SQL操作

# 加上------F参数

# 备份之前的记录
| mysql-log-bin.000004 |      558 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-4 |

# 备份后得记录


mkdir -p /mysql_3306_backup
mysqldump -uroot -plinux3306 -F -A --master-data=2 --single-transaction --max_allowed_packet=64M -R -E  > /mysql_3306_backup/full_db_$(date +%F).sql

# 明确日志已经刷新了



# 看一看这个全量备份SQL



2. 模拟次日刷新后的日志，数据写入，以及删除数据的操作

mysql> insert into test_table values(777),(888),(999);
Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> 
mysql> 
mysql> show master status;
+----------------------+----------+--------------+------------------+------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+----------------------+----------+--------------+------------------+------------------------------------------+
| mysql-log-bin.000009 |      479 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-5 |
+----------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)

mysql> drop database test_backup;
Query OK, 1 row affected (0.00 sec)

mysql> show master status;
+----------------------+----------+--------------+------------------+------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+----------------------+----------+--------------+------------------+------------------------------------------+
| mysql-log-bin.000009 |      657 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-6 |
+----------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)




3. 截取日志，进行数据恢复，实现全量数据的备份与恢复。


# 如何截取，要看你想恢复什么


# 思路

1. 解析二进制日志，看看都有0009日志

mysqlbinlog --base64-output=decode-rows -vv   /mysql_log/log_bin_3306/mysql-log-bin.000009  > /tmp/09.log



2. 分析完毕 09 增量日之后，确认要 全量恢复库，增量恢复数据

3. 先导入全量数据
mysql> set sql_log_bin=0;

mysql> source full_db_2022-08-10.sql;

mysql> select * from test_table;
Empty set (0.01 sec)


目前实现了基于全量备份的数据，找回了 库  test_backup; 逻辑跟上刷3333


4. 基于次日刷新的0009增量日志，恢复插入数据

基于mysqlbinlog 截取  00009日志，截取你要的事务区间

# --include-gtids 截取一个GTID事务区间



# 解密查看SQL
#pos值区间  ，写入数据的 194-479


mysqlbinlog --base64-output=decode-rows -vv --skip-gtids --include-gtids='187299d4-0e2b-11ed-8b0c-000c29463bc7:5' /mysql_log/log_bin_3306/mysql-log-bin.000009 > /tmp/decode_09.txt 




# 这是要用于恢复的SQL语句
mysqlbinlog --skip-gtids --include-gtids='187299d4-0e2b-11ed-8b0c-000c29463bc7:5' /mysql_log/log_bin_3306/mysql-log-bin.000009  > /mysql_3306_backup/restore_test_backup_db.sql



# 恢复数据的操作
mysql> set sql_log_bin=0;

mysql> source /mysql_3306_backup/restore_test_backup_db.sql;

mysql> select * from test_backup.test_table;
+------+
| id   |
+------+
|  777 |
|  888 |
|  999 |
+------+
3 rows in set (0.00 sec)

mysql> set sql_log_bin=1;
Query OK, 0 rows affected (0.00 sec)

mysql> 


# 总结
至此，完成
基于 
1. 全量备份的 库、表的恢复
2. 次日刷新的binlog，截取事务区间，恢复的 表数据

场景2：远程数据库的复制，或者重新数据导入

数据库A导出的数据库，导入到 机器B

3306实例的数据， 导入到新的 3307实例，让它继续开始binlog写入

正确远程数据导入玩法

-rw-r--r-- 1 root  root  863K Aug 10 10:34 no-gtid-all-db-flush-log.sql


3307数据库，导入进入，看是否可以使用该数据，以及binlog重新记录

# 准备一个新的 初始化数据的 3307实例

# 打开GTID 以及binlog功能，重新记录 事务日志

mysql> select * from kings.cike;
+-----------+
| name      |
+-----------+
| 钟薛高    |
| 兰陵王    |
| 孙悟空    |
+-----------+
3 rows in set (0.00 sec)

错误的场景

3306 导出的数据，携带了GTID历史记录
SET @@GLOBAL.GTID_PURGED='187299d4-0e2b-11ed-8b0c-000c29463bc7:1-2';



3307 实例的GTID 号码 
mysqld --initialize-insecure --user=mysql --basedir=/opt/mysql --datadir=/linux0224/mysql_3307



| eba785df-16c3-11ed-9d4f-000c29463bc7:1-276 |

试试 导入3306的SLQ到 3307

让你更多的见见故障的场景，多踩坑，多解决坑，好事。。

踩坑的问题在于

1. 3307实例，重新初始化，基于GTID启动后，默认有自己的GTID信息 唯一事务ID标识的 

mysql> create database 3307_db;
Query OK, 1 row affected (0.00 sec)

mysql> show master status;
+------------------+----------+--------------+------------------+----------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                      |
+------------------+----------+--------------+------------------+----------------------------------------+
| mysql-bin.000001 |      322 |              |                  | 68d3d065-185c-11ed-bcd5-000c29463bc7:1 |
+------------------+----------+--------------+------------------+----------------------------------------+
1 row in set (0.00 sec)


[root@tech-db-51 /linux0224/mysql_3307]#mysql -S /linux0224/mysql_3307/mysql.sock < /tmp/all-db-flush-log.sql 
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.


2. 此时是无法导入3306携带GTID的SQL文件


3. 你可以重置3307的 binlog，重置它的GTID事务信息

reset master; 没有它自己的GTID历史记录了，清空3307自己的GTID事务记录


4. 你就可以正确导入 3306的数据了，且携带GTID的


[root@tech-db-51 /linux0224/mysql_3307]#
[root@tech-db-51 /linux0224/mysql_3307]#
[root@tech-db-51 /linux0224/mysql_3307]#mysql -S /linux0224/mysql_3307/mysql.sock < /tmp/all-db-flush-log.sql 
[root@tech-db-51 /linux0224/mysql_3307]#


5. 此时的3307，就从3306的数据开始写入

物理备份工具

具体流程

注意区分开数据目录，以及日志目录。

什么是物理备份

查看如下物理备份方式

1. 基于逻辑备份的全量备份，导入执行，前提是数据库能正常启动

2. 直接恢复物理文件数据

• • tar对mysql数据打包压缩，做了个备份
• • 删数据
• • 解压恢复数据
• • 数据库重启还是可以继续用

但是这种方式太粗暴，有更专门的工具，通过这种直接操作数据文件的，备份，恢复方案，且对数据库做很多的校验工作。
一些主流的物理备份工具，，xtrabackup工具

看看mysql的数据是什么

[root@tech-db-51 /linux0224/mysql_3306/test_backup]#ll
total 112
-rw-r----- 1 mysql mysql    67 Aug 10 12:15 db.opt
-rw-r----- 1 mysql mysql  8556 Aug 10 12:15 test_table.frm
-rw-r----- 1 mysql mysql 98304 Aug 10 12:32 test_table.ibd


查看当前机器是什么引擎
mysql> show variables like '%storage%';
+----------------------------------+--------+
| Variable_name                    | Value  |
+----------------------------------+--------+
| default_storage_engine           | InnoDB |
| default_tmp_storage_engine       | InnoDB |
| disabled_storage_engines         |        |
| internal_tmp_disk_storage_engine | InnoDB |
+----------------------------------+--------+
4 rows in set (0.00 sec)

所以数据库引擎，就是帮你

• 1 。分析SQL语法
• 2. 执行SQL
• 3. 修改库，表数据
• 4. 提供了如事务的特性，能回滚，等，。

安装xtrabackup工具

yum install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL -y

# 下载软件且安装
wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.9/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.9-1.el7.x86_64.rpm

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



# up 深圳安卓开发
# 客户提了一个需求，能不能让二维码支持 扫码枪。
# 发呆。。
# 打开百度，搜索 "能不能让二维码支持 扫码枪。"
#  csdn 程序员客栈，
# ctrl +c  ctrl +v 
# 右键点击运行
# 好使了。。


# 就是用它的命令而已

# 搜索查看安装的这个rpm包，默认生成了哪些文件
# 看懂 2222
# 
[root@tech-db-51 /opt]#rpm -ql percona-xtrabackup-24 
/usr/bin/innobackupex
/usr/bin/xbcloud
/usr/bin/xbcloud_osenv
/usr/bin/xbcrypt
/usr/bin/xbstream
/usr/bin/xtrabackup



/usr/share/doc/percona-xtrabackup-24-2.4.9
/usr/share/doc/percona-xtrabackup-24-2.4.9/COPYING
/usr/share/man/man1/innobackupex.1.gz
/usr/share/man/man1/xbcrypt.1.gz
/usr/share/man/man1/xbstream.1.gz
/usr/share/man/man1/xtrabackup.1.gz

1.全量备份，恢复

明确，这个工具，其实就是再 备份mysql的数据文件而已

0. 给你的机器，设置基于GTID的模式运行



1. 基于命令 ，全量备份命令
# 和mysqldump很像，链接实例，备份数据

# 创建备份目录

innobackupex --user=root   --password=linux3306  -S /tmp/mysql.sock  /xtrabackup_data/ 

• 1.安装工具
• 2.基于innobackupex做好全量备份，手工备份，挪走数据。
• 3.全量恢复
• 4.其实这个操作，和cp拷贝整个目录区别不大，但是必然有诸多的优化，这个需要看该工具官网的详细介绍。

查看xtrabackup工具生成的日志文件

查看具体备份的数据信息，以及自己生成了哪些日志文件
xtrabackup_binlog_info 记录全量备份时，该实例最后的一个binlog  事务ID

xtrabackup_logfile 是该工具本身的一个二进制日志文件


[root@tech-db-51 /xtrabackup_data/2022-08-10_15-29-12]#strings xtrabackup_logfile 
xtrabkup 220810 15:29:12


xtrabackup_info  当前3306全量备份的详细信息，xtraback备份当前实例数据，一个版本信息

[root@tech-db-51 /xtrabackup_data/2022-08-10_15-29-12]#cat xtrabackup_info
uuid = 22363968-187e-11ed-8a4d-000c29463bc7
name = 
tool_name = innobackupex
tool_command = --user=root --password=... -S /tmp/mysql.sock /xtrabackup_data/
tool_version = 2.4.9
ibbackup_version = 2.4.9
server_version = 5.7.28-log
start_time = 2022-08-10 15:29:12
end_time = 2022-08-10 15:29:13
lock_time = 0
binlog_pos = filename 'mysql-log-bin.000012', position '194', GTID of the last change '187299d4-0e2b-11ed-8b0c-000c29463bc7:1-6'
innodb_from_lsn = 0
innodb_to_lsn = 950998185
partial = N
incremental = N
format = file
compact = N
compressed = N
encrypted = N


# xtrabackup备份数据，也是有连续性记录，
# xtrabackup通过lsn号，确认数据的起点，截止点
# xtrabackup备份数据，出现不一致的情况，会来查看该信息（DBA的活）

[root@tech-db-51 /xtrabackup_data/2022-08-10_15-29-12]#cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 950998185
last_lsn = 950998194
compact = 0
recover_binlog_info = 0

不要该工具自带的时间戳信息

--no-timestamp  

#自己制定备份的时间目录 
innobackupex --no-timestamp   --user=root   --password=linux3306  -S /tmp/mysql.sock  /xtrabackup_data_no_time/full_3306_db_$(date +%F)/

恢复该全量备份的数据

1. 挪走自带的数据，用mv替代rm

[root@tech-db-51 /linux0224/mysql_3306]#mv ./*  /opt/3306_db_backup/


2.尝试用xtrabackup命令恢复

恢复的思路其实，把备份的数据，原封不动，再放回mysql  datadir下


3. 基于xtraback命令的参数，对默认所有的未提交事务，确保数据一致性
# 操作备份的数据即可

innobackupex --apply-log     /xtrabackup_data_no_time/full_3306_db_2022-08-10/


4. 此时就可以直接恢复数据了
# innobackupex > rsync 数据拷贝回去

innobackupex --defaults-file=/etc/my.cnf --copy-back --rsync  /xtrabackup_data_no_time/full_3306_db_2022-08-10/

4.1 重新授权给mysql
[root@tech-db-51 /linux0224/mysql_3306]#chown -R mysql.mysql ./*


5.恢复数据之后，建议重启mysql，确保数据重新加载正常

6.修改配置文件，修改日志目录
[root@tech-db-51 /linux0224/mysql_3306]#mkdir -p /mysql_3306/logs/
[root@tech-db-51 /linux0224/mysql_3306]#
[root@tech-db-51 /linux0224/mysql_3306]#
[root@tech-db-51 /linux0224/mysql_3306]#chown -R mysql.mysql /mysql_3306/logs/


7.重启
[root@tech-db-51 /linux0224/mysql_3306]#systemctl restart mysqld

8.新得日志目录
[root@tech-db-51 /linux0224/mysql_3306]#ls /mysql_3306/logs/
3306-err.log


9.确保数据可以访问
mysql> select * from test_backup.test_table;
+------+
| id   |
+------+
|  777 |
|  888 |
|  999 |
+------+
3 rows in set (0.01 sec)

mysql> 

2.增量备份

完成演练目标

周日full + 周一inc1 + 周二inc2 + 周三 inc3 

注意命令细节即可，最后恢复时，需要先合并多个增量备份的日志，然后再统一恢复完整的数据。


# 1. 先模拟8-10 全量备份
innobackupex --no-timestamp   --user=root   --password=linux3306  -S /tmp/mysql.sock  /xtrabackup_0224/full_3306_db_$(date +%F)/

# 2.检查全量数据
[root@tech-db-51 /xtrabackup_0224]#du -sh .
93M	.
[root@tech-db-51 /xtrabackup_0224]#ll
total 4
drwxr-x--- 26 root root 4096 Aug 10 16:18 full_3306_db_2022-08-10


# 3.模拟次日的增量写入即可
mysql> show master status;
+----------------------+----------+--------------+------------------+------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+----------------------+----------+--------------+------------------+------------------------------------------+
| mysql-log-bin.000013 |      194 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-6 |
+----------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)

# 增量的数据写入
mysql> create database db_8_11;



# 4. 进行次日的增量备份，生成增量数据目录
# --incremental-basedir   以哪个目录为基础数据目录，然后进行增量备份 

#  --incremental  增量备份的数据，放到哪

innobackupex --defaults-file=/etc/my.cnf --user=root --password=linux3306 --socket=/tmp/mysql.sock --no-timestamp --incremental-basedir=/xtrabackup_0224/full_3306_db_2022-08-10  --incremental   /xtrabackup_0224/incr_1_2022-08-11 

# 5.进行 8-12的 增量备份，写入数据，模拟当天的数据增量

mysql> show master status;
+----------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                |
+----------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
| mysql-log-bin.000013 |      362 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-6,
9945ceea-1883-11ed-b2b4-000c29463bc7:1 |
+----------------------+----------+--------------+------------------+----------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> create database db_8_12;
Query OK, 1 row affected (0.00 sec)

mysql> 
mysql> show master status;
+----------------------+----------+--------------+------------------+------------------------------------------------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                  |
+----------------------+----------+--------------+------------------+------------------------------------------------------------------------------------+
| mysql-log-bin.000013 |      530 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-6,
9945ceea-1883-11ed-b2b4-000c29463bc7:1-2 |
+----------------------+----------+--------------+------------------+------------------------------------------------------------------------------------+
1 row in set (0.00 sec)


# 6.对 8-12的数据，进行增量备份

# --incremental-basedir=/xtrabackup_0224/incr_1_2022-08-11 以谁为相对进行增量
# --incremental=/xtrabackup_0224/incr_2_2022-08-12 本次增量数据写到哪


innobackupex --defaults-file=/etc/my.cnf --user=root --password=linux3306 --socket=/tmp/mysql.sock --no-timestamp --incremental-basedir=/xtrabackup_0224/incr_1_2022-08-11  --incremental /xtrabackup_0224/incr_2_2022-08-12



7.检查当前所有的备份环境
[root@tech-db-51 /xtrabackup_0224]#du -sh *
93M	full_3306_db_2022-08-10
3.6M	incr_1_2022-08-11
3.6M	incr_2_2022-08-12
[root@tech-db-51 /xtrabackup_0224]#
[root@tech-db-51 /xtrabackup_0224]#


8.模拟8-13数据写入

恢复思路

先模拟删数据，全部删除，反正有全量备份

mkdir -p /tmp/test_xtrabackup_db/

[root@tech-db-51 /xtrabackup_0224]#mv /linux0224/mysql_3306/*  /tmp/test_xtrabackup_db/



# 1. 明确了，目前可以恢复  8-10  到 8-12的数据，

# 2. 注意8-13的数据，再binlog里，找binlog在哪
[root@tech-db-51 /xtrabackup_0224]#ls /mysql_log/log_bin_3306/
all-06.txt  mysql-log-bin.000001  mysql-log-bin.000003  mysql-log-bin.000005  mysql-log-bin.000007  mysql-log-bin.000009  mysql-log-bin.000011  mysql-log-bin.000013  mysqllogOK.sql  table_delete.txt
jpress.sql  mysql-log-bin.000002  mysql-log-bin.000004  mysql-log-bin.000006  mysql-log-bin.000008  mysql-log-bin.000010  mysql-log-bin.000012  mysql-log-bin.index   recovery.sql    test4.txt
[root@tech-db-51 /xtrabackup_0224]#


# 3.开始合并增量日志

大体思路，每一个备份的数据，都要用该参数 --apply-log ，提交，回滚事务，确保数据一致性
--redo-only    只要不是最后一次合并，都要加这个参数

- 先处理8-10全量数据

innobackupex --apply-log   --redo-only  /xtrabackup_0224/full_3306_db_2022-08-10 

- 合并增量1，到全量数据

# --incremental-dir 填入增量的数据目录    写入 全量数据目录

innobackupex --apply-log   --redo-only --incremental-dir=/xtrabackup_0224/incr_1_2022-08-11  /xtrabackup_0224/full_3306_db_2022-08-10


# 合并8-12的增量数据

innobackupex --apply-log   --redo-only --incremental-dir=/xtrabackup_0224/incr_2_2022-08-12  /xtrabackup_0224/full_3306_db_2022-08-10  


# 最后对full数据 一致性校验确认，提交事务

innobackupex --apply-log /xtrabackup_0224/full_3306_db_2022-08-10 

# 基于最终的全量数据，恢复
# 预测结果，应该是有 db_8_11  db_8_12 


innobackupex --copy-back /xtrabackup_0224/full_3306_db_2022-08-10  

[root@tech-db-51 /linux0224/mysql_3306]#chown -R mysql.mysql ./*



# 此时还差一个 8-13的增量写入， 目前是 8-10 8-11 8-12 数据全部恢复了

# 基于mysqlbinlog  基于GTID的号码，恢复数据  db_8-13

mysqlbinlog --skip-gtids --include-gtids='9945ceea-1883-11ed-b2b4-000c29463bc7:3'      /mysql_log/log_bin_3306/mysql-log-bin.000013  > /tmp/db_8_13.sql

# 恢复该导出的SQL文件

mysql> set sql_log_bin=0;
mysql> source /tmp/db_8_13.sql;
mysql> set sql_log_bin=1;
Query OK, 0 rows affected (0.00 sec)



# 确认后续的日志，会继续记录
mysql> insert into  db_8_13.table_13 values(6666);
Query OK, 1 row affected (0.00 sec)

mysql> show master status;
+----------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------------------------------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                                                                                                            |
+----------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------------------------------------------+
| mysql-log-bin.000014 |      667 |              |                  | 187299d4-0e2b-11ed-8b0c-000c29463bc7:1-6,
7929ae4c-188a-11ed-ba6b-000c29463bc7:1-2,
9945ceea-1883-11ed-b2b4-000c29463bc7:1-3 |
+----------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

​​​​​​​