最近有個需求是升級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的複製關係，沒想到也是可以的。

所以上面的簡單嘗試讓我對複製有了一種新的認識，至少在這一點上資料確實能夠完全同步過來，至於更為複雜的場景後續還要做更多的補充測試。

大家有問題也歡迎提一下。