操作的输出status()已扩展为提供更多与诊断错误相关的信息。以下信息适用于 InnoDB 集群和 InnoDB 副本集：

有关详细信息，请参阅 使用检查集群的状态Cluster.status()。

InnoDB Cluster 和 InnoDB ReplicaSet 现在支持并启用并行复制应用程序，有时称为多线程副本。随着 MySQL 的进步，例如二进制日志事务依赖跟踪和基于 XXHASH64 的 GTID 集提取，使用多个副本应用程序线程提高了复制应用程序和增量恢复的吞吐量。

这导致了以下变化：

Bug#29305551 的修复扩展了 dba.checkInstanceConfiguration()操作以包括检查以验证异步复制是否已配置并在目标实例上运行，并在出现这种情况时打印警告。Cluster.addInstance() 当检测到这种情况时，操作和 Cluster.rejoinInstance() 操作 也使用此检查 来终止它们，并且dba.rebootClusterFromCompleteOutage() 只要有实例要重新加入集群，操作也会使用此检查。但是，该dba.createCluster() 操作错误地跳过了检查，并且 dba.rebootClusterFromCompleteOutage() 操作跳过了对用于引导集群的实例的检查。该修复确保在创建集群或从完全中断中重新启动集群时也执行检查。dba.createCluster()此外，它通过使用该选项增加了对覆盖操作检查的支持force，并改进了错误消息。（缺陷号 32197222）

Bug#29305551 的修复扩展 dba.checkInstanceConfiguration()为验证异步复制是否已配置并在目标实例上运行，如果是这种情况则打印警告。但是，检查没有验证复制通道是否已配置但未运行。此修复确保验证还考虑已配置但未主动运行的复制通道。此外，一条建议使用STOP REPLICA来覆盖此检查的可能性的错误消息已被删除并替换为一条信息性消息，该消息解释了不支持非托管复制通道以及使用它们可能存在的危险。（缺陷号 32197197）

根据 WL# 14189 中的术语更改，AdminAPI 已与新术语保持一致。错误和日志消息现在使用术语源（以前是主）和副本（以前是从）。（缺陷号 32152133）

在 Cluster.rebootClusterFromCompleteOutage() 操作期间，GTID 超集用于检测应该使用哪个实例来重启集群。如果一个实例有一个发散的 GTID 集，而你想明确地将它从集群中删除，操作就会被阻止，因为它无法确定哪个实例有 GTID 超集。以前，在这种情况下，无法从用于检测 GTID 超集的实例中排除该实例。现在，如果您在交互式向导中回答否，或配置该 removeInstances选项，则在查找 GTID 超集时不会检查该实例。（缺陷号 32112864）

当一个实例离开了 ReplicaSet，然后它的配置被更改为使其对 InnoDB ReplicaSet 使用无效的方式时，该 ReplicaSet.rejoinInstance() 操作没有检测到配置无效。现在，检查实例以确保它们在重新加入 ReplicaSet 之前有效。（错误号 31975416）

使用 升级元数据时 dba.upgradeMetadata()，如果有需要升级的MySQL Router实例，则等待所有实例升级后再继续。该操作为您提供了重新检查过时的 MySQL Router 实例并继续元数据升级的选项。MySQL Router 升级仅在应用程序重新启动后才完成，但打印的消息并未提及这一点。此消息现在包含升级二进制文件后必须重新启动 MySQL Router 实例的信息。（缺陷号 31882876）

当您连接到辅助实例时，尝试发出 、 等操作 Cluster.rejoinInstance()将 Cluster.addInstance()失败 Cluster.dissolve() 。现在，AdminAPI 始终连接到当前的主服务器。

作为这项工作的一部分，进行了以下更改：

（缺陷号 31757737）

作为 InnoDB Cluster 默认设置的一部分，为确保实例自动重新加入集群，该 group_replication_start_on_boot 选项自动设置为 true。然而，这意味着在使用外部工具管理集群生命周期的环境中，例如 Kubernetes 等编排器，重新加入的自动启用可能会导致与该工具的冲突。此外，如果在不合适的时间启用了实例的自动重新加入（例如，在重新启动时，或在修复裂脑时等），则可能会发生死锁或长时间冻结，直到发生超时。在某些情况下，实例甚至可能在重新配置期间加入错误的集群。

为了避免这种情况， manualStartOnBoot添加了布尔选项，默认为 false。要禁用实例的自动重新加入，例如在修复裂脑时，请将manualStartOnBoot选项设置为 true。这可以防止实例在您进行更改时自动重新加入集群。然后，您需要手动将实例重新加入集群，然后再将 manualStartOnBoot选项设置回 false 以确保实例再次自动重新加入集群。同样，如果您使用外部编排器来管理实例的生命周期，请将 manualStartOnBoot在整个集群中设置为 true 的选项，以禁用实例自动重新加入集群。然后应将您的协调器配置为手动重新加入实例。（缺陷号 31643595）

