TiDB用什么保证备份的一致性

TiDB用什么来保证备份的一致性？针对这个问题，本文详细介绍了相应的分析和解答，希望能帮助更多想要解决这个问题的小伙伴找到更简单易行的方法。

背景

作为一个MySQL的DBA，应该知道MySQL的备份，无论是逻辑的还是物理的，都会使用FLUSH TABLES WITH READ LOCK(以下简称FTWRL)锁来保证数据库备份的一致性。

描述FTWRL锁对一致性的影响

首先，以MySQL逻辑备份MySQLDump为例。

MySQLDump，为了保证备份的一致性，需要增加两个参数。

-单笔交易主数据=2 .

开启单事务后，MySQLDump的备份过程可能意味着将在MySQL中执行以下操作。

1.刷新表刷新表用于防止DDL操作。

2.执行FTWRL锁定。此时整个数据库被锁定，数据库处于一致状态。

3.将当前会话事务的隔离级别设置为RR。

4.记录MySQLbinlog的当前位置，或GTID信息。

5.解锁。#从锁定到解锁的执行速度会非常快，前提是没有锁冲突。如果存在锁冲突，将进入锁等待状态。

物理备份xtrabackup执行FTWRL锁定需要相对较长的时间。我们来看看xtrabackup锁定FTWRL的过程。

执行FTWRL锁定。

复制frm，MYD，MYI等副本。

等待重做的拷贝完成。

记录当前MySQLbinlog或GTID信息的位置。

解锁。

Xtrabackup锁定是为了保证如果数据库中有MyiSAM表，尽量保证MyiSAM表备份的一致性。

#之前有同学说。使用FTWRL锁的物理备份的锁定时间会比逻辑备份短，这实际上是错误的。物理备份的锁定时间完全取决于当前数据库中是否有MyiSAM表以及MyiSAM表的大小。

TiDB是用什么保证数据库一致性的

先说说TiDB官方推荐的逻辑备份mydumper。一开始我以为mydumper也用FTWRL锁来保证备份的一致性。结果今天看文件的时候，发现这个结论是错误的。

官方mydumper已经过优化和修改。先看官方描述。以下内容来自TiDB官方文档。

1.对于TiDB，可以通过设置tidb_snapshot的值来指定备份数据的时间点，从而保证备份的一致性，而不是使用FLUSH TABLES WITH READ LOCK来保证备份的一致性。

2.使用TiDB的隐藏列TiDB _ rowid可以优化单个表中数据的并发导出性能。

请记住，TiDB是由tidb_snapshot备份的，而不是由FTWRL锁备份的。这个设计有什么问题？你能保证数据备份的一致性吗？

要回答这个问题，简单说说TiDB的架构设计。

TiDB的存储节点为TiKV，以下主要为TiKV。首先，将TiKV理解为一个大的键值内存。

(图1选自TiDB官方文档)

这个备份与此无关。让我们大致了解一下TiKV存储的内容。

以下内容与备份有关。TiDB的MVCC(多版本控制器)在TiKV中实现。TiKV包括MVCC、关键和价值。

我认为那个版本是TSO(全球唯一增量时间戳)，是我通过TiDB两阶段提交发现的。

如果没有，版本的版本信息会存储在PD中，会增加PD的压力，感觉不切实际。

针对上面描述有一个小的结论TiKV里面会存储历史key的信息。

这里有一个问答来回答上面的问题。

问：TiDB是通过什么来保证数据的一致性的？

答：基于TiKV中的MVCC进行保障，根据当前时间戳信息下发命令。

sql='SETSESSIONtidb_snapshot=

'415599012634951683'"。

这个session就会读到这个时间点的历史版本的数据。

下一步的操作，只要把所有的表和里面的数据扫出来就可以了。

问：通过MVCC实现的备份，能达到一致性吗？(因为没有锁)

答：是可以的，大家可以看一下我之前写的《浅析TiDB二阶段提交》那篇文章中里面有写到，只有事务成功提交才能会写入到TiKV中，才会有TSO(全局唯一递增时间戳)。也就是TiKV中里面的key都是成功提交的。

那么在备份的过程中提交的成功的事务是不会被扫到的。

因为备份过程中提交的事务的tso(全局唯一递增时间戳)会大于当前的备份发起的tso(全局唯一递增时间戳)。

问: 使用了MVCC的备份方式，会有哪些问题?

答：我认为最大的问题就是 在备份的过程中老的key被GC(垃圾清理)掉，解决这个问题的最好的办法，可以把GC(垃圾清理)时间设置的长一点。

UPDATE mysql.tidb SET VARIABLE_VALUE = '800h' WHERE VARIABLE_NAME = 'tikv_gc_life_time';

可以设置为800h（根据时间情况而定），备份结束后要修改回来，否则会浪费存储空间。

通过上面的描述，大家应该会了解到TiDB对备份的一致性处理的相关细节。

在TiDB4.0的分布式备份恢复工具br，在这块处理是类似的。也是利用MVCC的方式来实现的。

最后在安利一下TiDB4.0的备份工具br。备份的速度快，消耗资源相对较低。下面的案例仅供参考大家感兴趣的话 我可以做一下详细的测试，留言刷起来。

机器描述：三台腾讯云4C8G SSD50G，Sysbench 压力10张表每张表1千万条数据。

整体大概5分钟左右，brlog里面会记录相关信息。

开始时间16:44:27.009 结束时间16:49:40.395

相同环境我用mydumper测，mydumper运行在tidb的节点上。

mydumper是4个线程数(默认线程数)

他备份的过程中把tidb压的OOM了。

#可以用-r参数控制每个并发处理的数据量来避免。

大概是我的机器配置低，而且mydumper和tidb-server是同一台机器。

关于TiDB用什么保证备份的一致性问题的解答就分享到这里了，希望