创新互联建站是一家网站设计公司，集创意、互联网应用、软件技术为一体的创意网站建设服务商，主营产品：
成都响应式网站建设、
品牌网站建设、
成都全网营销。我们专注企业品牌在网站中的整体树立，网络互动的体验，以及在手机等移动端的优质呈现。
成都网站设计、成都网站建设、移动互联产品、网络运营、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的一点简单尝试-创新互联
URL网址：
http://www.cdkjz.cn/article/dpdpee.html
