搭建阿里云 TiDB 的灾备体验

云原生数据库TiDB 上***了，依托的平台是***计算巢，***计算巢是一个服务管理平台，一方面方便第三方开发商交付服务，另一方面可以更充分的保障用户的信息安全和使用体验，两周前我申请到了试用，对于这次试用活动，PingCAP的诚意十足，最基础的集群配置也要几百块一天。

初始状态下包含了如下资源：

ControlServer 控制服务器、除了tiup外还部署了Grafana和Promethues服务、一台2C4GiB的ECS。

控制服务器EIP、为控制服务器提供公网IP地址。

SLB负载均衡、规格为slb.s3.small 。

TiDB 服务器 、两台4C8GiB的ECS。

PD 服务器、三台2C4GiB的ECS。

TiKV 服务器、三台8C64GiB的ECS，是本地盘类型的实例，挂了一个1.8TB的NVME *** 本地盘，这样能够提供更强的磁盘IO能力。

TiFlash节点初始环境并没有提供，要通过计算巢的扩容方式生成。

在确定了包括登录密码等配置参数后，集群开始部署。

参数配置和基础使用可以参考***计算巢服务的TiDB用户指南：

[https://help.aliyun.com/document_detail/433034.html]

在按照上述文档的指引登录ControlServer以后，首先确认了一下联网带宽：

大概5Mbps，这个带宽用来做管理肯定是够了，传输大量数据的话肯定不成。正常情况下云上的ECS要访问TiDB数据库要通过SLB负载均衡，这个负载的最大连接数可以达到20万，以这个性能绝大多数场景下都是足够的。

因为涉及到一些VPC之间的安全隔离问题，用户VPC下的服务器要访问计算巢中的资源需要经过privatelink服务，在计算巢中的叫法是虚拟互联网。

为了更好的配合测试，我在华北二开通了一台测试服务器和一个云桌面，并在华北三地域开通了一台服务器用以测试跨地域连接。云桌面的好处是可以与数据库集群保持7X24的稳定本地连接，执行一些压测、备份、恢复等长耗时操作的时候不用耽心网络中断。所有的云桌面、用户侧ECS均通过SLB访问数据库集群。

测试环境的拓扑：

TiFlash节点需要通过计算巢控制台的运维菜单下的弹性扩缩容实现，除了弹性扩缩容之外，通过运维功能还可以修改控制服务器的安全组，从而实现直接通过SSH客户端登录。

在完成扩容TiFlash节点后，终于获得了完全体的TiDB集群。

利用tiup自带的bench工具简单测试了一下，自带的bench工具可以测试OLTP或者HTAP的性能。

以上数据未经优化，仅供参考，另外我本次的测试重点主要是备份容灾架构方面的内容，因为数据库不同于一般应用，承载着的都是用户的身家性命，不容有失，备份和容灾的架构不解决，晚上会睡不着觉的。

先从最简单的本地备份开始，tidb的备份工具是br，可以从tidb的官网下载社区工具包获得，也可以通过tiup直接下载，但我用下来觉得tiup的下载下来的br有些问题，具体什么问题我会在后面提到，所以建议单独下载社区工具包。

我所使用的br版本（6.5）是不支持***OSS的，所以要实现本地备份也不是那么容易，需要找一块足够大、足够可靠的临时存储空间，找来找去，我盯上了TiFlash节点，基本上TiFlash的空间使用是处于比较受控的状态的，因为具体哪张表要放在TiFlash上需要手工指定，而计算巢环境下的TiFlash给的空间配置和TiFlash是完全一样的1.8TB ***本地盘，本地盘的优势是速度快，缺陷是缺乏高可用保护，需要额外想办法，比较极端的做法就是直接搞一个分布式文件系统上去，我觉得对于一个备份来说有些过于夸张了，我决定还是用多个TiFlash节点做NFS进行轮转使用，并在备份完成后立即上传***OSS。

考虑到一周7天，这样需要7个TiFlash节点，然后日志的备份再需要一个额外的Tlash节点，我就通过计算巢的控制台扩容出了8个TiFlash节点出来，将这8个节点做成NAS并mount到控制节点、TiKV、TiFlash节点。

其中nfs21 我用来进行日志备份，nfs244、nfs245、nfs246、nfs17、nfs18、nfs18 分别用来备份从周一到周日的全备份。

先把日志备份搞定，日志备份使用tiup br log start 然后指定一个存储位置和PD节点就可以创建成功，可以用tiup br status查询状态。

日志备份的主要问题不在于备份的创建，而在于备份日志的及时清理，假如不进行清理，很快就会把1.8TB的空间撑爆。而我在测试过程中发现tiup所带的br在清理日志的时候有些问题，一直不能成功的完成清理，而社区工具包中的独立br工具则没有这个问题。

写一个日志清理脚本，每天执行一次。这里可以根据数据的变化情况选择保留当天的日志、或者6天前的日志，我目前的策略是选择保留两天的日志，这样可以在第二天还能恢复前一天任意时间点的数据。

使用社区工具包中的br工具终于可以成功清理日志了。

然后，我们需要从周一到周日每天执行一个全备份，每一个全备份对应不同的NAS共享。这是周一的脚本，对应的NAS共享是nfs244。

这里还用到了***OSS的命令行工具ossutil，可以从***OSS的产品页面下载，下载后要进行配置，将OSS AK，endpoint等相关信息进行存储，这样就不需要每次输入了。在设置的时候务必注意使用OSS的内网endpoint，这样既不需要额外支付流量费用也能充分保证备份和恢复速度。

假如对数据的安全性比较看重，可以在创建OSS bucket的时候选择多可用区的同城冗余存储，这样就不怕单个可用区发生故障时无法访问备份数据。

在权限控制上，我使用了OSS的bucket 授权策略，只对单个bucket进行完全授权，这样这个子用户就只能访问这个备份用的bucket而不能访问其他bucket。

日志的同步同样需要写一个脚本：

这里用到了ossutil的同步功能，每次只同步变化的数据到OSS，同时删除在本地已经删除的日志，这样可以防止OSS上的日志数据无限扩张。

我完整的crontab 配置是这样的

从周一到周日每天执行一个全备份，然后把全备份传输到OSS，每天清理一次日志备份，只保留两天的日志备份，每15分钟同步一次日志备份到OSS。

在这个配置下即便当天的全备份无法使用，也可以依靠昨天的全备份和日志进行还原，假如日志备份所在的节点发生故障也能从OSS下载到最近的日志。

其实，假如br能够支持OSS，以上这些操作全都不必要，直接在备份的时候指定OSS的URI就可以。

本来到这一步就是数据恢复的测试了，但我还想增加一点儿难度，利用OSS的跨地域复制功能将备份数据复制到异地，然后在异地做恢复测试，这样就直接能获得一套异地灾备架构。

第一步，在灾备地域创建OSS bucket，这里选择华北三。

在生产中心地域（华北二）配置跨区域复制。

复制的速度非常快。

在灾备中心购买所需的ECS，配置拓扑文件。测试的过程中我用到了4台服务器，其中3台tikv，一台pd/tidb，实际业务环境建议增加更多的pd/tidb节点。

使用tiup部署非常简单快捷，这非常有利于灾备环境的快速创建和拉起

为灾备中心的oss bucket授权，同样只给一个bucket的权限。

ossutil 配置，注意这里要使用灾备地域的oss内网endpoint

同步备份数据，为了加速恢复速度，这里我就不搭NAS了，因此需要在每一个tikv节点上都保存一份备份数据，这里依然使用了sync命令，因为每隔15分钟都会有一份新数据，而在日志备份的数据量较大的情况下15分钟内可能无法完成复制，连续执行两次sync就以最快速度获得最新的数据。

在其中一台tikv节点上执行恢复，毕竟tikv节点的配置较高，恢复的速度能更快一些。

首先是全备份的恢复，这一部分的速度比较快，然后是日志恢复，速度相对慢一些，期间还报了一个告警，看起来像是PD相关的，可能是我的PD节点的配置太低吧。另外总的恢复时长要两个小时以上了，这相当于RTO。

为了能对这套架构的RPO有个更直观的感知，我启动一个数据库压测，利用命令行向数据库插入一千万行数据，命令行插入的效率比较低，这一千万行要插入好久，到时候我就可以通过对比生产站点和灾备站点之间的数据行数来感知RPO了。

在恢复之前生产站点的数据行数，可以看到数据在不断增加。

在恢复之后灾备站点的数据行数。

引起数据延迟的点有两个，一个是日志备份本身的延迟有大概两三分钟，一个是每隔15分钟才同步一次日志到oss，理论上RPO大概能做到20分钟，要是br能够直接写oss，RPO就能做到5分钟内。

在现有架构下进一步提高RPO的可能性不大，因为同步一次日志至少要几分钟，数据变化的速度越快，日志的同步负担越重，设置成15分钟是为了防止同步任务重叠堆积。那就研究提高一下RTO，我决定再鼓捣一下cdc做个数据同步。

在生产环境，利用7个tiflash节点部署cdc节点，实际用不到，下面是拓扑文件：

扩容以后的全家福，挺壮观

再利用tiflash节点部署一个备用集群：

在备用集群恢复一份数据出来。

建立一个changefeed，就实现实时复制了。

建立changefeed成功

查询一下状态，确认是normal

重新向生产库压数据

数据的同步延迟很小（上面的是生产库，下面的是备用库），可能是因为我给的压力也不是很大。

想给一点儿压力，结果在清理数据的时候把复制给玩坏了。

删除changefeed

重新建立一个，注意这里的URI用的是tidb

发现备用库缺了一段儿数据（上面的是生产库，下面的是备用库）

这种补数据的操作在cdc上下游均为tidb的情况下不需要重新同步，也不需要停业务，只要用sync_diff_inspector 进行在线对比生成补数据脚本，就可以利用脚本补齐缺失的数据。

在线对比需要开启三个cdc配置，生成一个cdc配置文件

要更新配置需要先暂停changefeed

更新配置

恢复复制

在cdc下游（备用数据库），查询两个tso。

将两个tso分别填充到sync_diff_inspector 配置文件中的上游数据库和下游数据库配置中。

使用配置文件进行对比

对比结果的概要，上游多8500行

SQL脚本

执行脚本

数据已经补齐

现在还有最后一个问题：如何完成主备切换？

集群的业务入口是slb，slb下面挂了两个tidb节点，切换其实就是切tidb，将这两个节点从生产数据库移除，再挂载到备用数据库即可完成切换。

先给生产库加一个额外的tidb节点

扩容生产库

生产库的tidb节点

缩容 ，将挂在slb下的两个tidb节点移除

扩容配置 ，将slb下挂的节点 作为tidb节点重新挂载到备用集群

扩容备用集群

备用集群各节点

登录备用数据库，压测还在继续。

RTO在分钟级，RPO约等于0。

我终于可以安心睡一个好觉了。 最后，标题不是笔误，因为我真的叫安欣。