Oracle/云MySQL/MsSQL“大迁移”真相及最优方案

  • 时间:
  • 浏览:110

最近一段时间碰到如可让 数据迁移的项目,如:Oracle迁移到MySQL,MsSQL迁移到MySQL,云MySQL迁移到本地MySQL。对于这方面做了系统的分类整理。包括:迁移方案的取舍、如可出現迁移遇到的坑、如可修改MySQL参数获取最大性能,加入分库分表的需求如可实现?文章的最后,作者做了就是 可行性的总结,码字不易,假使 对您有帮助,感谢转发。

迁移方案的取舍:


抛开业务逻辑的因素,根据不同的版本、不同平台、不同停机时间需求,有不同的可选路径决定迁移方

法和工具:

迁移土法子优点缺点
SQL LOAD操作简单、传输强度快、取舍数据范围灵活需自定义开发批量操作、对于CLOB等特殊字段无法支持
OGG商用软件,广泛的数据库平台支持、灵活的好友克隆架构、基于日志的实时数据同步、稳定性高对维护技能有一定的要求、费用高
ETL 软件使用方便简单、定时同步批量防止极少量表需定制化配置
MYSQL移植工具安装简单、可自动创建表不可定制、技术支持较弱
定制迁移工具可深度1定制,保证最佳性能和最短停机时间暂无



假使 不同的数据库版本、不同的组件安装、不同的应用开发行态后会 由于迁移计划的简化性和差异性。

调研中,除了OGG,有有哪几个MySQL迁移的工具,推荐的比较多,假使 收费的。

【工具:OGG (goldengate) 

同时支持Oracle,Mssql 迁移到 MySQL 上

参数:filter,COMPUTE 进行分库分表逻辑】

