作者：秦福朗
爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查。热爱 IT，喜欢在互联网里畅游，擅长摄影、厨艺，不会厨艺的 DBA 不是好司机，didi~
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
一、背景
MariaDB 的产生背景想必大家都知道，是由 MySQL 的创始人，在 MySQL 卖给 SUN 又被甲骨文收购后，以自己女儿名字命名的一款开源数据库。最初以其与 MySQL 的基本完全的兼容互通和免费开源受到大家的欢迎，甚至 CentOS7 都使用 MariaDB 替换了 MySQL 。所以关于 MariaDB 与 MySQL 的迁移的案例也较多，本公众号之前也有同事写过相关文章，有兴趣可以去看看，本篇写一下最近项目上遇到的迁移发生的问题及注意事项。
环境为 MariaDB 10.3 到 MySQL 5.7.25 。
二、简略操作过程
因 MariaDB 在5.5之后便不在跟随 MySQL 的版本号，所以5.5之后是以10.0.0为版本号起始，官方查询到 MariaDB 10.3 与 MySQL 5.7 是理论上可兼容的，项目操作者把 MariaDB 的 my.cnf 配置文件去掉了不存在 MySQL 中的部分参数，然后用此配置文件安装了 MySQL ，之后 mysqldump 了 MariaDB 的库表数据，导入到 MySQL中 （这是通常使用的迁移方式）。
三、导入数据报错
1、md5(uuid())
在导入过程中有报错信息如下：
从图中可看出导入过程中语法错误，MySQL 不识别 md5(uuid())，根据提示查看表结构：
可以看到主键列 instance_id 有个 default 属性，md5 函数嵌套 uuid 函数。在印象中没见过此种用法，遂以此为方向，去查看官方文档规定，如下：
-
MariaDB：
明确说明了，在10.2.1之后，default可以与表达式或函数一起使用。
-
MySQL：
可以看到 MySQL 中，default 子句中指定的默认值必须是文字常量，不能是表达式或函数。这里就解释了为什么会导入报错，MySQL 不支持 default 中有 md5(uuid())这种函数形式。
2、PAGE_CHECKSUM
从图中依旧可以看出是导入过程中有语法错误，MySQL 不识别“PAGE_CHECKSUM=1”，根据提示查看表结构：
可以看到 engine 为 Aria ，在 engine 的 default 的后面有此参数，查看 MariaDB 官方文档，如下：
可知，PAGE_CHECKSUM 只适用于 Aria 表，而与 MySQL 文档对比可知，Aria 引擎为 MariaDB 独有，MySQL 没有，所以 MySQL 也没有 PAGE_CHECKSUM 参数属性，所以此处会报错。
此 Aria 引擎是 MariaD B用来替换 Myisam 引擎的，甚至在10.4版本后连系统表都是此引擎，故在此之后的版本，更要注意该问题。
四、应用测试报错
应用测试执行 SQL 语句时报错如下：
从报错可知为比较经典的 select 后面查询的字段没有出现在 group by 中的例子，但 my.cnf 用的是 MariaDB 的，应该是没有变化才对，然后查看了 MySQL 的 sql_mode ：
可以看到 ONLY_FULL_GROUP_BY 出现在其中，这可以解释为什么会报错的原因，但此参数在 MariaDB 中查询却没有，且 sql_mode 参数没有存在于 my.cnf 文件中，那又是为什么，此时继续查看官方文档（真好东西）：
-
MySQL：
可以看到 MySQL 5.7 的 sql_mode 的默认值是包含 ONLY_FULL_GROUP_BY 参数的。
-
MariaDB：
在 MariaDB 中可以看到在10.2.4之后的 sql_mode 的默认值并不包含 ONLY_FULL_GROUP_BY 。
由此可以说明，sql_mode 没有配置在 my.cnf 文件中，部署了新的 MySQL 使用的便是 sql_mode 的默认值，所以此时 sql_mode 会包含 ONLY_FULL_GROUP_BY ，而业务程序 SQL 是以没有开启 ONLY_FULL_GROUP_BY 设计的，所以会在运行时产生报错。
修改了 sql_mode 之后，业务运行正常了。
五、结语
两个数据库的迁移，不是看看网上的文档或者官方文档提到的兼容与不兼容项，操作就稳如泰山了，迁移还是希望能在全面测试的基础上结合官方文档，尽量做到发现各种细节上的不一致，再去做正式的迁移，毕竟数据安全使用最重要。