数据库供应商通常每个月都会发布一些有bug /安全性修补程序的补丁，我们为什么要关心这些？因为，新的版本可能对安全漏洞或黑客入侵系统进行修复，所以除非不关注安全性能，否则，您会希望在您的系统安装上最新的安全修补程序。其中MySQL主要版本比较少见，通常是次版本升级，但是他们可能会带来一些重要的功能，使得升级是值得的。

在这篇博文中，我们将介绍DBA的一个最基本的任务—次要版本数据库升级和主要数据库升级。

MySQL升级

有两个MySQL官方版本已经不再关注和修复，是因为是在oracle收购MySQL之前的发行版本。它们分别发生在2013年12月4日的MySQL 5.1与2012年1月9日的MySQL5.0之前。在GA发布8年后的2018年，MySQL5.5也发生过这种情况。这意味着对于MySQL 5.0和MySQL 5.1，用户无法依靠官方的修复—即使是严重的安全漏洞。这也是您需要将MySQL升级到更新版本的原因。

友情建议：推荐使用MySQL5.6最新或者MySQL5.7.20之后的版本。叶师傅的朋友圈提过“关于MySQL5.7.20之前版本存在的bug”。

但是，您不会只处理主要的版本升级，而是在工作中更经常地升级次要版本，例如5.6.x - > 5.6.y. 最有可能的是，最新版本会为影响工作负载的错误进行一些修复，但也可能是其他原因。 在执行主版本和次版本升级方式方面存在显着差异。

友情建议：关于版本的子版本升级，尤其是成熟的版本，大多数是对bug的修复。可以根据发行说明来判断是否要升级，不过不建议使用子版本低于20的。

准备工作

在您考虑执行升级之前，您需要决定进行哪种测试。理想情况下，您有一个测试/开发环境，可以为常规版本进行测试。如果这样的话，进行升级前测试的最好方法就是使用新的MySQL版本来构建临时环境的数据库层。一旦完成，您可以继续进行一组常规测试。更多更好—你不仅要关注“xx功能/xxbug”方面，还要关注性能。

在数据库方面，你也可以做一些通用的测试。为此，您需要一个慢日志格式的查询列表。然后，可以使用pt-upgrade在旧版本和新版本的MySQL上运行它们，比较响应时间和结果集。在过去，我们已经注意到，pt-upgrade会返回很多误报—它可能会将查询报告为慢，而事实上，两个版本的查询都是完全正确的。为此，您可能需要引入一些额外的完整性检查—解析pt-upgrade输出，获取报告的慢速查询，再次在服务器上执行这些查询，并再次比较结果。你需要记住，你应该以同样的方式连接到新旧数据库服务器（套接字连接将比TCP更快）。

这种通用测试的典型结果是执行计划发生变化的查询—通常添加一些索引或强制优化器选择正确的查询就足够了。您还可以看到结果集中存在差异的查询—这很可能是查询中缺少显式ORDER BY的结果，如果不对其进行排序，则无法依赖行的排序方式。

友情建议：关于升级操作之前强烈要求备份。个人认为一个DBA除了要考虑性能，更多的是考虑稳定，安全。

次要版本升级

小升级相对容易执行—大多数情况下，您只需要使用发行版的软件包管理器来安装新版本即可。一旦你这样做，你需要确保升级后MySQL已经启动，然后你应该运行mysql_upgrade脚本。该脚本遍历数据库中的表，并确保它们与当前版本兼容。如果有需要，它也可能修复你的系统表。

显然，安装新版本的软件包需要停止服务。因此您需要规划升级过程。如果使用Galera Cluster或MySQL复制，它可能会略有不同。

MySQL复制

当我们处理MySQL复制时，升级过程相当简单。您需要通过升级slave，在执行升级所需的时间内将其停止运行（如果一切顺利，不超过几分钟的停机时间，即仅需很短的时间）。为此，您可能需要在代理配置中进行一些临时更改，以确保流量不会被路由到正在维护的slave设备。这里很难给出任何细节，因为这取决于你的设置。在某些情况下，甚至不需要任何更改，因为代理可以自行适应拓扑更改，并检测哪个节点可用，哪个不可用。顺便说一句，这就是你应该确定如何配置你的代理。

一旦每个从机都被更新，您需要执行一个计划的故障切换。我们在较早的博客文章中讨论了这个过程。该过程也可能取决于您的设置。如果你有自动化的工具（例如MHA），它不一定是手动的。一旦选出新的主服务器并完成故障切换，则应该对旧主服务器执行升级，此时应该将新服务器从新主服务器上删除。这将结束MySQL复制设置的次要版本升级。

友情建议：升级从库的时候，一定要留心主从的报错show slave status中的error。

Galera升级

使用Galera，执行升级要容易一些—您需要逐个停止节点，升级停止的节点，然后重新启动，然后再转到下一个节点。如果您的代理需要一些手动调整来确保流量不会受到正在进行维护的节点的攻击，则必须进行这些更改。如果它可以自动检测所有的东西，你只需要停止MySQL，升级并重新启动。一旦您浏览了集群中的所有节点，升级就完成了。

友情建议：升级Galera，一定要测试、测试、测试、备份、备份、备份。有个比较完善的回退方案，猥琐发育，不要浪。

主要版本升级

MySQL中的主要版本升级将是5.x - > 5.y甚至4.x> 5.y。这样的升级比较复杂，比较复杂，我们刚刚在前面的段落中提到的小升级。

