MySQL 8.4 增加/变动功能说明

1. 重要变更

1.1 组复制（Group Replication）

1. 8.4版本删除了MySQL 8.0 对8.0.17或更早版本的组成员进行特殊处理部分。
   1. 官方建议使用8.0的用户在升级到8.4之前将所有的实例升级到8.0的最新版本。
2. 组复制相关的两个服务器系统变量的默认值变更：
   1. group_replication_consistency 系统变量的默认值现在为 BEFORE_ON_PRIMARY_FAILOVER；变更前：EVENTUAL
      1. 参数说明：8.0.14引进的一个和组复制相关的参数，用来控制组提供的事务一致性保障。可以在全局或单个事务中进行配置，也可在单主组复制环境中配置用于新的主库(primary)选举的组复制一致性防护机制。
      2. 参数值：
         1. EVENTUAL: 在没有添加改参数之前的默认配置，RO 和 RW 事务在执行之前都不会等待前面的事务被应用。 RW 交易不会等待其他成员应用事务。这意味着一个事务可以先于其他成员在一个成员上可访问。这也意味着，如果发生主节点故障转移，新的主节点可以在之前的主节点事务全部应用之前接受新的 RO 和 RW 事务；可能导致RO事务查询到过时的值，RW事务因冲突而导致回滚。
         2. BEFORE_ON_PRIMARY_FAILOVER：新选出的主节点优先应用旧主节点的积压事务，新的 RO 或 RW 事务将被保留（不应用），直到应用完成所有的积压事务。这确保了当主节点故障转移发生时，无论有意还是无意，客户端始终可以看到主节点上的最新值。这保证了一致性，但意味着客户端必须等待新主应用所有积压事务导致的延迟。通常这种延迟应该是非常小，但实际取决于堆积事务的大小。
         3. BEFORE：RW 事务在应用之前等待所有先前事务完成，RO 事务在执行之前等待所有先前事务完成。这确保了该事务通过仅影响事务的延迟来读取最新的值。通过确保仅在 RO 事务上使用同步，可以减少每个 RW 事务上的同步开销。此一致性级别还包括 BEFORE_ON_PRIMARY_FAILOVER 提供的一致性保证。
         4. AFTER：RW 事务会等待，直到其更改已应用到所有其他成员，该值对RO事务没有影响。此模式确保当在本地成员上提交事务时，任何后续事务都会读取任何组成员上的写入值或更新的值。将此模式与主要用于 RO 操作的组结合使用，以确保所应用的 RW 事务在提交后应用于所有地方。应用程序可以使用它来确保后续读取获取最新数据，其中包括最新写入。通过确保仅在 RW 事务上使用同步，这减少了每个 RO 事务上的同步开销。此一致性级别还包括 BEFORE_ON_PRIMARY_FAILOVER 提供的一致性保证。
         5. BEFORE_AND_AFTER：RW 事务在应用之前等待所有先前事务完成，直到其更改已应用于其他成员。 RO 事务在执行之前等待所有先前事务完成。此一致性级别还包括 BEFORE_ON_PRIMARY_FAILOVER 提供的一致性保证。
   2. group_replication_exit_state_action 系统变量的默认值现在为 OFFLINE_MODE；变更前： READ_ONLY。
      1. 参数说明：配置当此服务器实例无意中离开组时组复制的行为方式，例如遇到应用程序错误后，或在失去多数的情况下，或组中的另一个成员由于怀疑超时而将其驱逐时。成员在失去多数的情况下离开组的超时时间由 group_replication_unreachable_majority_timeout 系统变量设置，怀疑的超时时间由 group_replication_member_expel_timeout 系统变量设置。请注意，被驱逐的群组成员在重新连接到群组之前并不知道自己已被驱逐，因此仅当该成员设法重新连接，或者该成员对自己提出怀疑并驱逐自己时，才会采取指定的操作。
      2. 参数值：
         1. READ_ONLY：如果成员无意退出组或用完自动重新加入尝试，实例会将 MySQL 切换到超级只读模式（通过将系统变量 super_read_only 设置为 ON）
         2. OFFLINE_MODE：如果成员无意退出组或用完自动重新加入尝试，实例会将 MySQL 切换到离线模式（通过将系统变量offline_mode 设置为 ON）。在此模式下，已连接的客户端用户在下一个请求时将断开连接，并且不再接受连接，具有 CONNECTION_ADMIN 权限（或已弃用的 SUPER 权限）的客户端用户除外。组复制还将系统变量 super_read_only 设置为 ON，因此客户端无法进行任何更新，即使它们已使用 CONNECTION_ADMIN 或 SUPER 权限进行连接。
         3. ABORT_SERVER 时，如果成员无意退出组或用完自动重新加入尝试，实例将关闭 MySQL。
3. 当 group_replication_consistency 设置为 BEFORE_ON_PRIMARY_FAILOVER 时，MySQL KILL 语句现在会忽略任何一致性保证，任何中断的事务现在都会回滚。

1.2 其他

1. 对于捆绑 OpenSSL 库的平台，MySQL Server 的链接 OpenSSL 库已更新至版本 3.0.13。 https://www.openssl.org/news/cl30.txt 中描述了 OpenSSL 版本 3.0.13 中修复的问题。
2. 不支持从MySQL 5.7升级到MySQL 8.4；代码和行为已更新以反映这一点。将 MySQL 5.7 升级到 8.0，然后再继续升级到 8.4。

