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

数据库
SQL
re:Invent
Amazon Aurora
0
0
# 前言 在2022年的春天,随着气温一天比一天高,公司大领导对微软 SQL Server 数据库也越来越烦躁,主要的原因就一个——钱。公司在业务规模很小的时候就使用了微软 SQL Server,随着公司业务规模的扩大,SQL Server 集群的数量也逐步增多,大家都知道,SQL Server 是需要微软授权的,因此这方面的开支占比也越来越高,逐步占据了公司总支出的很大的比例。为了能够节约开支,公司运维层提出更改数据库的计划,当然更换数据库的评估工作,也就落在了技术架构组...... # 数据库的选型方向 众所周知,MySQL 在开源数据库中占有重要的一席地。当然,隐隐有后来居上架势的 PostgreSQL 也名列在前(数据库排名参见下图)。既然是为了省钱,那么这两位大拿级的数据库均在考虑之列。 ![image.png](https://dev-media.amazoncloud.cn/a241c874d3284bceaeb560874bd4eec3_image.png "image.png") 后来,在与亚马逊云科技专家的交流中,又接触了新的数据库引擎 Aurora,在得知其优异的高可用支持以及兼容 MySQL 和 PostgreSQL 后,我决定去更深层次的了解和试用 Amazon Aurora,以便为公司的决策提供强力支持。 由于数据库的测试大约在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 是亚马逊打造的自有关系型数据库,其与 MySQL 和 PostgreSQL 数据库兼容,专为云数据库打造,它的性能和可用性与商用数据库相当,并且成本只有其1/10,当然还有一点是公司最看重的指标——高可用性,支持非常好。 Amazon Aurora 支持单主集群和双主集群部署方案。 **单主集群**:主服务器可以同时读写,其他从服务器为只读,最多可以支持15个副本。此种方式比较适合**写少读多**场景,其读写流程如下图所示。节点数据来自实例集群卷,在主实例写数据后同步,延迟通常低于100ms,主节点故障以后按照 Quorum 协议选主,选上的节点变成可写。 ![image.png](https://dev-media.amazoncloud.cn/edb87d3ed76e44c3bf0a2ba03d53b776_image.png "image.png") **多主集群**:所有 DB 实例均可读写,目前最大支持4个。【不支持单个实例读写其他只读的策略】某个 DB 实例不可用后,没有故障切换处理机制,因为其他 DB 实例会直接接管写操作。为了区分这种可用性,亚马逊云科技称它是持续可用,以区分单实例的高可用。多主集群需要处理写冲突,为了多主强一致,可以开启先写后读。 这里基于高可用的考虑,我仅测试单主集群的部署方案。高可用的原理来自 Quorum 算法,Amzon Aurora是6份数据,写4份作为一次成功写入来保证集群的数据写入安全,参见下图。最新的数据在主节点是有保证的,只读副本一般会有延迟,但延迟比较低,正常情况下不超过10ms,因此有强一致要求的场景需要考虑读写分离的区别。 ![image1.png](https://dev-media.amazoncloud.cn/0e8ea3f8b3374bea992503cf7b2bbc6c_image1.png "image1.png") 官方的测试和对外说明为 Aurora 比 MySQL 快5倍,比 PostgreSQL 快3倍,参见下图。 ![image.png](https://dev-media.amazoncloud.cn/4d799d8334d045dc92a2b13ff016245e_image.png "image.png") # 数据库 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 为例进行测试。 ![image.png](https://dev-media.amazoncloud.cn/ea76c9ddd7c54a919ed88774b08a4c0d_image.png "image.png") 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
0
目录
关闭
contact-us