EMQX 5.9 已知问题

e5.9.0

始于版本	问题描述	解决方法	状态
5.0.0	集群中路由表与会话注册表可能出现不一致 在集群发生网络分区恢复、节点非正常关闭或清理过程中 RPC 超时等情况后，路由表和全局会话（Channel）注册表中可能残留陈旧条目或丢失正常条目。已知表现包括： - 网络分区恢复后，副本节点（Replicant）上的订阅路由可能未能完全重新同步，导致部分订阅静默丢消息，直到对应节点重启才能恢复。 - 网络分区恢复后，副本节点上的 Channel 可能从全局会话注册表中丢失，进而导致会话接管行为异常（重新连接的客户端无法替换其旧会话）以及 Dashboard 中客户端计数失真。 - 当会话所有者进程异常结束且未完成清理性注销（例如出现短暂网络分区导致注销消息无法复制，或在 down-event 清理过程中核心节点的一致性检查超时），如果同名客户端 ID 不再连接，注册表中的该条目可能永久残留。随着时间推移，这类失效条目会持续累积。 相关修复已在更新的发布线中合入，但不会回移植到 5.9。详见 emqx/emqx PR #17076、#17257 与 #17522。	请升级至 5.10.4+、6.1.2+ 或 6.2.1+
5.0.0	Linux 单调时钟回调导致 EMQX 节点重启 在某些虚拟 Linux 环境中，操作系统无法保持时钟的单调性，这可能会导致 Erlang VM 因为错误消息 OS monotonic time stepped backwards! 而退出。	对于这类环境，可以在 etc/vm.args 中将 +c 标志设置为 false。
5.3.0	基于 SAML 的单点登录限制 EMQX Dashboard 支持基于安全断言标记语言（SAML）2.0 标准的单点登录（SSO），并与 Okta 和 OneLogin 作为身份提供商集成。然而，基于 SAML 的 SSO 目前不支持证书签名验证机制，并且由于其复杂性，无法与 Azure Entra ID 兼容。	-
5.1.0	新增核心节点时，复制节点在启动阶段可能出现启动失败 在涉及新增核心节点的集群变更过程中，新加入的核心节点有时可能无法正确启动复制节点所依赖的复制相关进程，进而导致升级后的或新添加的复制节点在启动时发生启动失败。 在 Kubernetes 部署中，这种情况会导致复制节点的就绪探针检查失败，从而被控制器不断地终止并重启复制节点的 Pod。 该问题通常出现在升级过程中，例如在原有的“两个核心节点 + 两个复制节点”集群基础上，添加两个运行新版 EMQX 的核心节点和两个复制节点时。	如果一个或多个复制节点在（重新）部署后启动时出现启动失败的情况，可以尝试依次强制重启新添加的核心节点，直到复制节点解除卡顿并完成启动。	已在 6.0.1 中修复
5.7.0	集群连接垃圾回收可能会移除活动路由 当配置了多个独立的集群连接，并且其中一些连接长时间处于离线状态时，垃圾回收过程可能会错误地从内部路由表中移除仍然有效的路由。 这可能导致受影响的集群连接仅转发部分消息，或完全停止转发消息。	-