2. 其他更新

2.1 InnoDB

1. 现在，在长时间运行的回滚过程中，进度消息会定期记录为信息注释级别错误消息，最初为 ER_IB_LONG_ROLLBACK_FULL（附加事务信息），然后是连续的 ER_IB_LONG_ROLLBACK。
2. 更改了以下 InnoDB 配置选项的默认值：

   InnoDB系统变量名	新默认值(MySQL 8.4)	之前默认值 (MySQL 8.0)
   innodb_buffer_pool_in_core_file	如果支持 MADV_DONTDUMP，则为 OFF，否则为 ON	ON
   innodb_buffer_pool_instances	如果 innodb_buffer_pool_size <= 1 GiB，则 innodb_buffer_pool_instances=1 如果 innodb_buffer_pool_size 为 1 GiB，则这是以下两个计算提示的最小值，范围为 1-64：Buffer pool hint：计算为 (innodb_buffer_pool_size / innodb_buffer_pool_chunk_size) 的 1/2;CPU hint：按可用逻辑处理器数量的1/4计算	8 (or 1 if innodb_buffer_pool_size < 1 GiB)
   innodb_change_buffering	none	all
   innodb_dedicated_server	该变量实际默认值为OFF；这与 MySQL 8.0 相比没有变化。如果为ON，则innodb_flush_method的值不再像MySQL 8.0中那样改变，但innodb_redo_log_capacity的计算从基于内存变为基于CPU	OFF
   innodb_adaptive_hash_index	OFF	ON
   innodb_doublewrite_files	2	innodb_buffer_pool_instances * 2
   innodb_doublewrite_pages	128	innodb_write_io_threads, which meant a default of 4
   innodb_flush_method on Linux	O_DIRECT（如果支持），否则 fsync	fsync
   innodb_io_capacity	10000	200
   innodb_io_capacity_max	2 * innodb_io_capacity	2 * innodb_io_capacity，最小默认值为2000
   innodb_log_buffer_size	67108864 (64 MiB)	16777216 (16 MiB)
   innodb_numa_interleave	ON	OFF
   innodb_page_cleaners	innodb_buffer_pool_instances	4
   innodb_parallel_read_threads	可用逻辑处理器 / 8，最小默认值为 4	4
   innodb_purge_threads	如果可用逻辑处理器 <= 16，则为 1，否则为 4	4
   innodb_read_io_threads	可用逻辑处理器 / 2，最小默认值为 4	4
   innodb_use_fdatasync	ON	OFF
   temptable_max_ram	总内存的3%，默认值范围1-4 GiB	1073741824 (1 GiB)
   temptable_max_mmap	0，表示关闭	1073741824 (1 GiB)
   temptable_use_mmap(在 MySQL 8.0.26 中已弃用。)	OFF	ON

2.2 二进制包

1. 添加了对 Fedora 40 和 Ubuntu 24.04 的支持

2.3 组复制

1. 当重新加入组的成员有要在 group_replication_applier 通道上应用先前参与该组的事务时，当该成员在分布式恢复期间连接到捐赠者之前重新加入时，将应用这些事务。
   可以使用 Performance_schema.replication_applier_status_by_worker 表来监视要应用的事务积压，但错误日志中没有有关它的信息，这可能会导致服务器已停止的错误印象。
   现在在这种情况下，其中一条消息：Distributed recovery will wait until the transactions … contained on the group_replication_applier channel are applied or Distributed recovery finished applying the transactions … contained on the group_replication_applier channel 也会根据需要写入错误日志
2. MySQL 组复制现在支持在单主模式下运行时抢占式认证信息垃圾收集。可以使用此版本中添加的 group_replication_preemptive_garbage_collection 系统变量来启用此功能；启用后，仅保留那些尚未提交的事务的写集，这可以节省时间和内存消耗。 group_replication_preemptive_garbage_collection_rows_threshold（也在本版本中引入）设置启用该功能时触发抢占式垃圾收集所需的认证行数的下限；默认值为 100000。
   仅当组复制未运行时，才能更改group_replication_preemptive_garbage_collection的值，并且对多主模式下运行的组没有影响。要从多主模式更改为单主模式，请使用 group_replication_switch_to_single_primary_mode() 函数；

2.4 windows

1. MySQL Windows 二进制文件（.exe 和 .dll 文件）现在在查看其属性时显示附加信息。

2.5 其他

1. 克隆插件版本要求放宽，允许在同一系列的不同点版本之间进行克隆。换句话说，只有主要版本号和次要版本号必须匹配，而以前点版本号也必须匹配。
   例如，克隆功能现在允许将 8.4.0 克隆到 8.4.14 以及将 8.0.51 克隆到 8.0.37。对于 8.0，之前的限制仍然适用于 8.0.37 之前的版本，因此不允许将 8.0.36 等克隆到 8.0.42，反之亦然。
2. 当对 EXPLAIN FORMAT=JSON 使用基于迭代器的格式时（即，当explain_json_format_version 为 2 时），输出现在包含一个用于标识语句类型（select、insert、delete 等）的 query_type 字段。