从迁移方案的落地、迁移前准备、N次迁移演练、回归测试、性能调优整整用了四个月左右的时间（固然在此期间还包括其余项目及平常操做耗费工时）。正式迁移到迁移成功、以及上线开服后性能稳定这些操做已通过去了一个多月时间。因为异构迁移在业界是一个较为困难繁琐的问题，因此通过这么久的沉淀，今天给你们复盘并分享一下整个迁移流程，从前期方案、到最后迁移成功的整个流程，但愿给对 ORACLE TO MYSQL 异构迁移流程不清晰的同窗，一点思路！html

目录java

1、迁移起因mysql

3、迁移方案落地github

1.协同高层肯定项目目标web

2.制定迁移计划sql

4、迁移工具选型（含功能实现原理）数据库

（1）SQL LOAD编程

（2）OGG缓存

1.oracle与mysql数据类型转换详情

（3）Trigger、存储过程、package

（8）分区表（Partitioned table）

innodb_flush_log_at_trx_commit

sync_binlog

max_allowed_packet

innodb_log_file_size

innodb_log_buffer_size

innodb_buffer_pool_size

innodb_buffer_pool_instances

1、迁移起因

“去O”，是近些年来一直很火的一个话题。但2019年，也许有着更加特殊的意义。随着国家监管要求、外部环境变化、国产数据库兴起等多种因素，相信今年会是“去O”井喷发展的一年。去O更详细的说是去IOE。

“去IOE”：是阿里巴巴造出的概念。其本意是，在阿里巴巴的IT架构中，去掉IBM的小型机、Oracle数据库、EMC存储设备，代之以本身在开源软件基础上开发的系统。（如公有云厂商产品RDS、CDB等）

2、迁移目标

迁移先后结构一致
迁移先后数据一致
迁移完成上线后——业务运行——性能稳定
最终实现oracle数据向mysql数据库的平滑过渡

3、迁移方案落地

1.协同高层肯定项目目标

这里须要肯定的包括迁移源端（如哪几个oracle数据库）、目标端（如迁移到RDS For MySQL、或者机房自建MySQL）

2.制定迁移计划

这里的迁移计划指的是整个迁移过程的总体排期，包含：

前期的迁移工具选型
测试环境搭建
迁移工具测试
对象兼容性统计、对比、改写
全量数据校验方案
压力测试
屡次迁移演练、产出迁移方案
- （该方案指的是迁移的详细操做步骤，方案中的操做步骤建议补充到尽量详细，防止迁移当天因为任何缘由出现操做步骤遗忘等任何故障，固然该方案能够留做下次迁移参考，以及经验总结）
正式迁移
上线后性能调优

那么下面就按照该部分迁移计划中的步骤，叙述详细内容及关键点

4、迁移工具选型（含功能实现原理）

你们再迁移前，能够了解到，迁移涉及到结构迁移和数据迁移，那么在迁移工具选型的时候，须要考虑的几点：

该工具能够迁移结构、数据仍是两者
该工具迁移先后数据库对象的兼容性
使用该工具迁移后改写工做量
是否能够作全量数据校验

这里简单聊几个目前常见的oracle迁移mysql的工具及与原理：

（1）SQL LOAD

这里使用的是powerdesigner，使用该工具迁移结构，首先在plsql中将oracle数据库中的表结构导出csv/sql，使用powerdesigner加载导出的oracle结构语法转换为mysql结构语法，转换后的结构语法存在大量改写：

表注释、列注释所有保留
索引数量没有丢失，可是部分惟一索引被修改成普通索引（源库多个索引且所有为惟一索引，这种状况转换后被修改成普通索引）
int数据类型所有转换为numeric，float数据类型没有转换，其余同DTS
保留了源库的default默认值，没有增长default null
分区表所有丢失
存储过程所有丢失
转换后timestamp类型须要转换其余类型才能导入（测试期间修改成datetime），float没有转换，须要改成double才能导入存在Specified key was too long; max key length is 3072 bytes，须要修改列长度

