在线QQ客服：1922638

专业的SQL Server、MySQL数据库同步软件

在此博客中，我们将讨论在MySQL降级期间需要注意的事项。

之前，我曾写过博客MySQL升级最佳实践。除了升级MySQL版本外，有时还需要降级。在降级MySQL时，支持两种降级方法:

就地降级:在这种方法中，您使用现有的数据目录并替换MySQL二进制文件，然后执行。同一发行系列中支持这种类型的降级。例如，从5.7.12升级到5.7.10时支持就地降级。

SQL转储降级: A＆nbsp; SQL转储是另一种降级方法，也称为” 逻辑降级“。此方法涉及所有数据库的备份。使用mysqldump程序创建表。您还可以使用mydumper进行并行备份以缩短备份时间，然后替换MySQL二进制文件并将转储还原到降级的MySQL版本中。然后使用mysql_upgrade程序完成降级过程。在同一发行系列中以及不同发行级别之间都支持这种降级。例如，从5.6降级到5.5或从5.7降级到5.6或5.5

降级之前，您需要了解一些可能会影响该过程的因素。我将在这里列出一些重要的事情。对于影响降级过程的所有更改，您应该检查手册。另外，建议查看要降级的特定版本的发行说明，以免出现任何意外情况。

在MySQL 5.6中，relay-log.info文件包含行数和复制延迟值。这些值包含的文件格式与以前的MySQL版本不同。如果您在复制设置中降级到5.6以下，则旧服务器将不会读取该文件格式。要在有问题的从站上更正此问题，您需要在编辑器中修改relay-log.info，以删除包含行数的初始行。

通过“In-Place”方法从5.6降级到较早版本。由于时间类型的磁盘格式不同，MySQL 5.5可能会引起一些问题。基本上，如果在5.6上创建或更改了包含TIME，DATETIME或TIMESTAMP列的表，则不能在5.5上使用这些表。将版本从5.6降级到5.5的推荐方法是使用mysqldump的”逻辑降级”方法。

您可以使用下面的查询来确定可能受此问题影响的表和列。其中一些是数据库中的系统表，这意味着MySQL是您需要转储/还原的数据库之一。

在复制环境中，建议您首先升级/降级从属。我试图通过逻辑降级将复制层次结构中的从属服务器之一从Percona Server 5.6降级到Percona Server 5.5，如下所示:

此时，Percona Server 5.6降级为Percona Server 5.5。现在，让我们尝试将5.6实例中的备份还原到5.5实例中。

分析了结果之后，我发现在备份过程中，在少数MySQL系统表中附加了STATS_PERSISTENT。还原期间失败，因为在MySQL 5.5中innodb_stats_persistent不可用。我发现此报告的错误验证了此问题。

要解决此问题，您需要将MySQL用户授权与应用程序数据库分开备份:来自Percona Toolkit的pt-show-grants可以解决！

从Percona Server 5.6从站:

并在Percona Server 5.5从属服务器上还原:

请记住，不支持从新的主要版本到旧的主要MySQL版本(例如5.6主版本和5.5副本)的复制，通常不建议这样做。复制失败，因为从MySQL 5.6.6开始，新选项默认为。由于该选项在MySQL 5.5中不存在，因此副本无法处理来自主服务器的校验和。反之，CRC(循环冗余校验和)失败，因为二进制日志采用5.6之前的格式且没有校验和信息。您需要在MySQL主服务器上设置为NONE。

这将在5.6主服务器的5.5从服务器上恢复复制。我建议在[mysqld]部分下的my.cnf中进行设置，以使此更改在主服务器5.6的重新引导期间持续存在。

总而言之，通过”逻辑转储”方法降级需要您排除转储/还原MySQL系统数据库，并在＆nbsp;的帮助下仅转储用户授权。恢复数据库用户和特权。另外，从5.6版降级到较旧的版本(例如5.5或5.1)时，您需要使binlog_checksum兼容(即NULL)。与此同时，您需要确保启用binlog_rows_query_log_events并将binlog_row_image设置为FULL。另外，从5.6版复制到5.5版时，不支持基于GTID的复制，您需要在5.6中设置gtid_mode = OFF。所有这些变量都应在5.6母版上正确设置。有关更多详细信息，请查阅手册。

MySQL降级是对升级的逆转，可能会很痛苦。如果在没有适当测试的情况下进行升级，则可能有必要。降级的原因之一是，如果您发现应用程序出现故障，MySQL崩溃或升级后的性能未达到预期水平。