● SQLyog

   (https://www.webyog.com/product/sqlyog)

● Navicat Premium

  (https://www.navicat.com/products/navicat-premium)

● Mss2sql

   (http://www.convert-in.com/)

● DB2DB

   (http://www.szmesoft.com/DB2DB)

取舍迁移软件,时要要考虑 软件易用性, 防止传输强度和内存占用,数据全部性。这帕累托图怪怪的要。

以上四款软件中:

1. 最不推荐使用的是 Navicat Premium,主要由于是数据的全部性表现较差,转换后的数

据不还并能立即用于生产环境,时要应用应用程序员仔细自行查找由于和分析。

2. SQLyog 有较好的数据全部性,但整体防止传输强度非常的慢,假使 数据较大的清况 下,时要浪费非常多宝

贵的时间。比较推荐的是

3. DB2DB,防止传输强度,数据全部性,整体表现较好,操作起来确实方便。

我我个人所有所有趋向于我个人所有所有写python脚本。

迁移中会处于哪些地方细节上的疑问?


1. 字符集

字符集转化:Oracle字符集AL32UTF8,ZHS16GBK,转加上MySQL支持的字符集Latin1,utf8,utf8mb4(emoji的表情符)

Mysql对于字符集里有原先概念:原先是”Character set”原先是”Collations”。

Collations:Mysql对字符的比较,排序规则 

Character set:字符的编码土法子

2. 字段类型

Oracle Row, Clob,BINARY_DOUBLE类型转化成MySQL支持的字段类型。

如:Oracle CLOB字段最大长度4G对应MySQL LONGTEXT 等等,但就是 把数据哪些地方地方数据迁移到MySQL上,还并能 想象到会处于哪些地方事情。

3. 主键

如可让 源表那么设置主键, 但对于MySQL来说主键的意思非常大,怪怪的是好友克隆环节里。

4. 迁移时间和数据量 

对于现在在线不间断提供的业务非常重要,按照这个指标还并能 制定全量假使 增量土法子进行迁移。

5. 考虑因素

除了以上内容源数据库还有账号、视图、存储过程、函数、触发器,索引等,同样也怪怪的要,时要时要考虑的原先因素。

6. 校验数据

这个关最后门卡,当数据迁移完成后,如可确保数据的正确迁移、那么遗漏和错误是原先太难的疑问。这里的难时要实现起来困难,也无须把它自动化,达到节省人力的目标怪怪的难,假使 两者的数据类型不同,数据量偏大,写如可让 脚本去做检查效果不大。

数据的全部性验证是十分重要的,千万无须怕验证到错误后会花好长已经 去抽取同步的操作这个步。假使 一旦那么验证到错误,让数据进行了使用却乱掉了,后果将更严重。

一般场景下时要对应查询数据行数count来判断数据的是不是处于疑问。或则 是用create_time时间字段进行验证数据。或则抽取帕累托图数据进行验证。还有导入过程中的log和警告 ,errors 等信息。

MySQL如可让 性能参数

还并能 在导入数据的已经 预先修改如可让 参数,来获取最大性能的防止,比如还并能 把自适应hash关掉,Doublewrite关掉,假使 调整缓存区,log文件的大小,把能变大的都变大,把能关的都关掉来获取最大的性能,接下来说有哪几个常用的:

1. innodb_flush_log_at_trx_commit

  • 假使 innodb_flush_log_at_trx_commit设置为0,log buffer将每秒一次地写入log file中,假使 log file的flush(刷到磁盘)操作同时进行。该模式下,在事务提交时,不不主动触发写入磁盘的操作。
  • 假使 innodb_flush_log_at_trx_commit设置为1,每次事务提交时MySQL后会 把log buffer的数据写入log file,假使 flush(刷到磁盘)中去。
  • 假使 innodb_flush_log_at_trx_commit设置为2,每次事务提交时MySQL后会 把log buffer的数据写入log file。假使 flush(刷到磁盘)的操作无须会同时进行。该模式下,MySQL会每秒执行一次 flush(刷到磁盘)操作。

注意:假使 应用应用应用程序调度策略疑问,这个“每秒执行一次 flush(刷到磁盘)操作”并时要保证100%的“每秒”。

2. sync_binlog

  • sync_binlog 的默认值是0,像操作系统刷其它文件的机制一样,MySQL不不同步到磁盘中去,就是 依赖操作系统来刷新binary log。
  • 当sync_binlog =N (N>0) ,MySQL 在每写N次 二进制日志binary log时,会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。

注意:假使 启用了autocommit,那么每原先一句话statement就会有一次写操作;假使 每个事务对应原先写操作。

3. max_allowed_packet

  • 在导大容量数据怪怪的是CLOB数据时,假使 会出現异常:“Packets larger than max_allowed_packet are not allowed”。这是假使 MySQL数据库有原先系统参数max_allowed_packet,其默认值为1048576(1M),还并能 通过如下一句话在数据库中查询其值:show VARIABLES like ‘%max_allowed_packet%’; 
  • 修改此参数的土法子是在MySQL文件夹找到my.cnf文件,在my.cnf文件[MySQLd]中加上一行:max_allowed_packet=16777216

4. innodb_log_file_size

InnoDB日志文件过多,会影响MySQL崩溃恢复的时间,太小会增加IO负担,就是 大家 要调整至少的日志大小。在数据导入时先把这个值调大如可让 。防止无谓的buffer pool的flush操作。但就是 能把innodb_log_file_size开得过多,会明显增加 InnoDB的log写入操作,假使 会造成操作系统时要更多的Disk Cache开销。

5. innodb_log_buffer_size

InnoDB用于将日志文件写入磁盘时的缓冲区大小字节数。为了实现较高写入吞吐率,可增大该参数的默认值。原先大的log buffer让原先大的事务运行,不时要在事务提交前写日志到磁盘,假使 ,假使 你有事务比如update、insert假使 delete 就是 的记录,让log buffer 足够大来节约磁盘I/O。

6. innodb_buffer_pool_size

这个参数主要缓存InnoDB表的索引、数据、插入数据时的缓冲。为InnoDN加速优化首要参数。一般让它等于你所有的innodb_log_buffer_size的大小就还并能 ,innodb_log_file_size要越大越好。 

7. innodb_buffer_pool_instances

InnoDB缓冲池拆分成的区域数量。对于数GB规模缓冲池的系统,通过减少不同应用应用程序读写缓冲页面的争用,将缓冲池拆分为不同实例促进改善并发性。

分库分表方案


现在加难度加入分库分表需求。

这个清况 建议取舍传统的土法子写原先迁移应用应用程序,读源数据库,通过顶端件写入目标库db1,db2,db3里

假使 源数据源设计的合理全部还并能 用全量+增量土法子实现。如下图所示

确实这个土法子很灵活,自行控制,但时要缺点,所有业务逻辑,分库分表方案,验证都时要手动编写

下次还并能 在不同的平台下使用。

现在业界比较常用的分库分表的顶端件有这个 :

  • proxy形,如:基于阿里开源的Cobar产品而研发的mycat, 时要部署另外服务器,作为分库分表的代理,对外服务,中含分库分表的配置信息,现在版本是mycat2.0。 
  • client形式,如当当出的sharding-jdbc,现在有京东金融进行维护,现在版本sharding-jdbc4.0开发中。是jar包,使用非常方便。我我个人所有所有趋向于Sharding-JDBC,这个土法子,不不额结构署,替换原有jdbc,DBA就是不改变原有的运维土法子,减轻了DBA的任务。

总结


1. 一定要取舍至少你的迁移工具,那么哪原先工具是最好的。

2. 数据的检验非常重要,有的已经 大家 迁过去很开心,校验时处于错误,这个已经 时要要重来。

3. 重复地迁移是很正常的,合乎每次迁移假使 时要很长时间,总会是有错误的,要做好再迁的心态

4. 迁移过程中的日志记录非常重要,一段出現故障,还并能 再疑问点已经 刚开始继续进行迁移。

本文由

数据和云

发布在

ITPUB

,转载此文请保持文章全部性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/05/20/1910/