调用dba.checkInstanceConfiguration()with verifyMyCnfset 到一个不存在的文件，操作成功完成，表示已检查配置文件。该修复程序检查指定的文件是否verifyMyCnf存在，如果不存在则打印错误，并确保控制台不会显示不必要的错误消息。（缺陷号 31468546）

在 sql_mode变量设置为 的实例上ANSI_QUOTES，尝试升级元数据模式dba.upgradeMetadata() 失败并出现错误：Unknown column 'MySQL Router' in 'field list'。这与使用单引号来引用字符串的查询有关。作为此修复的一部分，升级元数据操作现在准备 AdminAPI 使用的会话，并且在其他完整性检查中，它确保该sql_mode会话使用默认值以避免不兼容的用户配置设置。此外，对 and 操作也进行了同样的 dba.getCluster()操作 dba.dropMetadataSchema()。（缺陷号 31428813）

如果 MySQL Shell 全局会话连接到沙箱实例，并且该实例已停止，则 MySQL Shell 会尝试错误地重新连​​接到该实例。现在，如果活动会话连接到正在停止的沙箱实例，MySQL Shell 将关闭会话。（缺陷号 31113914）

now的输出 Cluster.status() 包括有关在元数据中注册但当前不在线的实例的附加信息。MySQL Shell 现在连接到在元数据中找到的离线实例并尝试对其进行诊断，提供附加信息，例如它们的连接性和状态。（缺陷号 30501615）

属于底层组但未在元数据中标识的实例，例如，因为它们是手动配置并绕过 MySQL Shell，或者因为它们之前已从 InnoDB 集群中删除但未正确停用，现在显示在输出中的 Cluster.status()，以及有关元数据差异的诊断警告。这确保您可以检测实例参与组但未由 MySQL Shell 管理的情况。（漏洞#27882663）

属于 InnoDB Cluster 的实例由其服务器 UUID 标识。如果 UUID 在实例离开集群后更改，例如因为您使用 MySQL Enterprise Backup 从备份中恢复，则实例无法重新加入集群。现在，如果集群遇到这种情况，它会检查元数据以查看是否可以使用其主机和端口来识别实例。如果找到，将根据用于重新加入操作的选项更新元数据。此检查在 Cluster.rejoinInstance() and Cluster.rescan() 操作期间执行。

此外，执行检查以验证 serverId所有实例的 是否在元数据中注册为实例属性。如果不是，则相应地更新元数据。此检查在添加、重新加入和重新扫描操作时执行。（缺陷号 26649039）

MySQL Shell 的并行表导入实用程序现在可以导入指定的输入数据文件列表，它支持通配符模式匹配以包含来自某个位置的所有相关文件。单次运行该实用程序上传的多个文件被放入一个关系表中，因此，例如，从多个主机导出并存储在多个文件中的数据可以合并到一个表中以用于分析。这些文件可以压缩为 gzip 或 zstd 格式，在这种情况下，该实用程序会以压缩格式从存储中读取它们，从而为该部分传输节省带宽。该实用程序然后使用其并行连接解压缩多个文件并将其同时上传到目标服务器。

当 MySQL Shell 的实例转储实用程序 util.dumpInstance()运行时， ocimds选项设置true 为检查与 MySQL 数据库服务的兼容性， users选项设置为true 在转储中包括用户及其角色和授权，该实用程序报告了一些实际允许的权限的兼容性错误. MySQL Shell 的 MySQL 数据库服务允许权限列表现已更新。（缺陷号 32213605）

MySQL Shell 的表转储实用程序 util.dumpTables()和转储加载实用程序 util.loadDump()关于单表转储和加载模式的行为已更改。以前，为单个表生成的转储文件不包含用于重新创建模式的 SQL 语句，因此在转储加载实用程序可以加载表之前，该模式必须存在于目标 MySQL 实例中。现在，由表转储实用程序生成的转储包含模式语句，当使用转储加载实用程序加载它们时，默认情况下，如果模式尚不存在，则会在目标 MySQL 实例中创建它。这 schema选项可用于将表转储加载到目标 MySQL 实例中存在的另一个模式中。使用早期版本的实用程序创建的表转储仍然需要该schema选项和现有架构。（缺陷号 32165101）

MySQL Shell 的表转储实用程序 util.dumpTables()现在支持 ocimds、compatibility、 ociParManifest和 ociParExpireTime选项，因此您可以检查与 MySQL 数据库服务的兼容性，并为转储文件生成预验证的请求 URL。此外，该 ignoreVersion选项已扩展为允许将在没有该 ocimds选项的情况下创建的转储导入 MySQL 数据库系统。（缺陷号 32140970）

