背??景作为MySQLDBA，你应该明白，MySQL备份，无论是逻辑备份还是物理备份，都会使用FLUSHTABLESWITHREADLOCK（以下简称FTWRL）锁来保证数据库备份的一致性。描述FTWRL锁对一致性的影响，以MySQL逻辑备份MySQLDump为例。MySQLDump，为了保证备份的一致性，需要添加2个参数--single-transaction--master-data=2。启用--single-transaction后，MySQLDump的备份过程在MySQL中大致是以下操作。1.Flushtables用于防止DDL操作。2.执行FTWRL锁。此时整个数据库都被锁定，使数据库处于一致状态。3、设置当前会话（返回）事务的隔离级别为RR。4.记录当前MySQLbinlog位置或GTID信息。5.解锁。#从上锁到解锁的执行速度会很快，前提是没有锁冲突，如果有锁冲突，就会进入锁等待状态。xtrabackup的物理备份需要比较长的时间来执行FTWRL锁。我们来看看xtrabackup的FTWRL锁的过程。执行FTWRL锁定。复制frm、MYD、MYI等副本。等待重做复制完成。记录当前MySQL的binlog位置，或者GTID信息。开锁。xtrabackup锁是保证如果数据库中有MyiSAM表，尽量保证MyiSAM表的备份一致性。#之前有同学说过。物理备份加FTWRL锁的时间会比逻辑备份短。这个结论其实是错误的。锁定物理备份的时间完全取决于当前数据库中是否有MyiSAM表以及MyiSAM表的大小。TiDB用什么来保证数据库的一致性？先说一下TiDB推荐的逻辑备份mydumper。一开始以为mydumper也是用了FTWRL锁来保证备份的一致性。结果今天看文档的时候，发现这个结论是错误的。官方优化修改mydumper。先看看官方说明。以下内容来自TiDB官方文档。1、对于TiDB，可以设置tidb_snapshot的值来指定备份数据的时间点，从而保证备份的一致性，而不是通过FLUSHTABLESWITHREADLOCK来保证备份的一致性。2、利用TiDB的隐藏列_tidb_rowid优化单表数据的并发导出性能。请记住，TiDB使用tidb_snapshot来实现备份，而不是FTWRL锁。这个设计有什么问题？你能保证数据备份的一致性吗？要回答这个问题，先简单说一下TiDB的架构设计。TiDB的存储节点是TiKV，下面主要针对TiKV。首先将TiKV理解为一个大型的Key-value存储。（图1摘自TiDB官方文档）这个和备份无关。首先让大家对TiKV存储的内容有一个大概的了解。以下内容与备份有关。TiDB的MVCC（多版本控制器）是在TiKV中实现的。MVCC，key和value被添加到TiKV中。我认为version是TSO（globaluniqueincrementaltimestamp），这是我通过TiDB的两阶段提交找到的。如果不是，则该版本的版本信息将存储在PD中。这样的设计会增加PD的压力，感觉不太现实。根据上面的描述，有一个小的结论，TiKV会存储历史密钥信息。这里有一个问答来回答上面的问题。Q：TiDB用什么来保证数据的一致性？Answer：是基于TiKV中的MVCC来保证的。根据当前时间戳信息，下发命令sql="SETSESSIONtidb_snapshot='415599012634951683'"。该会话将读取该时间点数据的历史版本。下一步，只需扫描出所有表和其中的数据即可。Q：通过MVCC实现的备份能否实现一致性？（因为没有锁）答：可以，你可以看我之前写的文章《浅析TiDB二阶段提交》。TiKV里面写的只有事务提交成功，然后才会有一个TSO（globallyuniqueIncrementtimestamp）。即TiKV中的key都提交成功了。那么在备份过程中提交成功的交易将不会被扫描。因为备份过程中提交的事务的tso（globallyuniqueincrementaltimestamp）会大于本次备份发起的tso（globallyuniqueincrementaltimestamp）。Q：使用MVCC备份方式有什么问题？A：我觉得最大的问题是旧密钥在备份过程中被GC（garbagecleanedup）。解决这个问题最好的办法就是把GC（GarbageCleaning）时间设置的长一点。UPDATEmysql.tidbSETVARIABLE_VALUE='800h'WHEREVARIABLE_NAME='tikv_gc_life_time';可以设置为800h（根据时间情况），备份完成后要修改，否则会浪费存储空间。通过上面的描述，你应该了解了TiDB对备份的一致性处理的细节。在TiDB4.0的分布式备份恢复工具br中，这方面的处理类似。也是使用MVCC实现的。最后安利一下TiDB4.0的备份工具br。备份速度快，资源消耗相对较低。以下案例仅供参考。如果你有兴趣，我可以做一个详细的测试并留言。机器描述：三块腾讯云4C8GSSD50G，sysbench压10张表每张表1000万数据。整体时间5分钟左右，相关信息会记录在brlog中。开始时间16:44:27.009结束时间16:49:40.395我在同一环境下使用mydumper测试，mydumper运行在tidb节点上。mydumper是4个线程（默认线程数）。备份过程中，TiDB被压缩到OOM。#可以使用-r参数控制并发处理的数据量来避免。可能是我机器配置低，mydumper和tidb-server是同一台机器，仅供参考。后面会测试这部分，会有完整的测试例子，还是推荐mydumper作为备份工具。
