MySQL 5.5復制升級到5.7的一點簡單嘗試

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

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