189 8069 5689

MySQL5.5复制升级到5.7的一点简单尝试-创新互联

MySQL 5.5复制升级到5.7的一点简单尝试

创新互联建站是一家网站设计公司,集创意、互联网应用、软件技术为一体的创意网站建设服务商,主营产品:成都响应式网站建设品牌网站建设成都全网营销。我们专注企业品牌在网站中的整体树立,网络互动的体验,以及在手机等移动端的优质呈现。成都网站设计、成都网站建设、移动互联产品、网络运营、VI设计、云产品.运维为核心业务。为用户提供一站式解决方案,我们深知市场的竞争激烈,认真对待每位客户,为客户提供赏析悦目的作品,网站的价值服务。

最近有个需求是升级MySQL 5.5到MySQL 5.7版本,为此我们想了一些方案,比如MySQL级联复制升级,这么考虑主要是基于版本的差异性,尽可能保持兼容。

还有逻辑备份恢复,物理备份恢复的方案,当然无论如何体现业务价值才能使得技术价值更有意义。所以我们希望通过升级版本来尽可能使得线上版本统一的同时,带给业务和DBA的几大福利就是online DDL,数据延迟降低,优化器的增强。

当然能不能升级也是拍脑袋想,原理上是可以的,但是实际上效果如何,没有验证心里还没有底。之前所做的比较多的是迁移式升级,通过逻辑备份恢复的方式,在数据量比较大的情况下,那种方式就有些吃力了。

所以我按照5.5,5.6,5.7的版本搭建了3套MySQL环境,然后以这3套环境为基础来实现级联复制。看看能够实现平滑的数据库升级。

数据库版本为5.5.19, 5.6.14, 5.7.19

为了保持尽可能保持兼容性和更好的功能,我计划使用如下的方式。

MySQL 5.5升级到MySQL 5.6使用偏移量的方式来同步

MySQL 5.6升级到MySQL 5.7使用GTID的方式来同步

然后说干就干,其实初始化环境这部分主要就是参数的兼容性,

比如下面的参数在5.5版本中就不存在,但是在5.6,5.7中存在,就需要根据需求来取舍。

171019 9:47:53 [ERROR] /usr/local/mysql_5.5/bin/mysqld: unknown variable 'master_info_repository=TABLE'

171019 9:47:53 [ERROR] Aborting

171019 9:48:48 [ERROR] /usr/local/mysql_5.5/bin/mysqld: unknown variable 'relay_log_info_repository=TABLE'

171019 9:49:12 [ERROR] /usr/local/mysql_5.5/bin/mysqld: unknown variable 'binlog_checksum=NONE'

关键就在于复制关系的配置了。

我先来验证5.6到5.7的配置关系,没想到启动slave后看到了如下的错误。

Last_SQL_Error: Column 1 of table 'mysql.user' cannot be converted from type 'char(48(bytes))' to type 'char(96(bytes) utf8)'

这类问题可以考虑修改参数来设置无损复制的程度,比如这样设置。

mysql> set global slave_type_conversions='ALL_LOSSY,ALL_NON_LOSSY';

接着就收到了另外一个错误。

Last_SQL_Error: Can't create conversion table for table 'mysql.user'

当然按照这个思路,我们可以完全抛弃mysql库,直接复制数据所在的库即可。

然后是配置5.5到5.6的环境,发现5.6配置了GTID,和偏移量的使用方式是有冲突的。

所以折衷下来的取舍就是先取消GTID的设置,统一使用偏移量,重新配置一下主从库,重置一下。重新建立主从关系即可。

经过简单的测试,5.5->5.6->5.7的方式通过偏移量的配置是可行的,无需设置复制的过滤配置,我做了DDL,DML的操作,重新配置了用户,这些操作都是可以的。

然后我更进一步,尝试配置5.5到5.7的复制关系,没想到也是可以的。

所以上面的简单尝试让我对复制有了一种新的认识,至少在这一点上数据确实能够完全同步过来,至于更为复杂的场景后续还要做更多的补充测试。


本文题目:MySQL5.5复制升级到5.7的一点简单尝试-创新互联
网页路径:http://cdxtjz.cn/article/dpdpee.html

其他资讯