最近有个需求是升级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的复制关系，没想到也是可以的。
所以上面的简单尝试让我对复制有了一种新的认识，至少在这一点上数据确实能够完全同步过来，至于更为复杂的场景后续还要做更多的补充测试。
