MySQL 5.5復(fù)制升級到5.7的一點簡單嘗試

最近有個需求是升級MySQL 5.5到MySQL 5.7版本，為此我們想了一些方案，比如MySQL級聯(lián)復(fù)制升級，這么考慮主要是基于版本的差異性，盡可能保持兼容。

還有邏輯備份恢復(fù)，物理備份恢復(fù)的方案，當然無論如何體現(xiàn)業(yè)務(wù)價值才能使得技術(shù)價值更有意義。所以我們希望通過升級版本來盡可能使得線上版本統(tǒng)一的同時，帶給業(yè)務(wù)和DBA的幾大福利就是online DDL,數(shù)據(jù)延遲降低，優(yōu)化器的增強。

當然能不能升級也是拍腦袋想，原理上是可以的，但是實際上效果如何，沒有驗證心里還沒有底。之前所做的比較多的是遷移式升級，通過邏輯備份恢復(fù)的方式，在數(shù)據(jù)量比較大的情況下，那種方式就有些吃力了。

所以我按照5.5,5.6,5.7的版本搭建了3套MySQL環(huán)境，然后以這3套環(huán)境為基礎(chǔ)來實現(xiàn)級聯(lián)復(fù)制?？纯茨軌?qū)崿F(xiàn)平滑的數(shù)據(jù)庫升級。

數(shù)據(jù)庫版本為5.5.19, 5.6.14, 5.7.19

為了保持盡可能保持兼容性和更好的功能，我計劃使用如下的方式。

MySQL 5.5升級到MySQL 5.6使用偏移量的方式來同步

MySQL 5.6升級到MySQL 5.7使用GTID的方式來同步

然后說干就干，其實初始化環(huán)境這部分主要就是參數(shù)的兼容性，

比如下面的參數(shù)在5.5版本中就不存在，但是在5.6,5.7中存在，就需要根據(jù)需求來取舍。

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'

關(guān)鍵就在于復(fù)制關(guān)系的配置了。

我先來驗證5.6到5.7的配置關(guān)系，沒想到啟動slave后看到了如下的錯誤。

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

這類問題可以考慮修改參數(shù)來設(shè)置無損復(fù)制的程度，比如這樣設(shè)置。

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

接著就收到了另外一個錯誤。

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

當然按照這個思路，我們可以完全拋棄mysql庫，直接復(fù)制數(shù)據(jù)所在的庫即可。

然后是配置5.5到5.6的環(huán)境，發(fā)現(xiàn)5.6配置了GTID,和偏移量的使用方式是有沖突的。

所以折衷下來的取舍就是先取消GTID的設(shè)置，統(tǒng)一使用偏移量，重新配置一下主從庫，重置一下。重新建立主從關(guān)系即可。

經(jīng)過簡單的測試，5.5->5.6->5.7的方式通過偏移量的配置是可行的，無需設(shè)置復(fù)制的過濾配置，我做了DDL,DML的操作，重新配置了用戶，這些操作都是可以的。

然后我更進一步，嘗試配置5.5到5.7的復(fù)制關(guān)系，沒想到也是可以的。

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