腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中，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点这儿~
