Upgrade causes replication failure due to schema changes

[Dave]

Caution with this release it will break replication due to a known upgrade issue in upstream MySQL.

Given the critical nature of the CVE reports addressed in this release we immediately tested the upgrade on a non-production server taking a feed from production and the replication died looking it lost the master information.

Upstream bug report: http://bugs.mysql.com/bug.php?id=82765&thanks=3&notify=67

For information we upgrade the server from 5.7.13-6-log to 5.7.14-8-log and ran MySQL upgrade everything passed.

2016-09-21T18:40:09.534517Z 0 [ERROR] Info table has a problem with its key field(s). Table ‘mysql.slave_master_info’ expected field #23 to be ‘Channel_name’ but found ‘Tls_version’ instead.
2016-09-21T18:40:09.534537Z 0 [ERROR] Slave: Failed to create a channel from master info table repository.
2016-09-21T18:40:09.534565Z 0 [ERROR] Slave: Could not create channel list
2016-09-21T18:40:09.534572Z 0 [ERROR] Failed to create or recover replication info repositories.
2016-09-21T18:40:09.534576Z 0 [Note] Check error log for additional messages. You will not be able to start replication until the issue is resolved and the server restarted.
2016-09-21T18:40:09.553673Z 0 [ERROR] Incorrect definition of table performance_schema.replication_connection_status: expected column ‘RECEIVED_TRANSACTION_SET’ at position 7 to have type longtext, found type text.
2016-09-21T18:40:09.554945Z 0 [ERROR] Incorrect definition of table performance_schema.replication_group_member_stats: expected column ‘COUNT_TRANSACTIONS_ROWS_VALIDATING’ at position 6, found ‘COUNT_TRANSACTIONS_VALIDATING’.

There is a workaround on the bug report which does get replication flowing again if you are desperate.

[Dave (akxws32zf6g92mu3-dave)]

Further to this I have compared the MySQL schema for a server upgraded from a previous version I believe the server originated on 5.6 to a brand new install on 5.7.14 and there appear to be other changes to the replication tables although mySQL does not complain about them.

Below is a DB diff report

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

USE `mysql`;

/* Alter table in target */
ALTER TABLE `slave_master_info`
 CHANGE `Host` `Host` char(64) COLLATE utf8_bin NULL COMMENT 'The host name of the master.' after `Master_log_pos` ,
 CHANGE `Channel_name` `Channel_name` char(64) COLLATE utf8_general_ci NOT NULL COMMENT 'The channel on which the slave is connected to a source. Used in Multisource Replication' after `Enabled_auto_position` ,
 CHANGE `Tls_version` `Tls_version` text COLLATE utf8_bin NULL COMMENT 'Tls version' after `Channel_name` ;

/* Alter table in target */
ALTER TABLE `slave_relay_log_info`
 CHANGE `Channel_name` `Channel_name` char(64) COLLATE utf8_general_ci NOT NULL COMMENT 'The channel on which the slave is connected to a source. Used in Multisource Replication' after `Id` ;

/* Alter table in target */
ALTER TABLE `slave_worker_info`
 CHANGE `Channel_name` `Channel_name` char(64) COLLATE utf8_general_ci NOT NULL COMMENT 'The channel on which the slave is connected to a source. Used in Multisource Replication' after `Checkpoint_group_bitmap` ;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;