（2）OGG

Oracle GoldenGate（OGG）能够在多样化和复杂的 IT 架构中实现实时事务更改数据捕获、转换和发送；其中，数据处理与交换以事务为单位，并支持异构平台，例如：DB2，MSSQL等

Oracle GoldenGate 数据复制过程以下：
利用抽取进程(Extract Process)在源端数据库中读取Online Redo Log或者Archive Log，而后进行解析，只提取其中数据的变化信息，好比DML操做——增、删、改操做，将抽取的信息转换为GoldenGate自定义的中间格式存放在队列文件(trail file)中。再利用传输进程将队列文件(trail file)经过TCP/IP传送到目标系统。
目标端有一个进程叫Server Collector，这个进程接受了从源端传输过来的数据变化信息，把信息缓存到GoldenGate 队列文件(trail file)当中，等待目标端的复制进程读取数据。
GoldenGate 复制进程(replicat process)从队列文件(trail file)中读取数据变化信息，并建立对应的SQL语句，经过数据库的本地接口执行，提交到目标端数据库，提交成功后更新本身的检查点，记录已经完成复制的位置，数据的复制过程最终完成。

但OGG有一个缺陷，作不到全量数据对比！

（3）KETTLE

Kettle是一款国外开源的ETL工具，能够在Windows、Linux、Unix上运行，纯java编写。该工具使用前须要作代码改造，以适用现有的业务场景。

（4）DATAX

DataX 是阿里巴巴集团内被普遍使用的离线数据同步工具/平台，实现包括 MySQL、Oracle、HDFS、Hive、OceanBase、HBase、OTS、ODPS 等各类异构数据源之间高效的数据同步功能。DataX采用了框架 + 插件的模式，目前已开源，代码托管在github。

DATAX底层原理：

DataX自己做为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为Reader/Writer插件，归入到整个同步框架中。
Reader：Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework。
Writer： Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端。
Framework：Framework用于链接reader和writer，做为二者的数据传输通道，并处理缓冲，流控，并发，数据转换等核心技术问题。

（5）ADAM STUDIO

阿里云官方描述：ADAM推出Oracle数据库平滑迁云解决方案，覆盖Oracle迁移的全生命周期，包括数据库与应用评估（兼容性、关联关系、性能、风险点、应用改造点）、转换（转换不兼容点、引擎特征优化转换）、结构迁移、数据迁移、一致性校验、SQL仿真回放、割接、优化。

这里简单聊一下在测试过程当中，对该工具的总结：

1.首先该工具须要搭建一套adam环境，部署一套mysql数据库存储迁移数据，迁移操做以web界面的形式呈现，操做相对较为简单

2.ADAM有一个我的认为很是实用的功能，在分析完结构对象在源端与目标端迁移先后兼容性后，会出一份兼容性报告，报告较为详细，包含了全部的对象的个数，不兼容对象的建立语句（如sequence、存储过程、merge into等），甚至包含这些对象的一些兼容性改写方案，对于没法兼容的对象，也有作标记，便于DBA及研发同窗核对。

（6）DTS

数据传输服务DTS（Data Transmission Service）是阿里云提供的实时数据流服务，支持RDBMS、NoSQL、OLAP等。
DTS自身能够实现结构迁移和数据迁移，结合迁移改造工做量、数据验证几个方案，测试比对各个迁移工具，最终本次oracle迁移mysql使用了DTS工具。
DTS工具能够实现数据验证功能，可是DTS仅能含主键或者惟一键约束的表，同时仅验证的是主键这一列的内容一致，DTS即认为数据一致，仍然作不到全量的数据验证

关于DTS同步数据的原理能够类比于OGG，给你们放一张图，如须要深刻了解，能够看本人的这篇博客【阿里云DTS原理】

https://blog.csdn.net/qq_44714603/article/details/105205150

