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

架构转换工具：为了实现架构转换并进行验证,我们评估了多种工具,但由于原有架构设计中所存在的问题,这些工具默认提供的架构转换功能无法使用.即使GoldenGate也无法将Oracle架构转换为相应的MySQL版本,因此只能首先由应用程序的所有者重新定义架构.

优化架构也是我们此次迁移的目标之一,数据库和应用程序团队合作审阅了数据类型,并通过多次迭代找出了所有误配的内容.在存在误配的情况下,GoldenGate会对这些值进行截断以符合MySQL数据类型的要求.问了缓解这一问题,我们主要借助数据对比工具和GoldenGate错误日志找出源和目标之间数据类型的误配.

数据完整性

完整加载和增量加载执行完毕后,又遇到另一个让人气馁的问题：必须核实目标副本的数据完整性.由于Oracle和MySQL使用了不同数据类型,无法通过用普通封装脚本对比行键(Rowkey)哈希值的方式保证数据的精确性.

虽然有几个第三方工具能跨越不同数据库对实际值进行数据对比,但总量10TB的数据集比较起来也不容易.最终我们使用这些工具对比了样本数据集,借此找出了少数由于架构映射错误导致的不一致问题.

测试刷新：确保数据完整性的方法之一是使用应用程序对生产数据库的副本进行测试.为此可安排从MySQL生产数据库进行刷新并用于测试.考虑到生产环境使用EBS作为存储,只要创建EBS快照即可轻松创建测试环境,同时可在测试中执行时间点恢复.为确保足够高的数据质量,这一过程重复了多次.

Sqoop作业：我们在数据校正过程中使用了ETL作业和报表,并使用Sqoop作业从Oracle中拉取创建报表所需的数据.此外还针对MySQL配置了这些作业.在源和目标之间进行持续复制的过程中,会在ETL的特定时间窗口内运行报表,这样即可找出增量加载过程中产生的变化.

行计数(Row count)是用于对源/目标进行比较和匹配的另一种方法.为此需要首先暂停目标的增量加载,并对Oracle和MySQL的行数进行匹配.在使用GoldenGate完整加载表之后也会对行计数的结果进行比较.

性能调优

基础结构：计费应用程序将数据持久保存在数据中心内两个Oracle数据库中,运行数据库的计算机性能极为强大,使用了IBM Power 7,32颗双核心64位处理器,750GB内存,通过SVC MCS集群分配TB级别的存储,集群使用了4GB/s接口,运行RAID10配置的8G4集群.

迁移过程中最大的顾虑是性能,目标数据库将整合到一个装备有32颗vCPU和244GB内存的i2.8xlarge服务器上.为了优化查询性能,应用程序团队在应用层进行了大量调优.在Vector的帮助下,性能团队可以方便地发现性能瓶颈,通过调整特定的系统和内核参数解决这些问题.详细信息请参阅附件.

我们用EBS供应的IOPS卷组建RAID0实现了极高的读写性能.为了通过每个卷获得更高吞吐率,共使用5个容量各4TB的卷,而没有使用更大容量的单个卷.这样做也可以加快创建快照和还原的速度.

数据库：对于MySQL的使用我们还有一个比较大的顾虑,担心计费应用程序在对数据执行批处理过程中MySQL的吞吐率无法满足数据规模的需求.Percona为此提供了顾问支持,在迁移过程中以及迁移之后,MySQL数据库的性能表现都让我们感到满意.

这里的诀窍在于使用两个cnf文件,一个用于迁移数据的过程中对innodb_log_file_size之类的参数进行优化,以便执行批量插入；第二个cnf文件用于在实时生产应用程序工作负载中对innodb_buffer_pool_instances之类的参数进行调整,借此促进事务的实时加载.详情请参阅附件.

数据加载：在概念验证过程中,我们针对开启和关闭索引两种情况测试了表的初始加载,并决定在加载前启用所有索引.这样做的原因在于MySQL中索引是通过单线程方式创建的(大部分表有多个索引),因此我们改为使用GoldenGate的并行加载功能在合理的时间内为表中填入索引.最后一次割接过程中还启用了外键约束.

我们学到的另一个窍门是按照实例的内核数量执行相同遍数的完整和增量加载过程.如果这些过程的执行遍数超过内核数量,数据加载性能将大幅降低,因为实例需要花费更多时间进行上下文切换.通过完整加载和增量加载将10TB数据装入目标MySQL数据库,这一过程用了大约两周时间.

结论

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!