专栏首页腾讯云数据库(TencentDB)腾讯云上数十万实例的备份方法大揭秘。

腾讯云上数十万实例的备份方法大揭秘。

腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中,5月23日杨杰的分享已经结束,没来得及参与的小伙伴不用担心,以下就是直播的视频和文字回顾。

关注“腾讯云数据库”公众号,回复“0523杨杰 ”,即可下载直播分享PPT。

我是来自CDB/CynosDB的架构师杨杰,主要负责CDB/CynosDB研发相关的工作。

今天分享的主题是CDB备份系统九鼎是如何支撑数十万节点的备份。主要分为几个部分。第一个部分是在海量场景下面,数据备份遇到的一个新的挑战。面对这个挑战,我们九鼎是怎么设计和应对的。第二部分是提升备份效率,完善资源隔离方面的实践。因为资源都是混用的,在资源隔离和备份效率之间,我们是怎么权衡的。第三部分是腾讯自研的无锁备份原理介绍。

Part1 数据备份的挑战

数据是一个企业最重要的资产,数据一旦丢失就会导致企业无法正常运作。因此,企业对数据进行保护和备份是非常必要的。在发生问题的时候可以尽快去恢复,确保企业可以正常工作。云内的实例至少都是主备热备,备份在备机上完成。在比较极端的场景,例如主备双挂了,或者磁盘异常,因为可控性高,云内是比较容易做一些数据恢复的。而针对跨云、云下的实例,例如很多云下自建的MySQL用户,在虚拟机上搭建MySQL,以及实例部署在其他云厂商的用户。

从数据安全考虑,鸡蛋不能放在一个篮子,避免因为非预期的大面积故障而引起服务不可用。部分用户因此会有一些顾虑,要求备份需要跨云的能力。

从备份效率考虑,自建的MySQL备份,使用传统的备份工具是会加锁的。在8.0之前,备份加锁的粒度比较大,为了保证数据一致性,需要加全局读锁。8.0之后,可以使用Backup lock和Binlog lock,在一定程度上可以降低备份时锁的影响。基于备份不能对用户实例加锁造成影响,腾讯云CDB也做了无锁备份的实践。

从人力成本,如果一个公司自己有专职的人员去做数据库备份的话,成本非常高。数据需要恢复时,还会经过一些比较繁琐的操作,没有办法保证实效性。

第四点是从增加规模的角度上来说,我们期望通过虚拟机自建的MySQL用户,即使不把数据库托管到云,依然能够享受到云上已有的能力。协助用户能方便地去做跨云的数据备份和实时的数据恢复服务。

在这样的背景下,九鼎备份系统应运而生。为跨云、云外的用户提供可靠的、连续的,低成本的备份服务,以及精确到秒级的实时数据恢复能力。

讲完背景以后,我们分析下跨云和云内备份之间业务的特点是什么。云内的CDB实例数在10+万,而且以肉眼可见的速度在快速增加。实例的数据量也特别大,每天产生10+T以上的备份数据。在单机存储量上,云上售卖最大是6T,并且对备份会有时效性的要求,需要在业务低峰的维护时间内完成备份。跨云和自建MySQL特点是不确定性。我们知道在云内的CDB实例都是有主备的,备份是在备机上面进行的,即使备份加锁,影响也比较有限,不会影响正常的主机访问。但是在跨云和自建MYSQL备份上面,这点是无法保证的。因为在云上面的实例,通常只会提供一个读写的虚拟IP,是绑定在主机上面的。自建的MySQL可能就是一个单点,连备机都没有。如果我们再按照传统的方式备份的话,那备份就可能会影响正常业务的读写了。除了备份以外,数据恢复也面临权限不足的问题。比如说从全量备份中,只要恢复个别的库表,过滤库表就不能再采用原生的MySQL复制了,因为缺少了super权限可以建立复制通道。

总结一下,在海量场景下面数据备份面临两方面的新挑战:一方面是云内规模大,对备份时间和资源有限制,所以云内矛盾是如何高效利用资源。另一方面是跨云场景可控性弱,缺少高级权限,要求备份和恢复不能影响正常读写。

Part2 九鼎的架构设计

