升级到 MySQL 9.7 之前，先把 my.cnf 里这两个复制变量清掉
从 8.0 或 8.4 直接升级到 MySQL 9.7 时，最容易让 mysqld 无法启动的原因往往不是数据目录，而是 my.cnf 里还留着已经消失的变量。9.7 删掉的两个系统变量都与复制有关：replica_parallel_type 和 group_replication_allow_local_lower_version_join。
参考文档：
被移除的变量
9.7 的 “Features Removed” 一节明确列出服务器系统变量和状态变量的移除清单，上面两个变量在其中：
group_replication_allow_local_lower_version_joinreplica_parallel_type
这两个变量在 9.7 中已不存在。需要注意，replica_parallel_type 在 8.0 里的取值是 LOGICAL_CLOCK / DATABASE；8.0.27 起 DATABASE 取值本身已被弃用。9.7 则直接移除了整个变量。
被弃用的变量
9.7.0 弃用了 enable_cascade_triggers。这个变量是在 9.7.0 新增的同时被弃用的，它控制外键级联时子表触发器是否执行，默认值为 OFF；当 innodb_native_foreign_keys=ON 时该功能无效，因为它只支持 SQL 层外键。
9.7.2 release notes 又追加了两个组复制相关的弃用项（WL #17300，计划在后续版本移除）：
group_replication_communication_stackgroup_replication_ip_allowlist
弃用并不是移除。这两个变量在 9.7 中仍可使用，但升级到后续版本后可能失效。如果现有配置或自动化脚本依赖它们，就需要提前留意。
残留配置的后果与升级前检查
MySQL 启动时遇到未知系统变量，通常会报 unknown variable 然后退出。把已移除的变量留在 my.cnf 里，mysqld 就无法启动，日志里只会留下一条变量不存在的报错，排查时容易误判成权限或数据目录问题。
升级前可以用 MySQL Shell 的 util.checkForServerUpgrade() 做一次检查，它会扫描配置与实例状态，指出不兼容项。另外，建议单独扫描一遍配置文件，排查不在 my.cnf 主文件时容易漏掉的 !include 和 !includedir 引入片段：用 grep -rn 查找 replica_parallel_type、group_replication_allow_local_lower_version_join、group_replication_communication_stack、group_replication_ip_allowlist 四个名字，逐个确认。
并行复制的替代配置
replica_parallel_type 被移除后，并行复制不能再靠它切换模式。方向上是改用 replica_parallel_workers 与 replica_preserve_commit_order 的组合来控制并行度与提交顺序。具体取值和组合行为需自行核对对应版本文档；不同小版本间的默认值与语义有差异，不要直接照搬 8.0 的经验值。
9.7.0 / 9.7.2 其他需要注意的变化
- 版本号从 9.7.4 起改为四段
MAJOR.MINOR.PATCH.UPDATE；新增VERSION_WITH_UPDATE()、version_with_update变量与mysqld --version-with-update。VERSION()、version、mysqld --version仍返回三段。解析版本字符串的监控和部署脚本要跟着调整。 - GIPK 相关：
UNIQUE NOT NULL视为 Primary Key-equivalent。 - Hypergraph Optimizer 进入社区版，通过
optimizer_switch='hypergraph_optimizer=on'开启。 - SCRAM-SHA-1（LDAP SASL）自 9.5.0 起弃用，默认改为 SCRAM-SHA-256。
- 9.7.2 中
thread_pool_max_unused_threads默认值从 2 改为 32。
升级路径上，被移除的变量必须在启动新版本前从配置里删除，被弃用的变量则要安排替换计划。这两步做完，再考虑并行复制的参数调整。