从微软 SQL server 到 Amazon Aurora 的迁移之路

# 前言 在2022年的春天，随着气温一天比一天高，公司大领导对微软 SQL Server 数据库也越来越烦躁，主要的原因就一个——钱。公司在业务规模很小的时候就使用了微软 SQL Server，随着公司业务规模的扩大，SQL Server 集群的数量也逐步增多，大家都知道，SQL Server 是需要微软授权的，因此这方面的开支占比也越来越高，逐步占据了公司总支出的很大的比例。为了能够节约开支，公司运维层提出更改数据库的计划，当然更换数据库的评估工作，也就落在了技术架构组...... # 数据库的选型方向 众所周知，MySQL 在开源数据库中占有重要的一席地。当然，隐隐有后来居上架势的 PostgreSQL 也名列在前（数据库排名参见下图）。既然是为了省钱，那么这两位大拿级的数据库均在考虑之列。  后来，在与亚马逊云科技专家的交流中，又接触了新的数据库引擎 Aurora，在得知其优异的高可用支持以及兼容 MySQL 和 PostgreSQL 后，我决定去更深层次的了解和试用 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail)，以便为公司的决策提供强力支持。 由于数据库的测试大约在1亿条左右，因此创建新的数据非常缓慢，整个测试过程大约持续了1个月左右。 当然，在进行技术测试之前，还是需要计算以下成本的，因为此次的目的就是节约成本。在选择 db.r5.xlarge (4 core, 16 G)、以及 db.r5.2xlarge (8 core, 32 G)两个规格的数据库以及双副本的情况下，粗略的进行了比较，其结果是，使用 SQL Server 的价格是 Aurora 的3.97倍。基于公司的数据库规模，大约每年可以节约33万美金。 # Aurora 简介 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 是亚马逊打造的自有关系型数据库，其与 MySQL 和 PostgreSQL 数据库兼容，专为云数据库打造，它的性能和可用性与商用数据库相当，并且成本只有其1/10，当然还有一点是公司最看重的指标——高可用性，支持非常好。 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) 支持单主集群和双主集群部署方案。 **单主集群**：主服务器可以同时读写，其他从服务器为只读，最多可以支持15个副本。此种方式比较适合**写少读多**场景，其读写流程如下图所示。节点数据来自实例集群卷，在主实例写数据后同步，延迟通常低于100ms，主节点故障以后按照 Quorum 协议选主，选上的节点变成可写。  **多主集群**：所有 DB 实例均可读写，目前最大支持4个。【不支持单个实例读写其他只读的策略】某个 DB 实例不可用后，没有故障切换处理机制，因为其他 DB 实例会直接接管写操作。为了区分这种可用性，亚马逊云科技称它是持续可用，以区分单实例的高可用。多主集群需要处理写冲突，为了多主强一致，可以开启先写后读。 这里基于高可用的考虑，我仅测试单主集群的部署方案。高可用的原理来自 Quorum 算法，Amzon Aurora是6份数据，写4份作为一次成功写入来保证集群的数据写入安全，参见下图。最新的数据在主节点是有保证的，只读副本一般会有延迟，但延迟比较低，正常情况下不超过10ms，因此有强一致要求的场景需要考虑读写分离的区别。  官方的测试和对外说明为 Aurora 比 MySQL 快5倍，比 PostgreSQL 快3倍，参见下图。  # 数据库 Sysbench 测试 为了测试数据库的读写性能，那肯定需要介绍下 TPC-C 标准。 TPC-C 是一个在线事务处理(OLTP)基准，于1992年7月批准。TPC-C 比以前的 OLTP 基准测试(如TPC-A)更复杂，因为它引入了更多的事务类型、更复杂的数据库和整体执行结构 TPC-C 混合了5个不同类型和复杂性的并发事务，它们要么在线执行，要么排队等待延迟执行。该数据库由9种类型的表组成，这些表的记录和填充大小各不相同。TPC-C 是以每分钟事务数(tpmC)来衡量的。虽然基准描述以批发供应商的为例子，但 TPC-C 并不局限于任何特定业务部门的活动，而是代表必须管理、销售或分发产品或服务的任何行业。 测试环境当然需要准备几台 CentOS7 云服务器了，测试工具就采用 BenchmarkSQL。测试机器选型如下： | 机型 | vCPU | 内存(GiB) | 磁盘 | 网络 | | ------------------- | ---- | ------- | --------- | -- | | 2台db.r5.2xlarge EC2 | 8 | 32 | 通用SSD 40G | 高 | 数据库的选型如下： | 数据库 | DB instance class | vCPU | 内存(GiB) | 磁盘 | 网络 | | ---------------- | --------------- | ---- | ------- | ------ | -- | | Aurora mysql5.6 | db.r4.xlarge | 4 | 32 | SSD 1T | 高 | | Arora PostgreSQL | db.r4.xlarge | 4 | 32 | SSD 1T | 高 | | SqlServer RDS | db.r5.xlarge | 4 | 32 | SSD 1T | 高 | 数据的准备工作： 在测试开始前，标准数据商品 ITEM 表中固定包含 10 万种商品，仓库的数量可进行调整，假设 WAREHOUSE 表中有 n 条记录，那么： ● STOCK 表中应有 n \* 10 万条记录（每个仓库对应 10 万种商品的库存数据） ● DISTRICT 表中应有 n\* 10 条记录（每个仓库为 10 个地区提供服务） ● CUSTOMER 表中应有 n \* 10 \* 3000 条记录（每个地区有 3000 个客户） ● HISTORY 表中应有 n \* 10 \* 3000 条记录（每个客户一条交易历史） ● ORDER 表中应有 n \* 10 \* 3000 条记录（每个地区 3000 个订单），并且最后生成的 900 个订单被添加到 NEW-ORDER 表中，每个订单随机生成 5 \~ 15 条 ORDER-LINE 记录。 我们将以 100,200，500 WAREHOUSE 为例进行测试。  BenchmarkSQL 需要进行构建。命令如下： ```js git clone https\\://github.com/pgsql-io/benchmarksql.git cd \\~/benchmarksql mvn ``` 对于 Linux 环境，测试前均需要提前配置，启动网络方面的限制，打开句柄数限制等。 测试前需要配置数据库配置文件，支持 SQL server、MySQL 和 PostgreSQL。 测试命令如下： ```js ./runDatabaseBuild.sh my.properties \\# 开始压测 ./runDatabaseBuild.sh my.properties ``` 测试结果如下所示。 ```js 2022-03-15 11:45:00,024 INFO - result, \\__\\__\\_ latency (seconds) \\__\\__\\_ 2022-03-15 11:45:00,024 INFO - result, TransType count | mix % | mean max 90th% | rbk% errors 2022-03-15 11:45:00,024 INFO - result, +--------------+---------------+---------+---------+---------+---------+---------+---------------+ 2022-03-15 11:45:00,025 INFO - result, | NEW_ORDER | 18,919 | 43.934 | 0.053 | 0.146 | 0.073 | 1.026 | 0 | 2022-03-15 11:45:00,035 INFO - result, | PAYMENT | 18,661 | 43.357 | 0.014 | 0.071 | 0.017 | 0.000 | 0 | 2022-03-15 11:45:00,036 INFO - result, | ORDER_STATUS | 1,851 | 4.301 | 0.004 | 0.011 | 0.006 | 0.000 | 0 | 2022-03-15 11:45:00,036 INFO - result, | STOCK_LEVEL | 1,832 | 4.261 | 0.003 | 0.012 | 0.004 | 0.000 | 0 | 2022-03-15 11:45:00,036 INFO - result, | DELIVERY | 1,783 | 4.147 | 0.000 | 0.001 | 0.001 | 0.000 | 0 | 2022-03-15 11:45:00,036 INFO - result, | DELIVERY_BG | 1,783 | 0.000 | 0.098 | 0.190 | 0.104 | 0.000 | 0 | 2022-03-15 11:45:00,037 INFO - result, +--------------+---------------+---------+---------+---------+---------+---------+---------------+ 2022-03-15 11:45:00,037 INFO - result, 2022-03-15 11:45:00,037 INFO - result, Overall NOPM: 631 (98.02% of the theoretical maximum) 2022-03-15 11:45:00,037 INFO - result, Overall TPM: 1,435 ``` 经测试，其结果如下： | 数据库 | tpmC（100仓库） | tpmC（200仓库） | tpmC（200仓库） | | ---------------- | ----------- | ----------- | ----------- | | Aurora mysql5.6 | 3360 | 4032 | 38031 | | Arora PostgreSQL | 12800 | 23021 | 39027 | | SqlServer RDS | 4073 | 4135 | 41030 | 经过一系列测试，其结果是在1000万数据~1亿数据量的时候 Aurora for PostgreSQL在事务读写方面超越了 SQL Server RDS 和 Aurora for MySQL，基本维持在10倍左右的事务读写效率，而在超过1亿数据后反而是 SQL Server 效率越来越高。单数据的读写方面 Aurora for MySQL 在100w-1000w数据时候超过了 PostgreSQL 和 SQL Server5 倍左右，其他场景下反而没有优势。 经过最终的评审和商议，最终决定将方案修改为 Aurora for PostgreSQL。 # 数据库迁移工作 迁移数据库是比较麻烦的，不过如果选用了 Aurora 服务，可以使用亚马逊云科技的 DMS 服务来进行数据的迁移工作，这个服务为我们的数据库迁移工作节省了很多的时间和精力。 迁移工作大致分为以下几个阶段： 1.  前期评估，采用亚马逊云科技的 Schema 转换工具进行数据库评估工作； 2.  根据评估，对 schema 转换工具内的问题进行修正或使用标准 SQL 规避； 3.  配置计划，对源数据库进分批或整体转换任务到测试数据库； 4.  修改程序集的 SQL 提供服务，修正内置 SQL 语句等，并进行测试； 5.  上线测试； 6.  制定上线计划； 7.  升级程序，开启双写库； 8.  打数据库时间标签，启动转换； 9.  校验数据； 10.  删除旧数据库，释放资源。 # 后记 数据库迁移对整个团队来说，是一件重要、但不迫切、并且很繁琐的事务。一旦迁移中出现问题，则往往导致工作暂停甚至延期。数据库的迁移不仅仅涉及到运维团队、数据库团队和开发团队，还涉及到商务团队和售后售前团队，因此保障整个过程的数据稳定和安全是重中之重。而采用了Amzon Aurora 和 DMS 服务后，一切变得简单起来，这就是云的魅力。 文章审核：caoliuh