kn007的个人博客
♥ You are here: Home > 软件与网络 > VPS > MySQL 8.0.11的更新之路

MySQL 8.0.11的更新之路

by | 68 Comments

提醒:本文最后更新于 2982 天前,文中所描述的信息可能已发生改变,请仔细核实。

总算赶在0点前发了出来,就不配图了。

在北京时间今天的18:10,MySQL更新了最新的GA版本8.0.11。

尴尬的是,那时候我正在将MySQL从5.7.21升级到5.7.22(在今天15:15放出)。

所以更新至5.7.22后,又马不停蹄的开了台测试机,测试了8.0.11。

便开始掉坑之旅,在摔得鼻青脸肿后,边查文档边爬出来。。。

让我一一道来,首先是my.cnf的。

Symbolic links现在默认就是禁用了,无需再去标记禁用了,如果你标记的话,会有个提醒:

'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.

再有就是“expire-logs-days”参数已经没有了,取而代之的是“binlog_expire_logs_seconds”,如名,单位是秒,不要搞错了。

据说,purge方式也不一样,但我没细究,回头看看。错误提示如下:

The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.

SQL Mode的NO_AUTO_CREATE_USER也没有了。

In MySQL 8.0.11, several deprecated features related to account management have been removed, such as use of the GRANT statement to modify nonprivilege characteristics of user accounts, the NO_AUTO_CREATE_USER SQL mode, the PASSWORD() function, and the old_passwords system variable.

Using GRANT to create users. Instead, use CREATE USER. Following this practice makes the NO_AUTO_CREATE_USER SQL mode immaterial for GRANT statements, so it too is removed.

实际应用时,发现不用加密手段,根本登录不上MySQL(比如用phpMyAdmin等就不行,用命令行就没事)。

查了下,发现是MySQL 8.0改了默认加密方式为“caching_sha2_password”:

In MySQL 8.0, caching_sha2_password is the default authentication plugin rather than mysql_native_password.

咋整?那就改回来呗,改回“mysql_native_password”。

default_authentication_plugin=mysql_native_password

另外MySQL的X Plugin默认跟随启动,作用我还没具体了解,早在5.7就有了,但一直没用它。

跟随启动后,如果你是用socket,它会在相同目录生成mysqlx.sock。并且他的连接方式强制要SSL,至少第一次要,如果我没理解错,官方是这么写的:

This means that the first use of an account must be done using an SSL connection with the X Plugin authentication cache enabled. Once this initial authentication over SSL has succeeded non-SSL connections can be used.

所以你也能在日志文件看到告警,如果你没有配置SSL的话:

Plugin mysqlx reported: 'Failed at SSL configuration: "SSL context is not usable without certificate and private key"

文档虽说mysqlx-ssl与ssl相等,但mysqlx-ssl=0或者skip、disabled都没用。并无办法禁用这一警告,如果谁知道方法和文档位置,麻烦告知下,谢谢。

而且这个的实际应用能有多少,也是个疑问。

之前说MySQL已经不用MyISAM存储了。确实没错,核心引擎已经不再使用MyISAM了,改为InnoDB了。但MyISAM引擎仍然是可用的,但是有限支持,具体可以看文档,传送门

In MySQL 8.0, it is normally necessary to use ENGINE to specify the MyISAM storage engine because InnoDB is the default engine.

In MySQL 8.0, the MyISAM storage engine provides no partitioning support. Partitioned MyISAM tables created in previous versions of MySQL cannot be used in MySQL 8.0. For more information, see Section 23.6.2, “Partitioning Limitations Relating to Storage Engines”.

其实想知道MySQL怎么禁用MyISAM这些插件,像MariaDB很容易禁用,给MySQL配上禁用参数,只会提示不认识这个参数。。

还有现在utf8mb4默认编码使用的是utf8mb4_0900_ai_ci,据说有优化,先用着看看有没有坑吧。。。

十分推荐升级,性能和效率提升很多。其他坑暂时没遇到过,正在尝试调优。

好了,就先简单说到这,其他需要补充的,后续再补充。

哦,对了,还有Nginx Amplify只能识别MySQL版本,却得不到任何数据,已经提交issue了。


MySQL 8.0之前的版本,当使用--all-databases 参数导出数据的时候,不加--routines和--events选项也可以导出触发器、存储过程等信息,因为这些信息都存放于proc和event表中,导出所有表即可导出这些信息。

但是在MySQL 8.0中,proc表和event表都不再使用,并且定义触发器、存储过程的数据字典表不会被导出。所以在8.0中使用mysqldump、mysqlpump导出数据的时候,如果需要导出触发器、存储过程等内容,一定需要加上--routines和--events选项。