这里补充几个在DTS在迁移过程当中须要改造的几个点：

Default 为Sysdate须要转换为now()，（测试期间，改成CURRENT_TIMESTAMP，这二者是同样的。）
存在Specified key was too long; max key length is 3072 bytes，须要修改列长度
补齐丢失的惟一索引
分区表所有不兼容，须要改写
存储过程不兼容，须要改写
外键约束不兼容，须要改写
（mysql中数据库对象不如oracle的多，因此针对自家oracle数据库中的对象，若是oracle中的对象在mysql中没有对应的，通常须要改写）

5、对象兼容性改写

对于对象兼容性这部分，你们须要兼顾人员分配。

相关数据库对象统计，研发与DBA均可以作，这里建议DBA作，由于DBA对数据库的权限相对较高，建议这里DBA与研发协做，互相比对对象统计结。
相关不兼容的数据库对象改写，这里建议研发同窗执行，DBA协助技术支持。其实改写SQL是DBA的基本技能，这里建议研发同窗改写，DBA同窗协助的缘由是，在一个项目人员细分较为明确的场景下，每每研发同窗对业务更加了解，想存储过程不兼容的改写方案，更加建议研发同窗结合真实的业务场景改写SQL，而DBA同窗价值更应该体如今校验SQL语法以及SQL性能方面
相关迁移改写后SQL执行问题，须要拆分SQL语句中的DDL语句与DML语句，测试环境能够给研发放开数据库权限，可是线上环境务必控制好数据库权限，对于DDL操做及部分DML操做务必要DBA操做，这里主要关系到DBA与研发同窗不一样职能的问题，一方面方便DBA管理数据库对象，另外DBA更擅长对SQL的性能评估，防止随意操做故障发生！

1.oracle与mysql数据类型转换详情

2.大小写敏感参数

咱们较为了解的是表结构大小写敏感参数lower_case_table_names，可是数据内容区分大小写敏感参数（collate）参数使用可能较少，因为oracle默认是区分数据大小写的，为达到迁移先后一致性，因此咱们须要对这个参数作显式修改。（该参数很是关键！！）

Collate参数在官方文档中的解释：https://dev.mysql.com/doc/refman/5.7/en/charset-binary-collations.html

因为迁移过程涉及屡次数据导入导出，所以使用如下语句可防止乱码

set names utf8 collate utf8_bin;

编码为utf8且校验规则为数据内容大小写敏感

3.数据库对象不兼容改写方案

（1）view

在MySQL里view是不能够嵌套子查询的：

create view v_ceshi as select * from (select * from test) t;

ERROR 1349 (HY000): View's SELECT contains a subquery in the FROM clause

解决方法就是view的嵌套：

create view v_test as select * from test;

Query OK, 0 rows affected (0.02 sec)

create view v_ceshi as select * from v_test;

Query OK, 0 rows affected (0.00 sec)

（2）物化视图

物化视图用于预先计算并保存表链接或汇集等耗时较多的操做结果，这样在执行查询时，就能够避免进行这些耗时的操做，而从快速获得结果。可是MySQL里没有这个功能。经过事件调度和存储过程模拟物化视图，实现的难点在于更新物化视图，若是要求实时性高的更新，而且表太大的话，可能会有一些性能问题。

（3）Trigger、存储过程、package

1）Oracle建立触发器时容许or，可是MySQL不容许。因此迁移时若是有须要写两个。

2）两种数据库定义变量的位置不一样，并且MySQL里不支持%type。这个在Oracle中用得太频繁了，是个好习惯。

3）elseif的逻辑分支语法不一样，而且MySQL里也没有for循环。

4）在MySQL中不能够返回cursor，而且声明时就要赋对象。

5）Oracle用包来把存储过程分门别类，并且在package里能够定义公共的变量/类型，既方便了编程，又减小了服务器的编译开销。可MySQL里根本没有这个概念。因此MySQL的函数也不能够重载。

