||
本文来源：原创投稿
* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。
在上一篇 分布式数据库测试平台构建之路-探索篇（1），笔者简单总结了在单机数据库测试工作中，“测什么”与“怎么测”这样两个关键问题。而在单机数据库中需要测试的内容，在分布式数据库上也一样需要测试，至于那些只有分布式数据库才需要进行的测试内容，笔者则将从本篇开始逐步总结。
就像单机数据库到分布式数据库的过渡不是一蹴而就的那样，我们的脚步也不需要太快，不要一下子就跳进分布式事务、分布式一致性这些会令人头大的概念中。我们先从数据副本、备份恢复之类，在单机数据库场景下也同样存在的概念开始。
每年毕业季总会听闻这样的故事：某某的电脑硬盘坏了，导致辛辛苦苦写的毕业论文都打了水漂。好在现在各种网盘、云盘和在线协作类的服务发展起来了，稍微聪慧点的后辈们就吸取了诸多前辈们的教训，知道重要的资料和文件不能只存在自己的电脑里。
刻在石壁上的壁画会因为风化而模糊不清，写在纸张上的文字可能毁灭于火焰，而硬盘上的数据则可能由于一次震动、一次断电就再也无法完整读取。故而，对于承诺了数据持久性保证的数据库软件来说，除了在单个数据库程序实例的内部需要有专门的机制，在位于不同物理机器上的两个数据库程序之间，也需要一定的机制进行数据的备份。
在对备份这个话题进行展开之前，我们先对备份这个概念进行一些分类：
| 分类规则 | 类型1 | 类型2 |
|---|---|---|
| 备份时机 | 冷备份：在数据库服务停止之后，进行的数据备份 | 热备份：在保证数据库服务不停机的情况下，进行数据备份 |
| 备份数据的量 | 全量备份：对数据库中的数据，进行整体性的备份。在许多场景中，可能不会对数据库中的所有库表进行备份，这里的整体性是指每个需要备份的库表的整体性。 | 增量备份：将数据库中的数据，自某一时间点之后所发生的数据变化进行的备份。 |
| 备份的实现机制 | 基于数据文件：在源端数据库实例导出csv等格式的数据文件，在目标端数据库再将数据文件导入；直接拷贝源端的数据目录，在目标端使用使用这个数据目录直接启动 | 基于日志：在源端数据库实例上，将所有用户操作语句或是数据的实际变化记录成日志文件，在目标端将日志文件回放 |
对于增量备份，如果强调实时性，就变成了数据同步。关于数据同步的内容，笔者会放到后续的文章中。
对于数据库的开发者和用户而言，数据备份的各种分类都有很重要的意义，但对于测试人员来说，如果只关心备份恢复过程中数据库实例的状态变化，将应该自动化完成的操作步骤放到一边，最后其实只有冷热备份之分——由于涉及到在线服务，热备要比冷备多出一些测试指标。
| 测试指标 | 指标具体的描述 | 测试的方法 |
|---|---|---|
| 数据备份的数据正确性 | 在源端与目标端的数据起点状态一致的情况下，经过备份恢复操作源端与目标端的数据终点状态一致。 | 小数据量或测试时长允许的情况下，可以通过各种粗暴的方法进行全量校验；数据量特别大的情况，可以考虑随机抽取若干数据段进行对比校验；在数据库本身支持校验和功能的情况下，如果可以的话，尽量使用校验和进行数据校验。 |
| 备份和恢复的速度 | 单纯的性能测试。 | 根据实际生产场景，设计测试所需的库表与数据量，记录备份和恢复的耗时，与过程中的硬件资源消耗、必要的数据库监控项等。 |
| 备份和恢复操作对在线业务的影响 | 除了备份恢复操作之外，还要同时模拟业务压力，现在的用户一般都有不能停机的业务，很看重各种重操作对在线业务的影响。 | 除了备份恢复相关的必要监控项之外，还要观察在线业务在备份恢复操作开始结束前后，TPS、QPS等重要指标的变化幅度。 |
从备份恢复开始，数据库中的数据就不再只存放在一台机器一个实例上了，相当于朝着分布式数据库迈出了最初的一小步，这一阶段的测试工作还是很简单的。在打开这扇大门之后，就会进入一个复杂性陡增的世界。
合作电话：010-64087828
社区邮箱：greatsql@greatdb.com