转载请注明转自: kn007的个人博客 的《MySQL 8.0.11的更新之路

donate
有所帮助?
Tags: , ,
Comments
68 Comments立即评论
  1. LV3
    回复

    标题改成更新至 MySQL 8.0.11 吧,别挣扎了 :smile:

    1. MOD
      回复

      @lwl12: 不,我就不 :twisted:

    2. 回复

      @lwl12: {} 的更新之路

    3. MOD
      回复

      @ysc3839: 感觉我要背着这个梗了 :cry:

    4. LV1
      回复

      @kn007: 专业更新博主kn007 :smile:

    5. MOD
      回复

      @一曲长歌辞烟雨: 完了完了 :razz:

    6. MOD
      回复

      @lwl12: 好了,现在各大群见到我,就说那个做更新日志的博主来了。。 :???:

    7. LV3
      回复
  2. LV4
    回复

    好折腾……没内存玩不起吧...

    1. MOD
      回复

      @zwwooooo: 比以前省内存,性能上我还没做测试。。。
      刚搞完,就凑篇文出来,啥都还没测,还有很多新东西。。

      然后明天开始也要恢复正常状态,不能不务正业了。。

    2. MOD
      回复

      @zwwooooo: 十分建议升级,性能和效率提升很多。 :oops:

    3. LV4
      回复

      @kn007: 总内存 1G 以下行不行?另外不知道有没有兼容性问题...

    4. MOD
      回复

      @zwwooooo: 可以的,配置配低来就行了,不过可能会降低性能。
      兼容性,如果都是InnoDB,感觉应该不存在问题,至少目前我还没遇见任何问题

  3. LV5
    回复

    512 内存能玩得起吗? :grin:

    1. MOD
      回复

      @老杨: 512都给MySQL,也可以啊,配置下

    2. LV6
      回复

      @老杨: 刚换了个512的,哈哈。

    3. LV5
      回复

      @郑永: 升级了?能跑? :cry:

    4. LV6
      回复

      @老杨: 降级 :o

    5. MOD
      回复

      @郑永: 老铁,邮箱写错了。。帮你改正了。

    6. LV6
      回复

      @kn007: :o 我想知道你怎么知道的?后天看头像?还是列入审核状态?

    7. MOD
      回复

      @郑永: 自动进待审啊。

      我的主题使用钩子重做了评论逻辑这块。。。嘿嘿

    8. LV6
      回复

      @kn007: 话说你的表情还可以在邮箱回复里显示。 ;-)

    9. MOD
      回复

      @郑永: 这一直都可以啊 :grin:

  4. 回复

    想坐等 MariaDB 更新啊 :lol:

    1. MOD
      回复

      @01: 咦,是你,你怎么不用🐳做昵称了?
      还是我这出Bug了。

    2. 回复

      @kn007: 当初随便起了个名字,用emoji做昵称最大的坏处是经常在个人博客上遇到意外的问题
      好在这里没有 :mrgreen:

    3. MOD
      回复

      @🐋: 好久没见到你了 :oops:
      新版的wordpress都没问题的现在,早期我考虑在先,做在前,就没什么事。

  5. 回复

    SQL Mode的NO_AUTO_CREATE_USER也没有了 ,需要用的时候咋整 :razz:

    1. MOD
      回复

      @BiGB: 因为控制权限的方法不一样了。。。怎么说呢,因为没影响,我没有深究。

    2. 回复

      @kn007: laravel 确实用不了。。。
      SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER' xxx :o

    3. MOD
      回复

      @BiGB: 框架问题,跟MySQL无关,官方已经在改了

    4. MOD
      回复

      @BiGB: https://github.com/laravel/framework/pull/23948

  6. 回复

    万年5.5版本, 小网站根本不需要这么高的性能。
    关键原因是innodb太耗内存

    1. MOD
      回复

      @匿名: 萝卜青菜

  7. 回复

    :oops: 放眼过去全是更新软件文章

    1. MOD
      回复
  8. LV1
    回复

    utf8mb4_0900_ai_ci 唯一不好的地方就是旧版本没法用,于是我就把旧版的也给升了 :cry:

    1. MOD
      回复
  9. LV2
    回复

    你的更新速度真是相当快。 :razz:

    1. MOD
      回复

      @灰常记忆: 那必须的!

  10. LV6
    回复

    我那还是5.5.9,更新这么快,遇到问题也是必须会解决的。

    1. MOD
      回复

      @郑永: 5.5.9,该更新了 :oops:

;-):|:x:twisted::smile::shock::sad::roll::razz::oops::o:mrgreen::lol::idea::grin::evil::cry::cool::arrow::???::?::!: