作者简介：余军，PingCAP解决方案事业部总经理。
对于金融企业来说，尤其是银行、证券、保险这些行业，在一个IT系统运行支撑业务的过程当中，考虑到硬件的故障、网络的故障，等一切可能会对业务产生影响的突发故障。那么，在过去漫长的IT发展的过程当中，大量的技术被应用在关于如何解决组件级的高可用，整个服务的容灾和灾备，包括如何保证整体业务的连续性。
在金融行业来说，数据库作为最核心的基础组件之一，要求它能够安全运行和保障数据安全，这是一个刚需。另外，数据库服务本身的高可用，是我们实现整个对外数据服务连续性的最重要的基石。在这些基础上，光有高可用还是不够的，我们需要考虑到机房级的、数据中心级的、站点级的灾难导致的对业务的影响。配套的容灾技术，以及对应事件的方案，应运而生。在过去的二、三十年里面，关于容灾和技术的技术手段、软件工具，包括各种各样的方案、管理方法，在不断的展现。
传统数据库支撑关键计算的高可用/容灾方案短板
回到传统的数据库领域，在过去至少三四十年的时间里，我们都是在使用集中式的数据库，比如大家非常熟悉的Oracle、DB2包括曾经很辉煌的Sybase、Informix等等。这些数据库都是以大家所熟知的“IOE”的架构来实现数据服务的。
在这些技术体系下，在长期的技术发展过程当中，也有产生对应的高可用和容灾的方案，比如说大家非常熟悉的OracleRAC，比如说我们在DB2上，经常会用到的HACMP，还有曾经大名鼎鼎的VeritasVCS，MC/SG，以及红帽的RHCS,Pacemaker/Corosync等实现单机数据库高可用的。
这些技术都是通过数据库，建主从的实例，然后共享数据库的数据文件，放在高端的数据的存储上。这种集中架构的话，它总体是比较稳定的，但是随着IT应用场景的不断发展，到今天为止，我们在考虑数据库的时候，除了要考虑它的可靠性之外，还需要考虑它如何应对海量的数据处理，海量的并发请求。那么我们需要必须寻求扩展，而集中式的结构，它没有办法做横向扩散。此外的话，这种传统的数据库的高可用方式，非常依赖于外部的组件，就是前面说的这些独立的厂商提供的相关的高可用和容灾组件。
进入到开源数据库的阶段，大家所熟知的MySQL和PostgreSQL，它们也会有对应的高可用的解决方案，比如MySQL它最常见的就是通过它的Binlog复制建立起来主从队，然后在数据库之外，我们采取类似像MHA这样的一个SwitchManager的工具，包括PG的话，它有PAF、RepMgr、Ptroni这样的技术。
在这样的技术场景中，其实在可用性和容灾方面，还是有很多的问题，比如说复制的时候的采用的异步复制，增强的半同步复制以及国内好多互联网公司定制的MySQL，PG的同步方案，在多节点，跨地域容灾灾备场景中的一致性的问题，始终是一个很大的挑战。特别是在容灾的场景当中，超过公里以上的站点距离间隔，用上述复制的方式，用独立的SwitchManager的故障切换机制，是不是能够保证在千公里以上的容灾的可靠性是很大一个疑问。
此外，主从复制的模式资源利用率比较低。到现在为止，我们还有在主从复制基础上，再往前走一步，提高高可用性的一些保障机制，比如说大家都熟知的组同步，像Codership之前做的Galera，像包括MariaDBGaleraCluster和PerconaXtraDBCluster，都把Galera组件放在产品当中。包括现在MySQL新版本中的复制技术实现了组同步MGR。但是这些方向又有它的问题，比如说它的性能损耗非常显著，然后在多写场景的冲突的处理复杂性，以及整个集群的扩展规模，受到这样的限制。
分布式数据库备份容灾的挑战
所以，从单机数据库进入到分布式数据库的领域，问题的挑战就更加大了。集中来看的话，就是比如说我们最常见的两个传统的分布式的数据库的架构：MySQL、PG加上主从复制核心组件，再加一个高可用的外部组件实现Failover/Switchover，然后再加分库分表中间件。那么这样的方案，在传统的分布式架构当中，它的核心的可用性的技术限制和天花板没有变化。它还是如前文所说的：主从复制加上一个数据库外部组件实现Failover/Switchover。
然后，在分布式数据库架构里，我们需要非常认真的去考虑，分布式数据库的伸缩能力和它怎么样去跟高可用及容灾的要求达到平衡。甚至还要想怎么样再去做进一步的优化，这是比较困难和有挑战的。
另外，在互联网应用场景中，访问量和数据量非常的大，业务逻辑相对简单。但是在银行、保险、证券等这样的传统关键金融场景当中，业务的逻辑是非常复杂的。针对于这样的传统高可用及灾备容灾方案，它与应用进行适配，往往要做一些面向应用的反向适配，应用还需要为此进行调整与妥协。比如说两地三中心的场景当中，应用适配的难度更加大，所以改造过程当中的适配过程和反向适配的风险，也是一个经常让金融行业的IT从业人员非常头痛的一件事情。
最严峻的一个事情，当在这样的传统灾备容灾方案为基底的一套系统在运行的过程当中，真的发生了非预期的重大故障和灾难突发的时候，怎么样保证数据的严格安全，以及如何保证在故障发生以后，对于部分组件，对于机房级的灾难，对于中心级的灾难，在灾难发生的时候，要保证对业务的最小影响，也就是我们经常听到的，RPO和RTO这样的要求。那么在这个过程当中，怎么样最大程度减少人工的干预？因为，在灾难发生的时候，人的干预是必须的，但是人的反应也是比较迟钝的。所以，怎么样通过一个技术手段，在整个方案的能力上，能够去高效执行灾难恢复的处理工作？
TiDB的金融级备份及容灾之道
TiDB经常这么多年的积累和逐渐完善，在整个分布式数据库的容灾和灾备的领域，我们达到了金融生产级的要求。那么在整个TiDB的备份与灾备、容灾的体系里，我们主要是由以下几个方面来组成的。
TiDB-金融级备份及容灾之道第一个是我们默认的，也是我们推荐的，多中心的容灾方案，同城的两中心，异地的一中心，或者扩展到三地五中心模式。这个方案也是TiDB最早原生的核心方案。通过多级标签的感知，能够实现服务器级、机架级、机房级、站点级的故障转移。能达到RPO等于0，以及我们的故障影响时间小于30秒，也就是RTO小于30秒的一个刚性指标。
这一套方案，目前我们在国内和国外，已经有了不少用户，尤其是金融行业的用户，在关键场景投产使用了。这其中也是经受过了很多的考验，比如说，同城光纤的抖动，同城到异地之间的通讯线路出现问题，以及机房里面多个节点同时出现了故障，随着在生产环境上持续运行时间的变长，这些问题都暴露出来了。通过TiDB的多中心的容灾方案，非常可靠地避免了这些故障对业务的影响，保障了业务连续性及数据安全。
除此之外，在国内的话，从北到南，我们的运营商的线路也是非常的复杂。对于有些用户来说，从投资成本、业务的重要性、客户网络的物理条件来说，没有办法去构成同城多中心加异地的的容灾架构，他可能只能选择两中心的方案，那么在这个过程当中的话，TiDB经过这几年对这个方面的积累，我们现在已经有了两中心的容灾方案，并且，在这个方案里面，我们有多种配置来适应不同的网络条件。即便是在两中心方案当中，我们也能达到RPO等于0的保护模式。当然也有一些用户的场景，他的网络线路可能延迟非常高，且用户要求有一个托底的容灾方案，同时对于数据的一致性可以有略微的放松和让步，在这个过程当中，我们也会通过配置来为其提供异步同步的模式，来帮助其实现托底的容灾方案，最大程度保障服务的连续性和数据安全。
以上是我们交付给用户的多种金融生产级的灾备容灾的方案，它背后的支撑是由核心的TiDB的MultiRaft的高可用机制，以及一系列针对跨中心的调度、数据的调度管理、故障的自动转移判断等这一整套后台的保障技术机制来实现的。
另外，对于数据业务来说，除了在线的热的故障转移、切换等。我们对于数据库的数据本身，也提供了完善的数据备份方案，除了全量的备份、增量、恢复时间点(PITR)之外，我们在数据的备份模式上面，也提供了包括基于日志的传统逻辑备份。并且，在去年我们也推出了TiDBBR工具和备份方案，直接从数据库的TiDB存储引擎TiKV层上，直接实现备份和恢复，备份与恢复非常高的效率。
但光有上述方案是不不够的，PingCAP对于自身产品的要求是非常严格的，既然是要达到金融生产级的要求，除了要有对应的技术方案、对应的技术实现之外，必须为产品本身提供专业的分布式测试的体系和手段。每一个TiDB的版本，在我们的内部，都会通过极其严格及复杂的分布式数据库测试。为此，我们也专门根据混沌工程，设计开发了自己的一套测试平台，并且在最近把它开源了，这套工具叫做ChaosMesh，可以帮助用户更好的检测分布式系统的可用性和鲁棒性。
在TiDB内部测试的整条链路上，我们有非常完善的对于可靠性和一致性和安全方面的测试保障。包括自动化故障注入，包括我们引入的Jepsen的一致性验证，包括我们对于一些最核心的算法，引入了TLA+的验证。还有我们每天在数据中心，在我们测试环境，不停跑的自动化模拟的业务负载以及各种各样的集成测试。我们相信只要是人写出来的软件，一定是会有问题的，一定会有Bug，不可能做到完全没有问题。所以，在这个过程当中，需要的保障手段，除了高可用和软件架构本身设计的机制之外，先进的、完善的、强大的产品测试体系和可靠性验证能力，也是最重要的保障手段之一。
TiDB灾备与容灾的核心机制
TiDB容灾的核心机制是我们的Raft，相信各位