执行升级的推荐方式是转储并重新加载数据—这需要一些时间（取决于数据库的大小），但是在从站不再旋转的情况下执行升级通常是不可行的。即使使用mydumper / myloader，这个过程也会花费很长时间。一般来说，如果数据集大于几百GB，则可能需要额外的准备工作。

尽管可能只是进行二进制升级（安装新软件包），但不建议这样做，因为旧版本和新版本之间可能存在一些二进制格式的不兼容问题，甚至在执行mysql_upgrade之后，仍然可能造成一些问题。我们已经看到了二进制升级导致的一些奇怪的行为，如何在优化器的工作原理，或导致不稳定。所有这些问题都通过执行转储/重新加载过程来解决。所以，虽然运行二进制升级也许可以，但是您也可能遇到严重的问题—这是您的要求，最终是您的决定。如果您决定执行二进制升级，则需要执行详细（耗时）的测试，以确保不会破坏任何内容。否则，你有风险。

MySQL复制

如果我们的设置基于MySQL复制，我们将在新的MySQL版本上构建一个从站。假设我们正在从MySQL 5.5升级到MySQL 5.6。由于我们必须执行一个很长的转储/重新加载过程，我们可能需要为此构建一个单独的MySQL主机。最简单的方法是使用xtrabackup从一个从站获取数据并复制坐标。这些数据将允许您将新节点从旧节点上删除。一旦新节点（仍在运行MySQL 5.5 - xtrabackup只是移动数据，所以我们必须使用相同的，原始的MySQL版本）启动并运行后，是时候转储数据了。您可以使用我们之前在“备份和还原”中发布的任何逻辑备份工具。只要您稍后可以恢复数据，则无关紧要。

转储完成后，该停止MySQL，清除当前数据目录，在节点上安装MySQL 5.6，使用mysql_install_db脚本初始化数据目录并启动新的MySQL版本。那么是时候加载转储 - 这个过程也可能需要很长时间。一旦完成，你应该有一个新的和干净的MySQL 5.6节点。现在是时候把它和master一起同步了 - 你可以使用xtrabackup收集的坐标将节点从运行MySQL 5.5的生产集群的成员中删除。这里需要记住的重要一点是，如果您最终要将节点从当前的生产群集中删除，则需要确保二进制日志不会旋出。对于大型数据集，转储/重新加载过程可能需要几天，因此您需要调整expire_logs_days因此在主人。你也想确认你有足够的可用磁盘空间用于所有这些binlog。

一旦我们拥有一个MySQL 5.5从属MySQL 5.5主服务器，现在是时候浏览5.5个从服务器并升级它们了。现在最简单的方法是利用xtrabackup从5.6节点复制数据。所以，我们把一个5.5从机停掉，停止MySQL服务器，清除数据目录，将MySQL升级到5.6，使用xtrabackup从其它5.6从机恢复数据。一旦完成，您可以再次设置复制，并且应该全部设置。

这个过程比为每个从站执行转储/重新加载要快得多—每个复制群集执行一次就可以了，然后使用物理备份来重建其他从站。如果您使用AWS，则可以依靠EBS快照而不是xtrabackup。与逻辑备份类似，只要能够正常工作，重建从站的方式并不重要。

最后，一旦所有从站都升级完毕，您需要从5.5主站到5.6从站之一进行故障切换。在这一点上，可能发生的情况是，您将无法在复制中保留5.5（即使您在它们之间设置了主 - 主复制）。一般来说，不支持从新版本的MySQL复制到较旧的版本 - 复制可能会中断。不管怎么样，您都需要使用与从服务器相同的流程来升级和重建旧的主服务器。

Galera升级

与MySQL复制相比，Galera同时更加容易升级。用Galera创建的集群应该被看作是一个MySQL服务器。在讨论Galera升级时，记住这一点至关重要 - 它不是一个拥有一些slave或者相互连接的master - 就像一台服务器一样。要执行单个MySQL服务器的升级，您需要执行脱机升级（使其不能轮换，转储数据，将MySQL升级到5.6，加载数据，重新启动它）或创建一个从属服务器，升级它并最终故障转移到它（我们在上一节讨论MySQL复制升级时描述的过程）。

同样的事情适用于Galera集群—您要么升级所有节点（所有节点），要么必须构建一个从属节点—另一个通过MySQL复制连接的Galera集群。

在线升级过程可能如下所示。对于初学者来说，你需要在MySQL 5.6上创建slave — 进程与上面完全一样：创建一个包含MySQL 5.5的节点（可以是Galera但不是必须的），使用xtrabackup复制数据和复制坐标，dump数据使用逻辑备份工具，清除数据目录，将MySQL升级到5.6 Galera，引导集群，加载数据，从节点关闭5.5 Galera集群。

此时，您应该有两个Galera群集—5.5和一个Galera 5.6的单个节点，都通过复制连接。下一步将是建立一个生产规模的5.6集群。很难说如何做 - 如果你在云端，你可以旋转新的实例。如果您在数据中心中使用共置服务器，则可能需要将某些硬件从旧群集移到新群集。您需要记住系统的总容量，以确保它能够处理一些不能轮换的节点。虽然硬件管理可能会非常棘手，但最好不要过多关注构建5.6群集—Galera将使用SST自动填充新节点。

一般来说，这个阶段的目标是建立一个足够处理生产工作量的5.6集群。一旦完成，您需要故障转移到5.6 Galera群集—这将结束升级。当然，您可能仍然需要添加更多的节点，但现在是一个定期调配Galera节点的过程，现在只使用5.6而不是5.5。

原文发布时间为：2017-12-30

本文作者：田帅萌