6）预约义函数。MySQL里没有to_char() to_date()之类的函数，也并非全部的Oracle都是好的，就像substring()和load_file()这样的函数，MySQL有，Oracle却没有。

7）MySQL里可使用set和=号给变量赋值，但不可使用：=。并且在MySQL里没 || 来拼接字符串。

8）MySQL的注释必需要求-- 和内容之间有一个空格。

9）MySQL存储过程当中只能使用leave退出当前存储过程，不可使用return。

10）MySQL异常对象不一样，MySQL一样的能够定义和处理异常，但对象名字不同。

业务SQL中若是有下面的函数使用，须要改写成mysql支持的：对于mysql不建议使用存储过程

oracle与mysql之经常使用函数的区别：

nvl(xx, 0) ==> coalesce(xx, 0)

说明：返回第一个非空值。

to_char(xx) ==> cast(xx as char)

说明：转换为char类型

to_char(xx,'yyyymmdd') ==> date_format(xx, '%Y%m%d')

说明：日期格式化，date_format具体参数查询文档

to_char(xx,'yyyyq') ==> concat(date_format(xx, '%Y'), quarter(xx))

说明：mysql date_format没法格式化季度，须要借助quarter函数

to_number(xx) ==> cast(xx as unsigned integer)

说明：转换为数字类类型，unsigned integer为无符号整数

sysdate ==> now()或者用current_timestamp代替，因为oracle在TIMESTAMP是有时区信息，这块改为mysql后不带时区的，因此对于高精度这块mysql不能彻底解决。

说明：获取当前时间

decode(cond, val1, res1, default) ==> case when cond = val1 then res1 else default end

说明：根据cond的值返回不一样结果

trunc(xx, 2) ==> convert(xx, decimal(6,2))

说明：保留2位小数

wm_concat(xx) ==> group_concat(xx)

说明：列转行

over() ==> 无

说明： mysql没有开窗函数，须要代码实现

oracle与mysql之语法的区别：

connect by…start with ==> 无

说明： mysql没有递归查询，须要代码实现

rownum ==> limit

说明：分页

'a'||'b' ==> concat('a', 'b')

说明：字符串拼接

select xx from (select xx from a) ==> select xx from (select xx from a) t1

说明：from后的子查询必须有别名

nulls last ==> 无

说明：mysql排序时，认为null是最小值，升序时排在最前面，降序时排在末尾

group by (a, b) ==> group by a, b

说明：mysql group by 字段不能加括号

begin end; ==> begin; commit;

说明：mysql事务控制begin后须要加分号执行，提交使用commit。P.S.禁止在sql中进行事务控制

select 1, 1 from dual

union

select 1, 1 from dual

==>

select 1 as a, 1 as b from dual

union

select 1 as a, 1 as b from dual

说明：mysql的union查询的每一个字段名必须不一样

null值在oracle和mysql中的差别

说明：在oracle和mysql中null都表示为空的意思，可是二者之间仍是有差别的，oracle中null与''是等价的，可是在mysql中null与''则不是等价的，在不一样的数据库中，''与null是有差别的。oracle中的''与 null是等价的，可是咱们在写sql时不能使用''=null这种方式，只能是'' is null这种方式；而在mysql中''与not null是等价的，同理咱们在写sql时不能使用'' <> null这种方式，只能用'' is not null。

Oracle中date类型对应 MySQL 时间类型以及空值的处理

Oracle数据库的date类型和mysql的date类型是不同的，Oracle为yyyy-mm-dd hh:mi:ss和mysql中的datetime类型匹配，而mysql 为 yyyy-mm 。当在存在空值的时候，mysql的time 类型可使用0零来插入，而date，datetime，timestamp可使用null 来插入，可是timestamp即便为null，也会默认插入当前时间戳。

（4）分页语句

MySQL中使用的是limit关键字，但在Oracle中使用的是rownum关键字。因此每有的和分页相关的语句都要进行调整。

