mysql 8升级在许多年我们使用MySQL,我们习惯了这一事实从MySQL 5.7.11升级5.7.12只是一件小事。这意味着,如果是错的,我们可以回滚二进制文件并再次感到高兴。

从MySQL 8,这不再是真实的。任何升级,即使是很小的,被认为是不可逆转的。(这是有效的raybetapp 。)

说我们有MySQL 8.0.17 8.0.18升级。在我们的MySQL日志开始时,我们将:

所有我们好!

然后我们意识到,刚刚将实例有这并不像预期的那样工作。在这一点上,我们可能需要回滚安装,并放回8.0.17二进制文件。

但是一旦我们做了,我们重新开始MySQL,实例将无法启动和MySQL日志显示:

我们不能回滚

这是明确的MySQL文档。你可能不喜欢它,但这就是现在。

这里有一些事情要考虑。升级一个小MySQL版本在过去是一个微不足道的活动,经常和自动化是默默地做。这不是最佳实践,但这是现实。同时,测试经常是肤浅的,如果做的话。

这种态度必须改变。

  • 你不能做一个升级小版本没有:
    • 完全备份/恢复测试(必须一个逻辑备份,如:,mysqldump mydumper或任何其他工具,允许你导出数据)
    • 严重的登台环境功能/应用程序测试
  • 你应该禁用任何自动化执行沉默/生产测试升级

还请记住,如果你进行备份,如果你有字节,甚至可能只是一个GB的数据,回滚将不会立即。

鉴于此,你应该:

  • 仔细计划,使用一个合适的平台测试(如全填充阶段)。
  • 使用尽可能多的实际负载从您的应用程序。
  • 从奴隶链的最后一个服务器升级。
  • 不要试图赶/实现最新的闪亮的特性。

最后一个但不支持方法(看到文档)是依靠复制中描述复制从MySQL 8.0至5.7 MySQL。但请记住,这是在你自己的风险,因为它不完全支持MySQL / Oracle。

这些是所需的最少的步骤来执行小版本升级,是安全的。伟大的MySQL大家!

参考

错误# 95216——打开了前一段时间我们赛威廉姆斯。

4评论
最古老的
最新的 大多数投票
内联反馈
查看所有评论
彼得•扎伊采夫

我想知道每个MySQL 8版本升级数据字典或只有一些小的版本?

在任何情况下,这是需要考虑的重大变化。

0
dbdemon

在8.0中主要的新特性被在补丁发布/错误修复版本(8.0.x),曾经被认为是大禁忌,因为它自然地引入新错误的风险增加,同时你再也不能回到以前的版本,除非通过逻辑备份,如果新,闪亮的版本引入了错误。我不确定我会描述为“伟大的MySQL”除非我被讽刺!

0
Marko麦克拉

我在想如果我能部分负责这个限制。简短的回答:没有。

在我最后一年在甲骨文,我工作在全局数据字典项目,主要是InnoDB的一面。InnoDB的我实现原型从未公布。但似乎我的设计生活。

设计的一部分,我们将硬编码的格式非常小数量的数据字典表,类似于InnoDB总是硬编码SYS_TABLES, SYS_COLUMNS SYS_INDEXES SYS_FIELDS在系统表空间(这应该是完全取代全局数据字典表)。他们的想法是,模式修改数据字典表将是极其罕见的,和数据字典版本几乎从来没有被更新。一些字典表或系统表可以创建“正常”,被写入到核心元数据表。

我想知道这个错误消息与数据字典的版本。它似乎InnoDB相关数据文件本身。对降级消息是输出函数fil_ibd_open ()。

MariaDB,而我们不正式保证评级工作,我花了一些努力,以确保.ibd文件的导入/导出服务器版本之间在一个合理的方式工作。当然,如果你使用10.3即时添加列,您将无法导入旧版本的表。但如果你重建表10.3,它将再次在旧兼容的格式,,您应该能够将其导入MariaDB 10.0或更高版本,或MySQL 5.6或MySQL 5.7。同样的,如果你使用后出口10.4即时删除列,导入到10.3或更早的就会失败。最后但并非最不重要的,文件中创建10.4 innodb_checksum_algorithm = full_crc32不会兼容旧版本。

当涉及到数据字典,我改变了我的想法自从MySQL 8.0字典设计。首先,我相信不是介绍一个单独的“ddl_log”表我们应该扩展undo日志格式。MariaDB 10.2.19支持crash-safe和Mariabackup-compatible InnoDB内重命名表和截断表,只有扩展现有的撤销和重做日志格式。MariaDB还支持InnoDB撤消表空间截断不引入一个单独的日志文件。我们仍然没有实现适当的InnoDB undo日志创建/删除表,所以并不是所有的DDL操作完全crash-safe InnoDB内部,和我们缺少日志记录在重命名.frm文件,这意味着许多DDL操作可能需要手动崩溃恢复。

其次,我相信“如果不打破,不修复它”。没有从根本上打破.frm文件。是的,一些日志记录是需要事务原子和crash-safe。但序列化、可扩展格式.frm文件本身是好的。MySQL 8.0引入了另一种序列化的格式(基于json SDI文件),而不是跟随SQLite和重用CREATE TABLE语句,这是一个已经支持和良好定义的序列化格式。是的,外键信息从.frm文件丢失,但.frm文件可以扩展。