九鼎的架构设计是分为三层的。最上层是Scheduler,负责全局任务的分发和资源限制。例如全局带宽限制、单节点任务控制、优先级队列等。Scheduler有多个节点,leader节点承载读写请求,follow节点承载一部分的读请求。Scheduler多节点高可用,当节点切换时,有服务发现模块进行通知,可以快速做故障转移和服务升级。中间层是执行层,实施具体的备份操作。执行层定义了不同的备份工具接口到存储层,适配不同的备份工具集变的更加轻松。工具集除了常规的数据备份工具外,还有增量Binlog备份工具,通过复制协议实时的把Binlog拉取过来做备份。最底层是存储层,作为一个中心化的、多副本的存储集群,支持多种不同的存储系统。例如对象存储COS、分布式文件系统CFS和HDFS。除了高可用和备份工具的兼容外,不得不说的九鼎架构特点还有调度模型和资源隔离。调度有三种模型,本地模型是执行层和MySQL实例同机部署的,适合云内的备份。比如物理备份,本地备份后做流式压缩上传到存储层,节省资源。中转机模型是执行层独立部署,主要应对临时储存的、对性能有更高要求的场景。比如备份最新的Binlog。混合模型是执行层独立部署,并且会相应的触发一些操作,完成后再上传存储层。比如物理备份先完成apply log之后再存储,这样在数据恢复的时候就能够更快。备份是比较耗费资源的操作,资源隔离可以避免在备份期间对CDB实例造成资源争抢。因为资源隔离非常重要,因此隔离是分多个层级的,重重保护的。调度层是采用了全局的带宽控制算法,目的是控制整个Region的带宽可以AZ就近接入,并且尽量跑满全局带宽。解决全局带宽资源有限的瓶颈。执行层采用了软硬结合的方式。软件层面有令牌桶,控制每个任务的带宽资源。硬限制作为一个保底的手段,限制单机的CPU/MEM/IOPS/带宽上限。软硬隔离的方式,可以更大程度的避免资源超用的风险。

Part3 无锁备份

在讲无锁备份之前,我们先回顾下常规的逻辑备份是怎么进行的。方式一,是在整个备份的过程中,先通过全局读锁将MySQL锁住,避免备份期间的数据更新。方法简单粗暴,但弊端也很大,整个备份期间数据是不能写入的。方式二,在InnoDB事务表上做了区分。只有在备份非InnoDB表的时候需要加全局读锁,在备份InnoDB表的时候不加锁。利用InnoDB的MVCC机制,弊端是备份期间有DDL,可能会破坏事务一致性,得到的备份数据可能是不一致的。这一点需要工具使用方保证,但在云上是很难保证的。无锁备份包含了两个工具,一个用以备份,一个用以恢复。备份原理是先记录全量的Binlog,再按照表的粒度分别进行不加锁的逻辑备份。恢复原理是重新回放Binlog。那么会遇到两个问题,单表数据一致性和整实例数据一致性问题。

单表数据一致性的问题,是在备份阶段解决的。T2时刻获取Binlog位点,T4时刻加表级意向锁,阻塞DDL操作。T2-T4时刻是不允许有DDL的,通过并行解析Binlog日志,确保在这段时间没有不允许的DDL出现。不允许的DDL包括了改变表字段顺序、列数的操作。如果T2-T4时刻备份的表有不允许的DDL操作,那么该表就进行重新备份,确保备份完成后单表的数据是一致的。

整实例数据一致性的问题,是在恢复阶段解决的。T2时刻之前的Binlog,是不需要重放的,因为可以明确T2之前提交的数据一定在全量备份中了。T2-T4时刻提交的数据,需要进行SQL的改写,原则是保证以Binlog的数据为准。T4时刻以后提交的数据,就不需要改写了,可以直接重放,可以避免重写SQL带来的性能损失。每个表的恢复都是相同的,直到最后一个表恢复完,此时整实例的数据就是最终一致的。

SQL重写规则如上,目的是保证最终数据以Binlog为准。可能出现一种场景,是一条记录在备份前的Binlog记录了,又在全量备份中存在。那么重放该条SQL的时候就会报错。

Part4 Q&A

Q:无锁备份的时候,我们语法解析的模块是百分之百兼容MYSQL的语法吗?

A:100%兼容。语法解析是目前是基于MySQL内核做的,虽然兼容性好,但也牺牲了易用性。考虑到易用性,以及解析的语句比较简单,后续语法解析会集成到工具内。

Q:我们腾讯云相关的备份工具跟原生开源的相比有没有性能优势呢?就是在备份导入,备份的速度上面。

A:性能没有优势,反而因为解析Binlog和SQL重写,性能反而会有下降。但无锁备份的关键并不是提速,而是尽量做到无锁。如果要提升速度的话,建议还是采用物理备份,直接拷贝数据文件,速度非常快。另外云上的CynosDB,备份可以采用快照的方式,速度会提升几个量级。

Q:数据校验的时候,如果增量的数据变化过快,会出现数据对不齐的情况,需要怎么解决?