（5）JOIN

若是你的SQL里有大量的（+），这绝对是一个很头疼的问题。须要改写。

（6）group by语句

Oracle里在查询字段出现的列必定要出如今group by后面，而MySQL里却不用。只是这样出来的结果可能并非预期的结果。形成MySQL这种奇怪的特性的归因于sql_mode的设置，一会会详细说一下sql_mode。不过从Oracle迁移到MySQL的过程当中，group by语句不会有跑不通的状况，反过来迁移可能就须要很长的时间来调整了。

（7）bitmap位图索引

在Oracle里能够利用bitmap来实现布隆过滤，进行一些查询的优化，同时这一特性也为Oracle一些数据仓库相关的操做提供了很好的支持，但在MySQL里没有这种索引，因此之前在Oracle里利于bitmap进行优化的SQL可能在MySQL会有很大的性能问题。

目前也没有什么较好的解决方案，能够尝试着建btree的索引看是否能解决问题。要求MySQL提供bitmap索引在MySQL的bug库里被人看成一个中级的问题提交了上去，不过至今仍是没有解决。

（8）分区表（Partitioned table）

须要特殊处理，与Oracle的作法不一样，MySQL会将分区键视做主键和惟一键的一部分。为确保不对应用逻辑和查询产生影响，必须用恰当的分区键从新定义目标架构。

（9）角色

MySQL8.0之前也没有role的对象。在迁移过程当中若是遇到的角色则是须要拼SQL来从新赋权。不过MySQL更好的一点是MySQL的用户与主机有关。

（10）表情和特殊字符

在Oracle里咱们通常都选择AL32UTF8的字符集，已经能够支付生僻字和emoji的表情了，由于在迁移的时候有的表包含了大量的表情字符，在MySQL里设置了为utf8却不行，导过去以后全部的都是问号，后来改为了utf8mb4才解决问题，因此推荐默认就把全部的DB都装成utf8mb4吧。

Oracle和MySQL差别远远不止这些，像闪回、AWR这些有不少，这里只谈一些和迁移工做相关的。

6、全量数据校验方案

前面咱们在迁移工具选型的时候，就了解到，目前不少迁移工具是作不到数据校验的，甚至少部分能够校验的迁移工具也仅仅是作针对约束列的数据校验，因此，咱们这里采用开发自主脚本实现全量的数据校验

1.全量数据验证逻辑流图

2.全量数据验证脚本逻辑

利用sqluldr2和mysqluldr2工具，按照主键列排序导出数据（不含主键的表，按照惟一值最多的几列排序），对比文件MD5
因为第一次导出数据文件制定字符集是utf8，可能会出现数据截断现象，因此对于第一次MD5不一致的表，从新导出，再次验证MD5
两次MD5都不一致，diff文件内容，批处理因为排序问题致使diff不一致的结果，互相循环过滤diff结果中的“>”和“<”行，行数是否大于1，若是大于1，意味该行在表中存在彻底重复的行，则校验该行内容在oracle和mysql数据文件中的行数是否一致，最终脚本输出为数据不一致的表，以及表中不一致的行内容。

从上面的脚本逻辑中能够看到，该自主研发脚本是作不到动态验证数据的，因此要求必须在停服后，导出静态数据，对比两端，因此为了节省更多的时间，数据验证脚本这步能够采用并行导出数据的方案。

3.数据验证注意事项

迁移先后全量数据的一致性是迁移的基本原则，也是难点，请读者务必关注这部分，本次迁移过程当中，过于考虑数据验证逻辑是否有疏漏而忽略了少部分的代码执行结果是否与预期一致（代码体现为grep配合awk出现数据截断，致使不一致的数据未验证出来），后期项目主备负责人验证代码时修复，不然将酿成大错，此处须要特别注意！

7、压力测试

这里在压力测试的时候，研发更加熟悉业务，DBA更加擅长数据库性能优化，因此该步骤建议DBA协助研发同窗执行测试过程

