MySQL 故障篇
一、开QC，导致性能降低，QPS，TPS降低
QC在分区表中是不起作用的。
二、Mysql连接长时间（7200和1200秒）无法释放
ipvsadmin -l -timeout 查看LVS的超时时间
Timeout (tcp tcpfin udp ): 90 120 300
net.ipv4.tcp_keepalive_time = 60 设置每隔60秒大宋一个心跳包，探测是否断开。
pt-kill杀死连接时间较长的连接
三、过度条带化导致性能问题
LVM条带化+raid5导致的 IOPS过高
四、有规律的一段时间，会产生性能低估
RAID卡巡读，一致性检查或电池充放电导致的性能下降。
五、zabbix监控2000+台主机，监控显示缓慢，每隔三四个月重新搭建，存储空间经常被占满
1.升级zabbix到最新版本，数据按月份切割。
2.升级数据库版本
3.使用tokudb引擎
4.分区表
为什么？
1.tokudb插入数据要比innodb快，数据压缩比innodb高
2.监控数据按月进行切割，为了能够truncate每个分区表，立即释放空间
3.关闭binlog 减少无关日志记录
4.参数调整，安全性参数关闭，提高性能
六、由于宕机，导致主从不一致，如何解决
1.pt工具可以修复主从不一致的问题
2.主库启动，biblog补全也可以使主库一致
3.innodb_flush_log_at_trx_commit=1 修改参数为1
4.mysql半同步（semi sync）
七、使用mysqldump方式构建主从，添加了--set-gtid-purged=off 导致主从构建失败？？
备份不会有set-gtid-purged=
八、基于binlog+gtid方式截取日志无法正常恢复，是什么原因导致。
gtid幂等性，恢复时要加上--skip-gtid参数
九、ibdata1共享表空间损坏，导致数据库无法启动，备份也失效，解决思路。
利用表空间迁移，将业务库的.ibd结尾的文件，导出，然后再新的数据库，创建表结构一样的数据库，导入表空间。
使用mysqlfrm工具可以知道元数据库的表结构
十、一条SQL语句，昨天执行很快，突然变慢是什么原因？
索引失效，统计数据不真实、
十一、在做DDL操作时，数据库hang住，什么原因？
出现了MDL元数据锁的问题
十二、http409错误，达到连接上线，是什么原因导致？
连接数上线，mysql连接数默认214个、
十三、连接数设置不生效，最多214，是什么原因
需要创建文件/etc/systemd/system/mariadb.service.d/limits.conf
来修改连接数：
vi limits.conf
[Service]
LimitNOFILE=10000
十四、数据库连接不上，可能的原因，如何排查。
网络，用户不对，端口不对，防火墙阻止，连接数上限，看错误日志。
十五、数据库升级时遇到过什么故障？
5.5版本升级到5.7，要先升级到5.6再升级到5.7
十六、安装部署数据库遇到什么故障？
版本不兼容
配置文件不对
目录没创建
权限没改
初始化不成功
非技术
一、上家公司用的什么架构？数据量多大？QPS/TPS多少？
高可用+读写分离
高可用+分布式
数据量在TB以上，
QPS 20000-50000不等
TPS 800-1500
二、在公司都干什么活？？
1.日常巡检
2.备份数据
3.配合开发，代码审计，审核，改写，设计
4.监控和优化
5.架构选型。调研，测试
6.应急处理
三、DBA需要掌握哪些知识？？
1.熟练操作各种sql语句
2.熟悉数据库中权限和用户的管理，具备一定安全知识
3.具备数据库恢复，备份技巧。
4.对数据库操作系统所在的操作系统有一定的认识和管理能，因为数据库系统是不能脱离操作系统独立运行。
四、喜欢MySQL吗，平常学习渠道有哪些？
热衷
一般会参加一些数据库大会，论坛，网上的论坛博客。
看一些技术类的书
五、最擅长的MySQL哪部分？
1.架构设计
2.优化，
3.处理一些常见的问题
4.底层原理
5.备份恢复
6.索引创建
7.分库分表
六、DBA应该具备哪些职业素养？
人品，严谨，细心。善于底层学习，善于分享，承担压力，知识面广，差异化发展。
优化类
一、公司如何监控mysql的？都监控哪些项目？
zabbix,
监控内存、事务、线程、QPS、TPS、锁、等待、参数的评估指标
二、PT工具都有哪些？
pt-osc
pt-archiver
pt-query-digest
pt-主从
pt-kill
三、索引优化的规范是什么？如何建索引？哪些情况不走索引？
建索引的原则：
1.必须要有主键，如果没有可以做为主键条件的列，创建无关列
2.经常做为where条件列， order by group by join on distinct的条件（业务：产品能力+用户行为）
3.最好使用唯一值多的作为索引，如果索引列重复值较多，可以考虑使用联合索引
4.列值长度较长的索引列。建议使用前缀索引
5.降低索引条目，一方面不要创建没用索引，不常用的索引清理，pwecona toolkit (xxxxx)
6.索引维护要避开业务繁忙期
不走索引的情况：
1.没有查询条件，或者查询条件没有建立索引
2.查询结果集是原表中的大部分数据，应该是15-25%以上
3.索引本身失效。统计数据不真实
4.查询条件使用函数在索引列上，或者对索引列进行运算，运算包括（+。-。*。/。！=）
5.隐式转换导致索引失效，这一点应重视，也是开发经常犯的错
6.<>,not in 不走索引
7.like "%-"百分号在前面的不走
四、如何定位SQL语句问题，如何进行优化？
1.show processlist;获取缓慢的SQL.
2.explain 查看执行计划，全表扫描，锁等待，索引方面
3.对SQL语句进行调优，有锁等待的调整顺序，索引不正确的修改语句，没索引的创建索引
4.测试库测试，总结结果，交给开发测试。
5.对在测试中没有问题的SQL语句，结合zabbix监控记录及对硬件CPU进行分析，硬件是否达到瓶颈需要升级
五、平时调整过什么参数？每个参数调整依据是什么？
Mylsam存储引擎内存优化：
key_buffer_size: 决定Mylsam索引缓冲区的大小，影响了Mylsam表的存取书读。
read_buffer_size 经常顺序扫描的Mylsam表，调整这个参数可以改善性能。
read_md_buffer_size 需要做排序的Mylsam表查询，增加参数的值，可改善sql性能，设置的太大会内存浪费
innodb存储引擎内存优化：
innodb_buffer_pool_size: 此参数决定了innodb存储引擎表数据和索引数量的最大缓冲大小 ，物理内存的80%
innodb_log_buffer_size:此参数决定了重做日志的缓冲大小，针对可能产生的大量更新记录的大事务，一般调整到64M
innodb_lock_wait_timeout:此参数决定了行锁等待的时间，一般调整为10秒。
连接层优化参数：
max_connections=1000: 最大连接数的优化
wait_timeout=600 :控制连接最大空闲时长参数
max_allowed_packet=32M 允许插入一天数据的大小。
双一参数优化：
innodb_flush_log_at_trx_commit=1 每次事务提交，内存中的数据立即刷写到磁盘。
sync_binlog=1:保证数据安全的机制。
刷写策略优化：
innodb_io_capacity=1000 ：刷写账页的速度
六、如何监控锁的状态？
1.查看锁等待。
show status like 'innodb_row_lock';
2.查看当前运行所有事务
select * from information_schema.innodb_trx;
3.查看等待锁和锁源
select * from sys.innodb_lock_waies;
---->block_pid
4.通过锁源的pid找到执行SQL的thread_id
select * from performance_schema.thread_id where processlist=进程号
5.通过thread_id找到具体的所言语句
select * from performance_schema.events_statements_current where thread_id=id号
select * from performance_schema.events_statements_history where thread_id=id号
七、数据库CPU爆满，排查思路？
1.通过top -Hp 详细排查线程
2.排查sys wait,us是否正常
3.show processlist;查看导致数据慢的sql语句
4.查看是不是有锁等待，索引的问题
八、你对mysql做过哪些优化
操作系统上：存储:网络：OS，
实例：参数优化
应用上：SQL语句的优化，索引、锁的优化
架构：搭建高可用、读写分离、分布式架构
架构类
一、Percona-XtraDB-Cluster高可用集群的工作原理
PXC最常使用以下4个端口号：
3306-数据库对外服务的端口号。
4444-请求SST的端口（SST是指数据库一个备份全量文件的传输。）
4567-组成员之间进行沟通的一个端口号
4568-用于传输IST（相对于SST来说的一个增量）
PXC的工作流程：
1.首先客户端先发起一个事务，该事务先在本地执行，执行完成之后就要发起对事务的提交操作了。
2.在提交之前需要将产生的复制写集广播出去，然后获取到一个全局的事务ID号，一并传送到另一个节点上面。通过合并数据之后，发现没有冲突数据，执行apply_cd和commit_cb动作，否则就需要取消此次事务的操作。
3.而当前server节点通过验证之后，执行提交操作，并返回OK，如果验证没通过，则执行回滚。
4.当然在生产中至少要有3个节点的集群环境，如果其中一个节点没有验证通过，出现了数据冲突，那么此时采取的方式就是讲出现不一致的节点踢出集群环境，而且它自己会执行shutdown命令，自动关机。
二、mycat分布式架构，如何设计的？
三、在维护公司MHA架构时主要做哪些工作？
1.定期的切换
2.故障监控处理
3.主从优化，降低延时
四、MHA高可用架构Failover(故障转移)原理
1.masterha_manager启动manager程序,读取app1.cnf文件，获取节点信息
2.调用masterha_master_monitor脚本，通过MHA用户连接各个节点探测心跳
3.每两秒探测主库心跳一次，探测到心跳，断开，一共给四次连接机会
4.四次连接不通，进入选主流程
a.生成一下属主，存储从库节点号码
b.进行判断
5.选择完新主，进入数据补偿间断
a.主库ssh能连接：将确实部分的binlog截取，存放在各个从库，进行补偿
b.ssh不能连接：计算从库的差异，互相补偿
6.主从切换，接触所有主从关系，构建新的主从关系
7.调用master_ip_failover进行vip切换，
8.调用masterha_conf_host将故障节点踢出集群（删除配置文件信息）
9.manager自杀，程序退出
10调用aend_report发送告警邮件
四、MHA重要脚本的作用
Manager工具包主要包括以下几个工具：
masterha_manger 启动MHA
masterha_check_ssh 检查MHA的SSH配置状况
masterha_check_repl 检查MySQL复制状况
masterha_master_monitor 检测master是否宕机
masterha_check_status 检测当前MHA运行状态
masterha_master_switch 控制故障转移（自动或者手动）
masterha_conf_host 添加或删除配置的server信息
Node工具包主要包括以下几个工具：
这些工具通常由MHA Manager的脚本触发，无需人为操作
save_binary_logs 保存和复制master的二进制日志
apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的
purge_relay_logs 清除中继日志（不会阻塞SQL线程）
五、MHA的搭建过程
1.搭建1主2从，独立节点、GTID
2.配置各节点互信无密码认证
3.配置所有节点软连接
4.在主库建用户
5.软件安装（perl\mananger\node）
6.状态检查
a.互信检查
b.主从状态检查
7.启动MHA
8.vip\binlogserver\sendreport
六、介绍你熟悉的高可用解决方案
搭建MHA架构 manager node
监控
自动选主
数据补偿
应用透明
故障通知
七、请介绍一下你们公司的数据库架构？
高可用架构：MHA、PXC、MGC、MGR
读写分离：ProxySQL、Maxscale、mysql-router、mycat
分布式架构：mycat/sharding-jdbc
主从复制类
一、如何为运行了两年的数据库，构建一个从库。请说明步骤，是否要停主库？
不需要停主库
1.主库开binlog,建立复制用户，给replication slave权限
2.每个节点的server_id和server_uuid不同
3.初始化从库数据
4.备份主库数据，恢复到从库
5.建立主从连接，change master to | start salve
二、简述主从复制原理？
1.线程：建立连接时和从库进行交互线程。监控binlog状态，传输binlog给从库。
2.文件：从库启动IO线程，接收到binlog文件写入到relaylog文件中，然后创建一个sql线程读取relaylog内容.
3.master_info会以文件或表的形式存储主库连接信息+binlog位置点。relaylog_info也会以文件或表的形式存储从库的位置点。
4.过程：
a.从库执行change master to ,相关信息存储到master_info, 执行start slave，启动IO和SQL线程
b.IO线程获取master_info信息，请求链接主库，主库接收请求，创建dump线程监控binlog变化，传输binlog给从库IO.
c.主库的dump线程根据IO线程提供的binlog位置点，截取部分日志传给从库IO
d.从库IO接收到dump日志，存储到relaylog中，并且将binlog为位置点更新到mastser_info中
e.SQL线程根据relaylog_info。回放最新的relaylog，并更新。一直重复以上操作。
f.relaylog用完之后会定期处理
三、如何监控主从复制，说明监控要点？
主库方面：
1.通过主库线程 show processlist;可以查看到从库线程信息
2.通过 show slave hosts;可以查看到从库的ID信息
3.重点监控 show slave status\G
a.故障监控：
b.主从延时：
四、简述遇到过的主从复制故障？如何监控、分析、规避、处理
1.连接主库: connecting
#可能原因
连接信息有误。
网络故障。
防火墙。
最大连接数上线。
# 排查方法：
[root@db01 data]# mysql -urepl -p123 -h10.0.0.51 -P 3307
# 处理方法：
mysql -S /data/3308/mysql.sock -e "stop slave;reset slave all;"
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000004',
MASTER_LOG_POS=674,
MASTER_CONNECT_RETRY=10;
start slave
2 请求日志: NO
主库日志损坏。
日志起点写错。
server_id重复
# 排查方法
show slave status \G
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 674
Last_IO_Error: xxxx
SQL 线程故障： 回放中继日志
中继日志损坏
1. 从库 停SQL线程
stop slave sql_thread ;
2. 主库发生新的操作
create database test1;
3. 从库删除relaylog
rm -rf /data/3308/data/db01-relay-bin.00000*
4. 启动SQL线程
start slave sql_thread ;
修复：
1. cat /data/3308/data/relay-log.info ----> binlog 位置点
2. 重构
stop slave ;
reset slave all;
CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;
日志回放失败（执行不了SQL）
# 1. 修改的对象不存在
# 2. 创建的对象已存在
# 3. 约束冲突
# 4. 主从配置不同
# 5. SQL_MODE不兼容
# 6. 主从版本差异
方法0：
从库逆反操作。
方法一：
stop slave;
set global sql_slave_skip_counter = 1;
#将同步指针向下移动一个，如果多次不同步，可以重复操作。
start slave;
方法二：
/etc/my.cnf
slave-skip-errors = 1032,1062,1007
常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突
但是，以上操作有时是有风险的，最安全的做法就是重新构建主从。把握一个原则,一切以主库为主.
方法三： PT工具
pt-table-checksum
pt-table-sync
方法四：从库只读
mysql> select @@read_only;
mysql> select @@super_read_only;
五、简述哪些情况会导致主从延时？如何监控，分析，规避，处理
导致主从延时：
1.主库binlog日志文件落地不及时，
2.主库没有GTID，主库并发多个事务，大事务，并发事务量大，
3.单一sql线程，只能串行relaylog。主库并发事务，只能是串行的。如果，大事务，并发量大，都会导致较高回放延时。
4.网络慢，主从配置相差大
5.6版本加入了GTID功能，在传输时就可以并行传输日志了，并且GTID模式下，可以开启多个 SQL进程。但SQL回放时只针对不同库并行串行
5.7版本即使不开GTID，会自动生成，GTID模式下，真正实现了并行回放
六、介绍你了解的主从复制模型？
1. 一主多从，一主一从
2.双主
3.级联复制 主库复制给从库，从库再复制给其他从库
4.延时从库 人为配置从库和这句库延时一段时间，用来处理逻辑卷损坏
5.过滤复制 只复制部分数据
设置白名单和黑名单，
6.半同步
七 传统主从复制是异步还是同步？会不会出现主从不一致？出现有什么好的方法解决和预防？
传统主从复制是异步，有可能出现主从不一致，使用PT工具解决。
八、延时从库的实现原理？主要解决什么问题？？如何使用延时从库？？
实现：
SQL线程延时:数据已经写入relaylog中了,SQL线程"慢点"运行
一般企业建议3-6小时,具体看公司运维人员对于故障的反应时间
主要解决逻辑损坏：
逻辑故障的恢复思路
1.及时发现主库发生了逻辑损坏
2.立即停止延时从库的SQL线程
3.挂维护页
4.截取relay进行恢复(人为模拟SQL线程工作，直到drop之前)
起点：stop sql线程时的relaylog位置点
终点：drop 之前的位置点
5.截取的日志恢复到从库
6.从库替代主库工作
九、过滤复制实现原理？你们公司过滤复制架构如何设计的？
replicate_do_db=库 白名单
replicate_ignore_db=库 黑名单
只需要在配置文件设置想要和不想要复制的库或表的黑白名单就可以实现过滤复制了。
公司一般会排除系统库不复制会设置，用来复制较为重要的业务库
十、增强半同步复制实现原理，5.6和5.7版本有什么区别？
原理：
1.主库执行新的事物，commit时，更新show master status\G,触发一个信号binlog
2.binlog 线程接收到主库的show master status\G信息，通知从库日志更新了
3.从库IO线程请求新的二进制日志事件，
4.主库会通过dump线程传送新的日志事件，给从库IO线程
5.从库IO线程接收到binlog日志，当日志写入到磁盘上的relaylog文件时，给主库ACK_receiver线程
6.ACK_receiver线程触发一个事件，告诉主库commit可以成功了。
7.如果ACK达到了我们预设值的超时时间，半同步复制会切换为原始的异步复制。
区别：
5.6版本加入了GC机制，半同步复制开始接受，使用after_commit机制，但是是在redo_commit之后今次那个等待ACK确认
如果主库redo commit间断宕机，从库又获取到了binlog,会出现从库比主库数据对的问题，导致数据不一致。
5.7版本以后，加入了after_sync机制，在binlog commit间断，等待从库ACK，不管谁宕机，都能保证最终一致性
十一、简述MySQL Group Replication（复制组）工作原理？Paxos 分布式一致性协议工作原理？
复制组：
由多个节点共同组成一个复制组，一个事务提交，必须经过组内大多数节点（N/2 + 1）协议并通过，才能提交。
分布式一致性协议：
用来解决分布式中一致性问题，分布一致性算法，最基本的功能是为了在多个进程之间对某个值达成一致。确定一个值，一旦被写入就不可改变，解决多节点写入问题。
备份恢复篇
一、在备份这块都做过什么具体工作？
1.备份策略
2.备份检查
3.恢复演练
4.故障快速恢复
5.迁移数据库
二、你们公司备份策略是什么样子的？
1.工具使用：
逻辑备份：mysqldump（MDP）
物理备份：percona Xtrabackup(PXB)
2.备份周期和方式
100G以内，每天逻辑备份全备，两份完整备份，日志每天都备。
100G以上，使用物理备份，每周全备，其他时间做增量和日志备份
3.类型
热备：数据库正常业务时备份
温备：锁表备份，只能查询不能修改
冷备：关闭业务，数据库没有变更情况下备份
三、你们公司用什么工具备份
mysqldump (MDP)
percona Xtarbackup (XBK)
mydumper
主从
延时从库
四、请介绍msyqldump核心参数，--master-data --single-transaction功能
--master-data=2
1.自动锁表（非innodb），global read lock
2.记录binlog位置
--single-transaction
对innodb表开启快照备份
三mysqldump原理
1.提取innodb数据快照，转换为SQL，存储到sql文件中
2.非innodb表，全局锁表，转换为sql，转存到sql文件
3.备份方式 create db create table insert
mysqldump的大致实现过程是：连接 -> 初始化信息 -> 刷新表（锁表）-> 记录偏移量 -> 开启事务（一致性快照）-> 记录偏移量 -> 解锁表，因为开启了一致性读，可以得到innodb的一致性，又因为解锁表了，MyISAM表一致性得不到保证，所以尽量别使用MyISAM表。
四、请介绍xtarbackup工具备份原理
1.innobackupex在启动后又，会分出一个进程，启动xtrabackup进程，然后等待XBK备份完ibd文件。
2.XBK在备份innodb相关数据时，是有两种线程的，1个是redo拷贝线程，一个是idb拷贝线程负责拷贝IBD文件。redo拷贝线程只有一个，在ibd拷贝线程之前启动，在idb线程结束后结束。XBK开始执行，先启动redo线程，从最新的checkpoint点开始顺序拷贝。然后再启动ibd数据拷贝线程，在拷贝idb过程中，innobackupex进程一致处于等待状态。（等待文件被创建）
3.XBK拷贝完成idb文件后,通知innobackupex，同时自己进入等待（redo线程任然继续拷贝）
4. innobackupex 收到XBK 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。
5. 当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 XBK（通过删文件） ，同时自己进入等待（等待另一个文件被创建）；
6. XBK收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知 innobackupex redo log 拷贝完成（通过创建文件）；
7. innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；
8. 最后 innobackupex 和 XBK进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待 XBK 子进程结束后退出。
五 增量备份
XBK 是支持增量备份的，但是只能对 InnoDB 做增量，InnoDB 每个 page 有个 LSN 号，LSN 是全局递增的，page 被更改时会记录当前的 LSN 号，page中的 LSN 越大，说明当前page越新（最近被更新）。每次备份会记录当前备份到的LSN（xtrabackup_checkpoints 文件中），增量备份就是只拷贝LSN大于上次备份的page，比上次备份小的跳过，每个 ibd 文件最终备份出来的是增量 delta 文件。
MyISAM 是没有增量的机制的，每次增量备份都是全部拷贝的。
增量备份过程和全量备份一样，只是在 ibd 文件拷贝上有不同。
六、恢复过程
如果看恢复备份集的日志，会发现和 mysqld 启动时非常相似，其实备份集的恢复就是类似 mysqld crash后，做一次 crash recover。
恢复的目的是把备份集中的数据恢复到一个一致性位点，所谓一致就是指原数据库某一时间点各引擎数据的状态，比如 MyISAM 中的数据对应的是 15:00 时间点的，InnoDB 中的数据对应的是 15:20 的，这种状态的数据就是不一致的。PXB 备份集对应的一致点，就是备份时FTWRL的时间点，恢复出来的数据，就对应原数据库FTWRL时的状态。
因为备份时 FTWRL 后，数据库是处于只读的，非 InnoDB 数据是在持有全局读锁情况下拷贝的，所以非 InnoDB 数据本身就对应 FTWRL 时间点；InnoDB 的 ibd 文件拷贝是在 FTWRL 前做的，拷贝出来的不同 ibd 文件最后更新时间点是不一样的，这种状态的 ibd 文件是不能直接用的，但是 redo log 是从备份开始一直持续拷贝的，最后的 redo 日志点是在持有 FTWRL 后取得的，所以最终通过 redo 应用后的 ibd 数据时间点也是和 FTWRL 一致的。
所以恢复过程只涉及 InnoDB 文件的恢复，非 InnoDB 数据是不动的。备份恢复完成后，就可以把数据文件拷贝到对应的目录，然后通过mysqld来启动了。
七、同时晚上23：00开始备份，23:30分结束。Mdp和xbk两个工具理论上能将数据恢复至几点？
MDP :23.00
XBK:23.30
八、XBK的增量备份时如何实现的？
基于上一次备份LSN号变化过的数据页进行备份，灾备份同时产生的新的变更，会将redo备份、
第一次增量是依赖于全备的，将来恢复也要合并到全备中，在进行统一恢复
九、Xtrabackup增量备份恢复要注意什么？
1.增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。
2.增量备份需要使用参数–incremental指定需要备份到哪个目录，使用incremental-dir指定全备目录；
3.进行数据备份时，需要使用参数–apply-log redo-only先合并全备数据目录数据，确保全备数据目录数据的一致性；
4.再将增量备份数据使用参数–incremental-dir合并到全备数据当中；
5.最后通过最后的全备数据进行恢复数据，注意，如果有多个增量备份，需要逐一合并到全备数据当中，再进行恢复。
十、Mysqldump和xtrabackup 备份如何实现基于时间点的恢复？
MDP的--master-data=2参数,自动记录了位置点信息，结合binlog恢复。
XBK的xtrabackup_binlog_info文件中记录了binlog 和GTID的信息,结合binlog恢复