如果转储包含使用外部身份验证插件创建的用户， util.loadDump()如果这些插件在目标服务器实例上不可用，则 MySQL Shell 的转储加载实用程序无法加载转储。ocimds用于检查与 MySQL 数据库服务兼容性的 MySQL Shell 实例转储实用程序 util.dumpInstance()和模式转储实用程序 的选项util.dumpSchemas现在检查使用 MySQL 数据库服务不支持的身份验证插件的帐户。兼容性选项有一个额外的修改选项skip_invalid_accounts，可以删除此类用户帐户。（缺陷号 32115948）

以前，如果该选项设置为 true 但提供的转储文件不包含用户帐户，则 MySQL Shell 的转储加载实用程序会 util.loadDump()因错误而停止 。loadUsers该实用程序现在显示警告并在这种情况下继续。（缺陷号 32115861）

MySQL Shell 的 instance dump utility util.dumpInstance()、 schema dump utility util.dumpSchemas()和 table dump utility util.dumpTables()回退到使用 LOCK TABLES权限锁定转储表，如果 consistent 选项设置为 true，这是默认值，并且RELOAD权限不可用。但是，锁定操作可能会导致对活动事务的隐式提交，这意味着数据不会一致地转储。现在已更正锁定以确保这种情况下的一致性。（漏洞 #32107327，漏洞 #101410）

当 MySQL Shell 的转储加载实用程序 util.loadDump()使用索引来识别行边界时，如果索引指向读取缓冲区中的数据之外，则会发生错误。该实用程序现在检查是否存在这种情况，如果是则忽略索引。（缺陷号 32072961）

当 MySQL Shell 试图重新连接到服务器时， Ctrl + C不会中断操作。中断现在起作用并将重试尝试计数器设置为零，以便序列正确退出。（缺陷号 32041342）

MySQL Shell 现在可以使用 Python 3.9 构建。（缺陷号 32020230）

updateGtidSet由于权限限制，MySQL Shell 的转储加载实用程序 的选项util.loadDump()无法与 MySQL 数据库系统一起使用。该实用程序现在使用允许的存储过程，因此可以使用该选项。（缺陷号 32009225）

当 MySQL Shell 的实例转储实用程序 util.dumpInstance()、模式转储实用程序 util.dumpSchemas()或表转储实用程序 util.dumpTables()导出到 Oracle Cloud Infrastructure 对象存储桶时，如果与对象存储服务器的连接或路由丢失，MySQL Shell 会意外停止。该错误现在已得到正确处理。（错误号 32005418）

如果响应中的标头值为空，则MySQL Shell 的转储加载实用程序会 util.loadDump()返回异常。（缺陷号 31979374）

MySQL Shell 没有初始化 Python 3.8 的新 cf_feature_version编译器标志字段，这可能会在使用格式字符串时导致异常。（缺陷号 31926697）

MySQL Shell 使用系统安装的 Python 而不是捆绑版本，MySQL Shell 现在支持的最低版本是 Python 3.6。Python 3.4.3 是以前系统安装的最低要求。捆绑版本为 Python 3.7.7。（缺陷号 31900744）

MySQL Shell 的实例转储实用程序 util.dumpInstance()、模式转储实用程序 util.dumpSchemas()和表转储实用程序 util.dumpTables()使用表统计信息来确定合适的默认行大小。如果表的统计信息已过时或不存在，这可能会导致分块过程出现问题。在这种情况下，MySQL Shell 现在会发出一条消息，建议使用一条ANALYZE TABLE语句来生成最新的统计信息。（缺陷号 31766490）

skipBinlogMySQL Shell 的转储加载实用程序 的选项会util.loadDump()跳过目标 MySQL 实例上的二进制日志记录以进行导入。该选项不适用于 MySQL 数据库系统，因为无法更改二进制日志记录状态，如果在这种情况下使用该选项，导入现在会失败并显示错误消息。对于其他 MySQL 实例，该实用程序现在会检查用户是否具有设置系统变量所需的权限，sql_log_bin 如果没有则失败并显示一条错误消息。（缺陷号 31748786）

MySQL Shell 的实例转储实用程序 util.dumpInstance()、模式转储实用程序 util.dumpSchemas()和表转储实用程序 util.dumpTables()使用表的唯一索引的第一列对提取的数据进行排序。出于分块的目的，使用相同的方法查询数据。这些实用程序现在使用唯一索引的所有列进行排序。此外，通过添加缓存来存储常用的实例元数据，性能得到了提高。一次为所有模式对象填充缓存，而不是根据需要由单个查询填充。（缺陷号 31706755）

MySQL Shell 的断开连接功能被添加到 shell全局对象。（缺陷号 31704380）