最后,我认为这是一个坏主意,将存储引擎更紧密地与数据字典,并允许engine-private元数据存储在数据字典中,有时甚至在DDL操作。是清洁每个表对应一个或多个数据文件,由存储引擎定义的格式。存储引擎是免费存储任何额外的信息需求,在这些数据文件。例如,即时添加/删除列的附加元数据在.ibd MariaDB存储文件,和数据导出/导入的文件只是没有额外的工作技巧。我没有试过,但我的理解是,在MySQL 8.0中,附加的元数据存储在数据字典表,和导入/导出不会工作在使用MySQL 8.0即时添加列。

不幸的是,MySQL 5.7实现为InnoDB创建表空间,打破了简单设计的“一个表是一堆文件,名字来源于表名”,实际上需要一些engine-private细节(如起始地址的每个索引表中的b - tree)存储在表空间文件(s)或在数据字典。MySQL 5.7和8.0选择了后者。

故意MariaDB服务器不支持为InnoDB表创建表空间。我认为可以消除InnoDB数据字典表,将所有数据字典信息存储在.frm文件,和所有engine-private数据存储在存储引擎的文件。为InnoDB表,这将需要写下二级索引根页码的地方。一个自然的地方,可以介绍的“元数据团”,最初是为即时列在MariaDB 10.4下降。

0
sjmudd

参见:http://blog.wl0.org/2019/09/mysql-cloning-more-thoughts/谈到克隆被确切的版本升级而不相同这是相关的。

所以我不能与本地MySQL克隆“克隆和升级”一样。这是不幸的,但不是世界末日。

咒语时我一直使用升级已经“克隆和升级”,前进的道路,让我得到低风险环境中测试这些新版本,逐步更新更多的系统直到除了大师,大师之后,得到了相同的待遇。工作得很好。几年前我甚至提升它在OOW当搬到MySQL 5.7从MySQL 5.6。显然一旦你搬到一个新的主要版本主回到一个更严重的问题,但总是认为几年一次的问题。小版本变化合规问题可能发挥作用需要升级比这更经常无法回去如果你发现一个问题是一个大问题是Oracle发布新小版本每隔几个月。

我记得讨论“你只能从相同的克隆版本”和“你不能降级问题”的一个高级甲骨文经理Percona住在阿姆斯特丹去年晚些时候,他证实了没有下调路径是有意为之。雷竞技下载官网我说我不认为这是个好主意。对生产系统你总是想要一个出路,这似乎阻止,我认为这是非常危险的。他不认为是重要的。

现在有5.7 5.7.29如果我发现一个错误,我没有注意到,直到我使用它在一个主(和所有的奴隶)没有阻止我降级的奴隶5.7.28和交换与主然后可能下调所有奴隶回到5.7.28留给我一个“完全5.7.28集群工作的。”显然我不希望这种事情发生但可能。我看到大师的负载是完全不同的负载上看到奴隶和查询配置文件也改变不少,所以一些不幸事件的组合可以让一个错误的孔集群不会好。我运行多个集群,这样就增加了机会我可能会错过一些邪恶魔法组合,咬我。

回到8.0:让我们记住。8.0有许多“小改进”自从GA和非常,非常好:我们能够更快的产品改进和新功能更快,真的很感激。但是,我认为那些可能已经做的发展尚未意识到的后果不向后兼容的变更,咨询是否有足够的用户可能会被这样一个事件,即使它可能不太可能。

我倾向于认为这将是更好的是MySQL 8.0基地和新特性应该添加在某种程度上,他们可以被关闭(即使在默认情况下)或者一个旧版本可以运行8.0 DD的定义,它会简单地忽略任何新的I_S数据结构和新代码,使用新的I_S数据结构将不会修改现有的向后兼容。

这是一个更加棘手的,但并非不可能。问题的一部分是,可能这将是可见的在哪里_undocumented_ DD表。表内容不是暴露虽然我们知道有办法看到它们。(我想他们是可见的所有的时间,但我知道这是一个失去了战斗。)这里变化不是记录我们看不出有什么变化,鉴于目前官方改变日志已经足够长的挖掘代码寻找这样的事情并不是我真正想做的。

然后很可能在许多情况下没有这样的实际需求,防止降级真的存在。我敢打赌,在许多(但不是全部)情况下,这实际上并不是必要的。

是方便添加在更改日志有什么变化阻止小版本降级的可能。至少让这更明显。这可能是你想推迟大师升级到多个小版本已经发布与主更舒适安全升级。

我还想看到一个帖子,描述了不兼容的更改,由8.0.19回到8.0.11我怀疑可能只有在这些更新的几个实际发生这样的变化,我猜他们与DD结构或格式不兼容的更改,或许可以避免这种向后不兼容的实现略有不同。如果是这样的话就可以考虑未来的小版本的变化让他们取消如果绝对必要和这个删除的限制不可能降低到一个较低的小版本的版本相比,最后一次使用。

0