A:数据校验指的是备份数据的校验,不是主从复制的校验。备份数据是静态的,所以不存在数据变化过快的问题。主从复制的数据校验,一般采用pt-table-checksum的方式,通过分批加锁计算多行的CRC值,并以Binlog方式传输到从机,一次只对比若干行。如果主从的CRC值相同,那么就说明在那一时刻,主从的那些行数据是完全相同的。所以数据对比可能对主从复制有影响,反而造成延迟加大,一般这种情况需要控制对比频率,等延迟缩小后再进行。

Q:云上的数据库使用强隔离的技术限制CPU和内存,那备份的带宽有限制吗?怎么保证备份的带宽不会影响实例的备份呢?

A:资源隔离问题前面也提到了。归结起来有三个点:第一点是全局带宽控制,目的是控制整个区备份的带宽,防止带宽超限后端存储访问拒绝的情况。第二点是单机单个任务的控制。目的是避免使用单机资源太多而影响实例的正常实例。单任务上也做了一些优化,用以减少内存和IO占用。例如多线程流式压缩上传、网络发包减少内存拷贝。第三点是资源的强隔离,避免软件层面有Bug导致资源没有控制住。

以上是今天的分享和Q&A的解答,感谢大家的聆听。

手机运维小程序限时免费体验!

手机运维小程序——腾讯云数据库上线啦,从此在手机里可以实现实例信息查看,健康报告接收,慢SQL分析和异常查看等功能,以后回家终于可以不背电脑了!

↓↓一年19.9特惠Cynos点这儿~

本文分享自微信公众号 - 腾讯云数据库(TencentDB),作者:腾讯云数据库

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-09-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 图文:TBASE分布式数据库的自动全量备份配置(备份至HDFS分布式存储中)

    TBase 是一款高扩展性、SQL 兼容度高(兼容绝大多数 PostgreSQL 语法以及大部分 Oracle 语法)、提供事务一致性功能支持、具备多级容灾能...

    腾讯云数据库 TencentDB
  • TDSQL分布式数据库的HDFS和LOCAL备份配置

    产品介绍:TDSQL分布式数据库是腾讯公司结合自身支付、金融等核心业务需求,紧紧抓住了国外传统集中式数据库难以适应业务规模快速增长这一现实问题,从2009年开始...

    腾讯云数据库 TencentDB
  • 深度解析腾讯自研数据库CynosDB备份与回档

    点击上方蓝字每天学习数据库 作者介绍:林锦,腾讯云数据库团队高级工程师,曾任云计算初创公司系统架构师,从事分布式系统研发7年,2017年加入腾讯云,从事New...

    腾讯云数据库 TencentDB
  • 利用宝塔面板计划任务定期备份自己的网站和数据库

    网站安全,数据安全永远是永恒的话题,再怎么强调都不为过,但是很多初次接触到网站建站服务器运维的人来说,完全不重视数据的安全,一般都是要有一次刻骨铭心的教训之后,...

    wordpress建站吧
  • MySQL/MariaDB数据库备份与恢复

    前言 数据库一般存放着企业最为重要的数据,它关系到企业业务能否正常运转,数据库服务器总会遇到一 些不可抗拒因素,导致数据丢失或损坏,而数据库备份可以帮助我们...

    小小科
  • Rman备份恢复和管理

    物理备份用于实现数据库的完整恢复,但数据库必须运行在归挡模式下(业务数据库在非归挡模式下运行),且需要极大的外部存储设备,例如磁带库,具体包括冷备份和热备份。冷...

    职场亮哥
  • 世界备份日:你是否会备份自己的文件?

    备份是使用智能设备时一个需要重视的环节,很多人无论在使用PC设备还是移动终端时,都会忽略对重要资料的备份工作,一旦出现问题往往追悔莫及。虽然时下 流行的视频网站...

    安恒信息
  • MySQL企业版备份工具MEB

    ”工欲善其事,必先利其器“。数据备份是DBA的日常工作,也是保证数据安全的重要工作,要尽善尽美的完成这项工作,必须要使用一款高效可靠的备份工具。MySQL在其企...

    MySQLSE
  • 学会用各种姿势备份MySQL数据库

    前言 我们试着想一想, 在生产环境中什么最重要?如果我们服务器的硬件坏了可以维修或者换新, 软件问题可以修复或重新安装, 但是如果数据没了呢?这可能是最恐怖的事...

    小小科
  • 灾难发生时云备份至关重要

    2017年9月和10月对许多人来说可能记忆深刻。哈维飓风在9月袭击了美国德克萨斯州,几个星期后,伊尔玛飓风对佛罗里达州造成了严重破坏,随后在墨西哥和危地马拉发生...

    静一

扫码关注云+社区

领取腾讯云代金券