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

GoldenGate的主要不足在于了解该工具工作原理所面临的学习曲线.此外该产品使用了易于出错的手工配置过程,这也增大了项目难度.如果源表没有主键或唯一键,GoldenGate会使用所有列作为提取和复制操作的增补日志键对.但我们发现了一些问题,例如复制到目标的数据仅仅是相关表的增量载荷,因此决定在切换这些表的过程中执行不预定义主键或唯一键的完整加载.GoldenGate的优势和包含的功能远远超过了所造成的困难,我们最终选择使用该工具.

架构转换和验证

由于源和目标数据库存在差异,数据类型和长度也有所不同,为了在迁移数据的同时确保数据完整性,验证工作变得必不可少.

数据类型误配造成的问题需要花些时间来修复.例如因为一些历史遗留原因,Oracle中的很多数值已定义为Number数据类型,MySQL缺少类似的类型.Oracle中的Number数据类型会存储定数和浮点数,这一点比较难以处理.

一些源表中的列使用Number代表整数,另一些情况则会代表十进制数值,其中一些值的长度甚至达到38位.作为对比,MySQL使用了明确的数据类型,例如Int、bigInt、decimal、double等,而bigInt不能超过18位.因此必须确保通过恰当的映射以便在MySQL中反应精确的值.

分区表(Partitioned table)需要特殊处理,与Oracle的做法不同,MySQL会将分区键视作主键和唯一键的一部分.为确保不对应用逻辑和查询产生影响,必须用恰当的分区键重新定义目标架构.

默认值的处理在MySQL和Oracle之间也有不同.对于包含NOT NULL值的列,MySQL会确定该列暗含的默认值,在MySQL中启用Strict模式即可看到此类数据转换问题,这样的事务会执行失败并显示在GoldenGate的错误日志中.

架构转换工具：为了实现架构转换并进行验证,我们评估了多种工具,但由于原有架构设计中所存在的问题,这些工具默认提供的架构转换功能无法使用.即使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数据库,这一过程用了大约两周时间.

结论

（编辑：ASP站长网）