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

70次阅读
没有评论

共计 2526 个字符,预计需要花费 7 分钟才能阅读完成。

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

背景

作为一名 MySQL DBA,就应该了解 MySQL 备份无论是逻辑备份还是物理备份,都会使用 FLUSH TABLES WITH READ LOCK(下面简称 FTWRL)锁来保证数据库备份的一致性。

描述 FTWRL 锁对一致性的影响

先拿,MySQL 逻辑备份 MySQLDump 举例。

MySQLDump,为了保证备份一致性,需要添加 2 个参数      

–single-transaction  –master-data=2。

在开启 –single-transaction 后,MySQLDump 的备份流程大概就是,在 MySQL 中会执行如下操作。

1、刷新表 flush tables 用来防止 DDL 操作。

2、执行 FTWRL 锁,这个时候整个数据库整体被锁住,让数据库处于一个一致性的状态。

3、设置当前 session(回话)事务的隔离级别为 RR。

4、记录当前的 MySQLbinlog 的位置,或者 GTID 信息。

5、解锁。# 从加锁到解锁执行速度会很快,前提是没有锁冲突,如果有锁冲突,就会到锁等待的一个状态。

物理备份 xtrabackup,物理备份执行 FTWRL 锁的时间相对较长,下面来看一下 xtrabackup 对 FTWRL 锁的流程。

  执行 FTWRL 锁。

  拷贝 frm、MYD、MYI、etc 拷贝。

  等待 redo 的拷贝完成。

  记录当前的 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,理解为很大的一个 Key-value 的存储器。

(图 1 选自 TiDB 官方文档)

这块跟备份其实没有什么关系,先让大家大概了解一下 TiKV 存什么。

下面的内容就跟备份有关系了,TiDB 的 MVCC(多版本控制器)实现是在 TiKV 中。TiKV 中加了 MVCC,key 和 value 这样的。

我认为 version 就是 TSO(全局唯一递增时间戳),我是通过 TiDB 二阶段提交中发现的。

如果不是的话 version 的版本信息就会存在 PD 里面,这样设计的话会增加 PD 的压力,感觉不现实。

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

下面还是来一个问答来解答上面的疑问。

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

答:是基于 TiKV 里面的 MVCC 来保证的,根据当前的的时间戳信息,来下发命令  

sql= SET SESSION tidb_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 用什么保证备份的一致性问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注丸趣 TV 行业资讯频道了解更多相关知识。

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-07-18发表,共计2526字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)