8、迁移演练

注意事项：

在时间容许的状况下，建议尽量多的作几回迁移演练，屡次演练将可能出现的问题所有发掘出来
同时将全部的演练问题、解决方案及其余经验输出到文档中，以便后续查阅
各个步骤的操做时间须要记录，以便后续结合研发侧须要的时间整合并肯定一个停服时间
因为使用第三方迁移工具，考虑到数据安全性，这里建议正式迁移当天使用内网专线进行迁移防止脱库！！

9、正式迁移

在DBA迁移演练和研发测试能够验收后，在业务低峰期的范围内肯定停服时间进行正式迁移

因为前期迁移演练次数较多，出现的问题尽量记录在迁移方案中，故迁移当前按照迁移方案执行迁移便可。

这里只简单描述一下正式迁移期间，出现重复数据的处理方案

重复数据处理方案

1）.重复数据出现缘由：

迁移工具在重放update时，是delete+insert操做，可是delete操做丢失，insert成功，导出重复数据的出现

2）.解决方案

1.添加主键、惟一键

2.Group by或者distinct去重导出临时表，rename原表为test_bak，在rename临时表为test

（1）全部列去重

--distinct

insert into tb_actv_openid_cn_bind(APP,ACTV,VERSION,OPENID,CN,CN_MASTER,ACCESS_DATE,STATUS) select distinct * from tb_actv_openid_cn_bind_bak;

--group by

insert into tb_actv_openid_cn_bind(APP,ACTV,VERSION,OPENID,CN,CN_MASTER,ACCESS_DATE,STATUS) select * from tb_actv_openid_cn_bind_bak group by APP,ACTV,VERSION,OPENID,CN,CN_MASTER,ACCESS_DATE,STATUS;

（2）部分列去重

--group by

insert into tb_actv_openid_cn_bind(APP,ACTV,VERSION,OPENID,CN,CN_MASTER,ACCESS_DATE,STATUS) select * from tb_actv_openid_cn_bind_bak group by APP,ACTV,VERSION,OPENID,CN,CN_MASTER,ACCESS_DATE,STATUS;

--

select * from table group by col1,col3;

对于标准的sql_mode：

对于不标准的sql_mode：

迁移当天：

-- Select count(*) from t1 group by col1,col2,col3;

--Select count(*) from t1 group by col1,col3;

两者相等的状况下，说明col1,col3这两列没有重复数据，在阿里云以group by col1,col3导出，再导入到腾讯云（不丢失数据），再创建组合惟一索引

讨论：

若是上面状况，两者不等，说明col1,col3这两列有重复数据，如何处理？

1.组合惟一索引增长一列col2，以肯定惟一性

2.前提：若是容许删除col1,col3重复，col2不重复的行（保留惟一键重复的首行）

（1）那么能够经过增长一列自增主键列，保留重复行主键号最小的一行进行删除（删除效率很低）

delete from sub_dj_enroll_sign

  where (app, actv, version, cn_master, sign_date_str) in

        (select *

           from (select app, actv, version, cn_master, sign_date_str

                   from sub_dj_enroll_sign

                  group by app, actv, version, cn_master, sign_date_str

                 having count(*) > 1) temp1)

    and id not in

        (select *

           from (select min(id)

                   from sub_dj_enroll_sign

                  group by app, actv, version, cn_master, sign_date_str

                 having count(*) > 1) temp2);

（2）逻辑上拼主键，having出来的都是重复数据，而后如今有了重复数据的起始主键值a，和重复行数b，要删除的主键值就是(a+1~a+b-1)这个段，然id等于这部分，直接删。（若是重复行，主键号不连续，该方法不可行）

10、迁移后性能调优

DBA在正式迁移完数据后，须要协助研发作最终的回归测试，测试验证经过后，启服上线！

1.上线后持续关注目标端数据库性能

