拍摄纸牌屋的Netflix为何要迁移数据库入云？
数据库的迁移过程你是否考虑过为了顺利完成复杂的数据库迁移任务,都需要考虑并解决哪些问题?但你可能也会问,“这有什么复杂的?” 想想数据库迁移过程中遇到的下列挑战吧,我们本次迁移几乎遇到了所有这些问题：
在任何迁移项目中,数据库能否成功迁移直接决定了整个项目能否成功.下文将介绍为确保迁移项目成功完成所采取的一些关键措施. 数据库的选择为顺利处理付款过程中产生的事务,计费应用程序的事务须符合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)、双向复制,以及数据完整性.在评估迁移工具时我们主要侧重于下列几个条件.
GoldenGate以丰富的功能脱颖而出,该产品很好地满足了我们的需求.GoldenGate可以在遇到故障后重启动批载荷(很少的几张表就达到数百GB容量),该产品的双向复制功能可以让我们从MySQL轻松回滚到Oracle. （编辑：辽源站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |