拍摄纸牌屋的Netflix为何要迁移数据库入云？(3)

至此我们的数据库体系结构已经由部署在某一AWS区域内EC2实例上的MySQL主数据库组成.我们还搭建了一个从主数据库复制数据的灾难恢复数据库,如果主数据库故障,该数据库将成为新的主数据.另外我们还在在其他AWS区域设置了从数据库,这些数据库主要为应用程序提供只读访问.

至此我们的计费系统已经全部搬入云中,现在看起来是下面这个样子：

数据库的迁移过程

你是否考虑过为了顺利完成复杂的数据库迁移任务,都需要考虑并解决哪些问题?但你可能也会问,“这有什么复杂的?”

想想数据库迁移过程中遇到的下列挑战吧,我们本次迁移几乎遇到了所有这些问题：

• 源和目标硬件存在差异；

• 使用了不同的操作系统；

• 需要跨域异构数据库进行迁移；

• 涉及多个数据中心 – Netflix数据中心(DC)和AWS云；

• 要迁移的是非常关键的交易计费数据；

• 有选择地迁移数据集；
• 需要在最小停机时间的前提下迁移持续变化的数据.

在任何迁移项目中,数据库能否成功迁移直接决定了整个项目能否成功.下文将介绍为确保迁移项目成功完成所采取的一些关键措施.

数据库的选择

为顺利处理付款过程中产生的事务,计费应用程序的事务须符合ACID(原子性、一致性、隔离性、持久性)要求.RDBMS似乎是此类数据存储的最佳选择.

Oracle：由于源数据库使用了Oracle产品,直接迁移至云中运行的Oracle数据库可避免进行跨数据库迁移,降低代码开发和配置工作量.我们过去在生产环境中使用Oracle产品的体验也让自己对该产品的性能和伸缩性更有信心.然而考虑到许可成本以及“依原样”迁移遗留数据所要产生的技术债,最终只能寻求其他解决方案.

AWS RDS MySQL：理想情况下我们会选择MySQL?RDS作为后端,毕竟亚马逊在关系型数据库即服务产品的管理和升级方面做的挺好,为了实现高可用还提供了多可用区(AZ)支持.然而RDS的主要不足之处在于存储容量有着6TB上限.我们迁移时的容量已接近10TB.

AWS Aurora：AWS Aurora可以满足我们对存储容量的需求,但目前还是Beta测试版.

PostgreSQL：PostgreSQL是一种强大的对象-关系开源数据库系统,但我们团队内部缺乏足够的PostgreSQL使用经验.在自己的数据中心内我们主要使用Oracle和MySQL作为后端数据库,更重要的是选择PostgreSQL会导致未来无法无缝迁移至Aurora,因为Aurora使用了基于MySQL的引擎.

EC2 MySQL：最终我们的计费系统选择使用EC2 MySQL,这种技术无须许可成本,同时未来可以直接迁移至Aurora.该方式需要在i2.8xlarge实例上使用InnoDB引擎配置MySQL.

生产数据库体系结构

为确保计费应用程序可以承受基础结构、区域和地域故障,并将可能的停机时间降至最低,高可用性和伸缩性是我们设计整个体系结构时最主要的考虑因素.

通过在另一个区域内为数据库主副本创建DRBD副本,即可承受区域故障,节点出错等基础结构故障,以及EBS卷故障.当本地和远程写操作均完成后,会使用“同步复制协议”将主要节点上的写操作标记为已完成.借此可确保一个节点的故障绝对不会导致数据丢失.虽然这样的设计会影响写操作的延迟,但延迟依然在SLA可接受的范围内.

读取副本可设置为本地或跨区域配置,这样不仅可以满足对高可用的需求,而且有助于增强伸缩性.来自ETL作业的读取流量会分流至读取副本,借此降低主要数据库执行繁重ETL批处理的负担.

一旦主要MySQL数据库故障,工作负载将被故障转移至使用同步模式进行复制的DRBD辅助节点.辅助节点开始承担主节点的角色后,会更改数据库主机的route53 DNS记录将其指向新的主节点.按照设计,计费应用程序与生俱来的“批处理”特性可顺利应对此类停机事件.CNAME记录传播工作完成后,客户端连接不会回退(Fallback),而是会建立指向新主节点的连接.

迁移工具的选择

我们在迁移工具的选择方面花费了大量时间和精力.概念验证工作成功与否的最主要条件在于能否重启动批载荷(Bulk load)、双向复制,以及数据完整性.在评估迁移工具时我们主要侧重于下列几个条件.

• 批/增量载荷的重启动；

• 双向复制；

• 每个表并行性(Parallelism per table)；

• 数据完整性；

• 传输过程中错误报告；

• 上线后回滚的能力；

• 性能；
• 易用性.

GoldenGate以丰富的功能脱颖而出,该产品很好地满足了我们的需求.GoldenGate可以在遇到故障后重启动批载荷(很少的几张表就达到数百GB容量),该产品的双向复制功能可以让我们从MySQL轻松回滚到Oracle.

（编辑：ASP站长网）