如出现慢查询等致使CPU或IO骤升骤减的状况，请及时优化SQL

2.参数调优

咱们能够在导入数据的时候预先的修改一些参数，来获取最大性能的处理，好比能够把自适应hash关掉，Doublewrite关掉，而后调整缓存区，log文件的大小，把能变大的都变大，把能关的都关掉来获取最大的性能，咱们接下来讲几个经常使用的：

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%的“每秒”。

sync_binlog

sync_binlog 的默认值是0，像操做系统刷其它文件的机制同样，MySQL不会同步到磁盘中去，而是依赖操做系统来刷新binary log。

当sync_binlog =N (N>0) ，MySQL 在每写N次二进制日志binary log时，会使用fdatasync()函数将它的写二进制日志binary log同步到磁盘中去。

注：若是启用了autocommit，那么每个语句statement就会有一次写操做；不然每一个事务对应一个写操做。

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

innodb_log_file_size

InnoDB日志文件太大，会影响MySQL崩溃恢复的时间，过小会增长IO负担，因此咱们要调整合适的日志大小。在数据导入时先把这个值调大一点。避免无谓的buffer pool的flush操做。但也不能把 innodb_log_file_size开得太大，会明显增长 InnoDB的log写入操做，并且会形成操做系统须要更多的Disk Cache开销。

innodb_log_buffer_size

InnoDB用于将日志文件写入磁盘时的缓冲区大小字节数。为了实现较高写入吞吐率，可增大该参数的默认值。一个大的log buffer让一个大的事务运行，不须要在事务提交前写日志到磁盘，所以，若是你有事务好比update、insert或者delete 不少的记录，让log buffer 足够大来节约磁盘I/O。

innodb_buffer_pool_size

这个参数主要缓存InnoDB表的索引、数据、插入数据时的缓冲。为InnoDN加速优化首要参数。通常让它等于你全部的innodb_log_buffer_size的大小就能够，

innodb_log_file_size要越大越好。

innodb_buffer_pool_instances

InnoDB缓冲池拆分红的区域数量。对于数GB规模缓冲池的系统，经过减小不一样线程读写缓冲页面的争用，将缓冲池拆分为不一样实例有助于改善并发性。

至此，整个迁移流程执行完成，固然，文章也告一段落了，码了一成天，但愿感兴趣的同窗评论区讨论口嗨！

喜欢的同窗，点赞关注哦，感谢支持！！！

点赞 2
收藏
分享
- 文章举报

黑领灵灵妖

发布了34 篇原创文章 · 获赞 78 · 访问量 12万+

私信关注

oracle异构迁移mysql方案实施（含原理）——已迁移成功

1、迁移起因

2、迁移目标

3、迁移方案落地

1.协同高层肯定项目目标

2.制定迁移计划

4、迁移工具选型（含功能实现原理）

（1）SQL LOAD

（2）OGG

（3）KETTLE

（4）DATAX

（5）ADAM STUDIO

（6）DTS

5、对象兼容性改写

1.oracle与mysql数据类型转换详情

2.大小写敏感参数

3.数据库对象不兼容改写方案

（1）view

（2）物化视图

（3）Trigger、存储过程、package

（4）分页语句

（5）JOIN

（6）group by语句

（7）bitmap位图索引

（8）分区表（Partitioned table）

（9）角色

（10）表情和特殊字符

6、全量数据校验方案

1.全量数据验证逻辑流图

2.全量数据验证脚本逻辑

3.数据验证注意事项

7、压力测试

8、迁移演练

9、正式迁移

重复数据处理方案

1）.重复数据出现缘由：

2）.解决方案

10、迁移后性能调优

1.上线后持续关注目标端数据库性能

2.参数调优

innodb_flush_log_at_trx_commit

sync_binlog

max_allowed_packet

innodb_log_file_size

innodb_log_buffer_size

innodb_buffer_pool_size

innodb_buffer_pool_instances