学习
实践
活动
专区
工具
TVP
写文章
专栏首页「3306 Pai」社区TiDB用什么保证备份的一致性?

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锁的流程。

  1. 执行FTWRL锁。
  2. 拷贝frm、MYD、MYI、etc拷贝。
  3. 等待redo的拷贝完成。
  4. 记录当前的MySQLbinlog的位置,或者GTID信息。
  5. 解锁。

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是同一台机器,这块只是给大家提供一个参考。这块我在后续测一下吧,会有一个完整的测试例子,目前备份工具还是推荐mydumper

文章分享自微信公众号:
3306pai

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

作者:田帅萌
原始发表时间:2020-03-28
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • MySQL 怎么保证备份数据的一致性?

    为了数据安全,数据库需要定期备份,这个大家都懂,然而数据库备份的时候,最怕写操作,因为这个最容易导致数据的不一致,松哥举一个简单的例子大家来看下: 假设在数据库...

    江南一点雨
  • RocketMQ为什么要保证订阅关系的一致性?

    前段时间有个朋友向我提了一个问题,他说在搭建 RocketMQ 集群过程中遇到了关于消费订阅的问题,具体问题如下:

    张乘辉
  • ghost备份系统有什么用_win备份和ghost备份的区别

     Ghost(是General Hardware Oriented Software Transfer的缩写译为“面向通用型硬件系统传送器”)软件是美国赛门铁克...

    全栈程序员站长
  • TiDB备份恢复方式你知多少?

    学习一款数据库,要学会备份和恢复。备份是一个严谨的工作,作为一个dba,掌握数据库备份、恢复的各种手段。

    田帅萌
  • MySQL痿了,放不下这么多数据!

    MySQL在达到一定数据量(我的经验是3T、单表1亿)时,复杂查询会有明显的延迟。继续分库分表,会严重增加业务复杂性,尤其对很多非互联网产品来说,急需一个分布式...

    xjjdog
  • 如何做到 10T 集群数据安全备份、1GB/s 快速恢复?

    数据库作为基础设施,其安全性不言而明,因此数据安全备份和恢复功能是在严肃使用场景下的标配。TiDB 作为一款分布式数据库,目前可以满足超大集群的备份恢复的需求,...

    PingCAP
  • TIDB 初级课程体验 9 (备份策略与备份和恢复,BR 原理)

    数据库的备份在普通的数据库是很正常不过的,但对于分布式数据库来说,备份是比较复杂. 下面就的说说TIDB 分布式数据库的备份和恢复的问题了.

    AustinDatabases
  • TiDB 金融级备份及多中心容灾

    对于金融企业来说,尤其是银行、证券、保险这些行业,在一个 IT 系统运行支撑业务的过程当中,考虑到硬件的故障、网络的故障,等一切可能会对业务产生影响的突发故障。...

    PingCAP
  • PingCAP刘奇:如何构建一个NewSQL数据库

    大家好,我是PingCAP CEO刘奇。今天我将和大家分享一下如何构建一个NewSQL数据库。 首先,来介绍下我自己。和你们当中很多人一样,我是一名开源Hack...

    CSDN技术头条
  • tidb本周精选 2021年的第 31 周

    将数据按照 key 的范围划分成大致相等的切片(下文统称为 Region),每一个切片会有多个副本(通常是 3 个),其中一个副本是 Leader,提供读写服务...

    程序员小王
  • TiCDC 在大单表场景下的性能优化:我们如何将吞吐量提升 7 倍?

    在2023 伊始,我们很高兴向大家宣布,TiDB 6.5 LTS 版本已经发布了。这是 TiDB V6 的第二个长期支持版(上一个是 TiDB 6.1),除了携...

    PingCAP
  • The Overview of TiDB 4.0

    在上篇文章中,我司 CTO 黄东旭分享了 我们对“未来数据库”的展望,很高兴我们一直走在「写一个更好的数据库」的初心之路上。4 月 8 日是 PingCAP 成...

    PingCAP
  • TiDB 4.0: The Leading Real-Time HTAP Database is Ready for Cloud

    经过一年多的开发,TiDB 4.0 终于迎来 GA 版本,作为 TiDB「面向未来的数据库」道路上面的一个重要的里程碑,TiDB 4.0 不光在稳定性、易用性、...

    PingCAP
  • 网易互娱的数据库选型和 TiDB 应用实践

    计费组是为网易互娱产品提供统一登录和支付高效解决方案的公共支持部门,对内是互娱的各个游戏工作室,对外是国内外数百个渠道。由于业务场景的特殊性,我们为各个游戏产品...

    PingCAP
  • 【DB宝55】两地三中心部署TiDB数据库高可用环境

    参考:https://docs.pingcap.com/zh/tidb/stable/three-data-centers-in-two-cities-depl...

    小麦苗DBA宝典
  • TiDB 在实时分析应用场景下的探索

    近年来,随着数据规模越来越大,以及由此衍生出数据实时化的诉求激增,产生了一系列大数据相关的业务场景,场景复杂性高以及业务多维度是明显的两个特点,因此出现许多了实...

    PingCAP
  • 微众银行数据库架构演进及 TiDB 实践经验

    本文将介绍微众银行的数据库架构演进过程,并分享 TiDB 在微众银行实践经验和部分业务案例。

    PingCAP

扫码关注腾讯云开发者

领取腾讯云代金券