看完这篇,你就知道是否要升级到MySQL 8.4 LTS
nanshan 2024-10-20 07:35 12 浏览 0 评论
写在前面
MySQL 8.0 版本即将于 2026 年 4 月结束服务支持,而 MySQL 8.4 作为当前的 LTS 版本,在 MySQL 的 Release Notes 和手册上都被加上了 current 标记。
也就是说,对版本选择偏稳重的铁子们,可以在 8.0 版本后选择 8.4 版本。
升级、降级 兼容关系表
先看下未来几个主要版本之间的 升级、降级 兼容关系表,作为选择具体哪个版本之前的重要参考之一(本表格内容摘自徐轶韬老师主理的公众号:MySQL解决方案工程师):
- 升级
原地 | 克隆 | 异步复制 | 转储/加载 | |
LTS 8.4 → LTS 9.7 | ? | ? | ? | ? |
LTS 8.4.11 → LTS 8.4.20 | ? | ? | ? | ? |
Innovation 8.1 → 8.2 | ? | ? | ? | ? |
Innovation 8.1 → 8.3 | ? | ? | ? | ? |
Innovation 9.1 → LTS 9.7 | ? | ? | ? | ? |
LTS 8.4 → LTS 10.7 | ? | ? | ? | ? |
- 降级
原地 | 克隆 | 异步复制 | 转储/加载 | |
LTS 8.4.20 → 8.4.11 | ? | ? | ? | ? |
LTS 9.7 → LTS 8.4 | ? | ? | ?? | ?? |
LTS 9.7 → Innovation 9.6 | ? | ? | ?? | ?? |
LTS 9.7 → Innovation 9.5 | ? | ? | ?? | ?? |
?表示仅用于回滚目的。
MySQL 8.4 新变化
下面罗列 MySQL 8.4 相对 8.0 版本我个人认为比较关键的一些变化,感觉相对没那么重要的就没列出。
InnoDB 相关新变化
- 以下是 InnoDB 中几个主要参数(没有全部列出)的默认值发生变化
参数名 | 8.4 默认值 | 8.0 默认值 |
innodb_buffer_pool_in_core_file | 支持 MADV_DONTDUMP 时默认 OFF,其他情况下默认 ON | ON |
innodb_buffer_pool_instances | 当 IBP <= 1GB 时为 1,当 IBP > 1GB 时会根据公式自动计算 | 8,当 IBP <= 1GB 时为 1 |
innodb_change_buffering | none | all |
innodb_adaptive_hash_index | OFF | ON |
innodb_doublewrite_files | 2 | innodb_buffer_pool_instances*2 |
innodb_flush_method(Linux系统中) | 系统支持时为 O_DIRECT,否则 fsync | fsync |
innodb_io_capacity | 1000 | 200 |
innodb_io_capacity_max | innodb_io_capacity*2 | innodb_io_capacity*2,且最小值为 2000 |
innodb_log_buffer_size | 64MB | 16MB |
innodb_numa_interleave | ON | OFF |
innodb_page_cleaners | innodb_buffer_pool_instances | 4 |
innodb_parallel_read_threads | CPU逻辑核数/8,默认最低为 4 | 4 |
innodb_purge_threads | CPU逻辑核数 <=16 时为 1,否则为 4 | 4 |
innodb_read_io_threads | CPU逻辑核数/8,默认最低为 4 | 4 |
innodb_use_fdatasync | ON | OFF |
- 临时表相关几个参数的默认值也发生变化
参数名 | 8.4 默认值 | 8.0 默认值 |
temptable_max_ram | 物理内存 * 3%,且默认值的范围在 1-4GB 间 | 1GB |
temptable_max_mmap | 0(禁用) | 1GB |
temptable_use_mmap | OFF | ON,从 8.0.26 开始提示即将弃用 |
MGR 相关新变化
- 有两个 MGR 参数默认值发生变化:事务一致性级别参数 group_replication_consistency 从 EVENTUAL 调整为 BEFORE_ON_PRIMARY_FAILOVER;节点退出后的默认行为参数 group_replication_exit_state_action 从 READ_ONLY 调整为 OFFLINE_MODE。
- 在 MGR 中切换新的主节点时,需要等待当前的 DDL 操作(例如 ALTER TABLE)以及大部分 DCL 操作(例如 ALTER DATABASE)结束才能继续。
- 对 MGR 的版本兼容约束也放宽了,支持相同大版本内的小版本原地降级(例如从 8.4.2 原地降级到 8.4.0);另外,只要是大版本号相同,小版本号不同的多个节点也可以混跑(例如在 8.4.0、8.4.2、8.4.3 三个不同小版本号的节点可以在一起跑 MGR)。
- 在 MGR 中新增参数 group_replication_preemptive_garbage_collection,设置为 ON 时,在单主模式下会启用了抢占式 GC(garbage collection),仅保留尚未提交的事务 writeset。这可以节省时间和内存消耗。同时新增 group_replication_presemptive_garbage_collection_rows_threshold 参数用于设置了触发抢占式 GC 所需的认证事务数最小值,默认为 100000。
主从复制及 Clone 相关新变化
- Clone 插件不再严格要求连小版本号也要一致才行,允许在同一个大版本内进行克隆。这个特性不错,希望未来能继续提升兼容性,支持在不同大版本间 Clone 数据。
- 在主从复制中,参数 SOURCE_RETRY_COUNT默认值从 86400 调整为 10。即默认行为是 重试 10 次,每次间隔 60 秒,总共 10 分钟。在 8.0 中默认行为是重试 86400 次,每次间隔 60 秒,总共 60 天(这也太过于疯狂了吧 ~~)。
- 支持对 GTID 事务设置不同的 tag(标签),这对于运维很友好,比如针对一些特殊操作加上特别的标签便于后续区分。
- 在从服务器上执行START REPLICA 启动复制线程时,子句 SQL_AFTER_GTIDS 支持多线程并行回放工作模式。在以前,启用多线程并行回放时,如果加上 SQL_AFTER_GTIDS 会提示 ER_MTA_FEATURE_IS_NOT_SUPPORTED 告警,并自动切换到单线程回放模式。
其他新变化
- 无论是否执行了ANALYZE TABLE操作,都支持自动更新直方图统计信息,自动更新的规则和 InnoDB 表统计信息自动更新规则一样,详情参考 innodb_stats_auto_recalc 参数。
- 默认地,不再启用认证插件 mysql_native_password,如果需要启用以兼容旧的应用程序的话,则要在启动时加上 --mysql-native-password=ON 参数,也可以在运行时在线动态设置 SET GLOBAL mysql_native_password=ON 启用。
- 在 mysqldump 中增加 --output-as-version 参数,支持设置对旧版本的兼容性模式。
- 针对 FLUSH PRIVILEGES 新增相应的授权 FLUSH_PRIVILEGES。
- 新增一些保留关键字:AUTO, BERNOULLI, GTIDS, LOG, MANUAL, PARALLEL, PARSE_TREE, QUALIFY, S3, TABLESAMPLE,这些保留关键字不可用于库、表、字段等数据库对象名称。
MySQL 8.4 中弃用或不再建议使用的特性、参数
下面是未来准备弃用的一些特性及参数
- 参数 binlog_transaction_dependency_tracking,因为总是使用 WRITESET 机制。
- 参数 group_replication_allow_local_lower_version_join。
- 从 8.3.0 开始,MGR 组成员元数据信息会在各节点间共享,因此不再需要依赖组视图变化事件,相应地,参数 group_replication_view_change_uuid 也不再需要。
- 废弃函数 WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()。
- 在主从复制中如果已启用 GTID 模式,则已被应用的事务会自动被忽略,这意味着 IGNORE_SERVER_IDS 参数和 GTID 模式将不兼容。
- 废弃参数 expire_logs_days,改用 binlog_expire_logs_seconds 参数。
- 废弃参数 group_replication_recovery_complete_at。从 8.4.0 开始,分布式事务恢复过程中的策略总是:只有在新成员接收、认证并应用了其加入组之前发生的所有事务后,才会标记在线;这相当于在早期版本中设置 group_replication_recovery_complete_at = TRANSACTIONS_APPLIED 同样的效果。
写在最后
总的来说,MySQL 8.4 看起来是作为 8.0 的延续并成为 LTS 版本。
两个版本间的变化并不算太大,并且主要集中在 InnoDB 引擎方面。
无论对开发者还是DBA来说都能很快适配和适应。
想要体验激进新特性的话,可以尝试 8.1/8.2/8.3/9.0 等创新版本。
延伸阅读
- https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html
相关推荐
- 服务器数据恢复—Raid5数据灾难不用愁,Raid5数据恢复原理了解下
-
Raid5数据恢复算法原理:分布式奇偶校验的独立磁盘结构(被称之为raid5)的数据恢复有一个“奇偶校验”的概念。可以简单的理解为二进制运算中的“异或运算”,通常使用的标识是xor。运算规则:若二者值...
- 服务器数据恢复—多次异常断电导致服务器raid不可用的数据恢复
-
服务器数据恢复环境&故障:由于机房多次断电导致一台服务器中raid阵列信息丢失。该阵列中存放的是文档,上层安装的是Windowsserver操作系统,没有配置ups。因为服务器异常断电重启后,rai...
- 服务器数据恢复-V7000存储更换磁盘数据同步失败的数据恢复案例
-
服务器数据恢复环境:P740+AIX+Sybase+V7000存储,存储阵列柜上共12块SAS机械硬盘(其中一块为热备盘)。服务器故障:存储阵列柜中有磁盘出现故障,工作人员发现后更换磁盘,新更换的磁盘...
- 「服务器数据恢复」重装系统导致XFS文件系统分区丢失的数据恢复
-
服务器数据恢复环境:DellPowerVault系列磁盘柜;用RAID卡创建的一组RAID5;分配一个LUN。服务器故障:在Linux系统层面对LUN进行分区,划分sdc1和sdc2两个分区。将sd...
- 服务器数据恢复-ESXi虚拟机被误删的数据恢复案例
-
服务器数据恢复环境:一台服务器安装的ESXi虚拟化系统,该虚拟化系统连接了多个LUN,其中一个LUN上运行了数台虚拟机,虚拟机安装WindowsServer操作系统。服务器故障&分析:管理员因误操作...
- 「服务器数据恢复」Raid5阵列两块硬盘亮黄灯掉线的数据恢复案例
-
服务器数据恢复环境:HPStorageWorks某型号存储;虚拟化平台为vmwareexsi;10块磁盘组成raid5(有1块热备盘)。服务器故障:raid5阵列中两块硬盘指示灯变黄掉线,无法读取...
- 服务器数据恢复—基于oracle数据库的SAP数据恢复案例
-
服务器存储数据恢复环境:某品牌服务器存储中有一组由6块SAS硬盘组建的RAID5阵列,其中有1块硬盘作为热备盘使用。上层划分若干lun,存放Oracle数据库数据。服务器存储故障&分析:该RAID5阵...
- 「服务器虚拟化数据恢复」Xen Server环境下数据库数据恢复案例
-
服务器虚拟化数据恢复环境:Dell某型号服务器;数块STAT硬盘通过raid卡组建的RAID10;XenServer服务器虚拟化系统;故障虚拟机操作系统:WindowsServer,部署Web服务...
- 服务器数据恢复—RAID故障导致oracle无法启动的数据恢复案例
-
服务器数据恢复环境:某品牌服务器中有一组由4块SAS磁盘做的RAID5磁盘阵列。该服务器操作系统为windowsserver,运行了一个单节点Oracle,数据存储为文件系统,无归档。该oracle...
- 服务器数据恢复—服务器磁盘阵列常见故障表现&解决方案
-
RAID(磁盘阵列)是一种将多块物理硬盘整合成一个虚拟存储的技术,raid模块相当于一个存储管理的中间层,上层接收并执行操作系统及文件系统的数据读写指令,下层管理数据在各个物理硬盘上的存储及读写。相对...
- 「服务器数据恢复」IBM某型号服务器RAID5磁盘阵列数据恢复案例
-
服务器数据恢复环境:IBM某型号服务器;5块SAS硬盘组成RAID5磁盘阵列;存储划分为1个LUN和3个分区:第一个分区存放windowsserver系统,第二个分区存放SQLServer数据库,...
- 服务器数据恢复—Zfs文件系统下误删除文件如何恢复数据?
-
服务器故障:一台zfs文件系统服务器,管理员误操作删除服务器上的数据。服务器数据恢复过程:1、将故障服务器所有磁盘编号后取出,硬件工程师检测所有硬盘后没有发现有磁盘存在硬件故障。以只读方式将全部磁盘做...
- 服务器数据恢复—Linux+raid5服务器数据恢复案例
-
服务器数据恢复环境:某品牌linux操作系统服务器,服务器中有4块SAS接口硬盘组建一组raid5阵列。服务器中存放的数据有数据库、办公文档、代码文件等。服务器故障&检测:服务器在运行过程中突然瘫痪,...
- 服务器数据恢复—Sql Server数据库数据恢复案例
-
服务器数据恢复环境:一台安装windowsserver操作系统的服务器。一组由8块硬盘组建的RAID5,划分LUN供这台服务器使用。在windows服务器内装有SqlServer数据库。存储空间LU...
- 服务器数据恢复—阿里云ECS网站服务器数据恢复案例
-
云服务器数据恢复环境:阿里云ECS网站服务器,linux操作系统+mysql数据库。云服务器故障:在执行数据库版本更新测试时,在生产库误执行了本来应该在测试库执行的sql脚本,导致生产库部分表被tru...
你 发表评论:
欢迎- 一周热门
-
-
爱折腾的特斯拉车主必看!手把手教你TESLAMATE的备份和恢复
-
如何在安装前及安装后修改黑群晖的Mac地址和Sn系列号
-
[常用工具] OpenCV_contrib库在windows下编译使用指南
-
WindowsServer2022|配置NTP服务器的命令
-
Ubuntu系统Daphne + Nginx + supervisor部署Django项目
-
WIN11 安装配置 linux 子系统 Ubuntu 图形界面 桌面系统
-
解决Linux终端中“-bash: nano: command not found”问题
-
NBA 2K25虚拟内存不足/爆内存/内存占用100% 一文速解
-
Linux 中的文件描述符是什么?(linux 打开文件表 文件描述符)
-
K3s禁用Service Load Balancer,解决获取浏览器IP不正确问题
-
- 最近发表
-
- 服务器数据恢复—Raid5数据灾难不用愁,Raid5数据恢复原理了解下
- 服务器数据恢复—多次异常断电导致服务器raid不可用的数据恢复
- 服务器数据恢复-V7000存储更换磁盘数据同步失败的数据恢复案例
- 「服务器数据恢复」重装系统导致XFS文件系统分区丢失的数据恢复
- 服务器数据恢复-ESXi虚拟机被误删的数据恢复案例
- 「服务器数据恢复」Raid5阵列两块硬盘亮黄灯掉线的数据恢复案例
- 服务器数据恢复—基于oracle数据库的SAP数据恢复案例
- 「服务器虚拟化数据恢复」Xen Server环境下数据库数据恢复案例
- 服务器数据恢复—RAID故障导致oracle无法启动的数据恢复案例
- 服务器数据恢复—服务器磁盘阵列常见故障表现&解决方案
- 标签列表
-
- linux 查询端口号 (58)
- docker映射容器目录到宿主机 (66)
- 杀端口 (60)
- yum更换阿里源 (62)
- internet explorer 增强的安全配置已启用 (65)
- linux自动挂载 (56)
- 禁用selinux (55)
- sysv-rc-conf (69)
- ubuntu防火墙状态查看 (64)
- windows server 2022激活密钥 (56)
- 无法与服务器建立安全连接是什么意思 (74)
- 443/80端口被占用怎么解决 (56)
- ping无法访问目标主机怎么解决 (58)
- fdatasync (59)
- 405 not allowed (56)
- 免备案虚拟主机zxhost (55)
- linux根据pid查看进程 (60)
- dhcp工具 (62)
- mysql 1045 (57)
- 宝塔远程工具 (56)
- ssh服务器拒绝了密码 请再试一次 (56)
- ubuntu卸载docker (56)
- linux查看nginx状态 (63)
- tomcat 乱码 (76)
- 2008r2激活序列号 (65)