MySQL Shell 8.0.30 的变化（2022-07-26，全面上市）

MySQL Shell 8.0 发行说明 / MySQL Shell 8.0.30 的变化（2022-07-26，全面上市）

MySQL Shell 8.0.30 的变化（2022-07-26，全面上市）

修复了 AdminAPI 错误

当从 InnoDB ClusterSet 中删除副本集群时，如果副本集群只有一个成员（主要成员），则不会执行视图更改日志事件的协调。如果该实例随后用于创建一个新的副本集群，它包含额外的事务，这意味着复制无法与 InnoDB ClusterSet 中的其他集群发生。当副本集群解散时，即使只有一个成员，视图更改日志事件现在也总是协调的。（缺陷号 34069295）
在使用 AdminAPI 创建的 MySQL 沙箱实例上，会启动一个辅助 MySQL Shell 实例来进行 AdminAPI 操作。MYSQLSH_JSON_SHELL以前，使用环境变量将辅助 MySQL Shell 实例置于 JSON shell 模式。但是，如果用户的MySQL Shell实例也是JSON shell模式，辅助MySQL Shell实例返回给它的错误信息无法解析，因为它们已经被包裹在JSON文档中，所以不会显示给用户。沙盒实例上的辅助 MySQL Shell 实例现在不使用 MYSQLSH_JSON_SHELL 环境变量。（缺陷号 34066667）
使用 clusterSet.setPrimaryCluster() 命令或 clusterSet.rejoinCluster() 命令时，目标集群上设置的不同 GTID 未协调，因为在此过程中过早过滤掉了视图更改事件。如果二进制日志被清除，则无法修复这种情况，集群无法继续在 InnoDB ClusterSet 中运行。GTID 集协调过程现已修复。（缺陷号 34013718）
ClusterSet.status()对于具有一个或多个不可访问成员且少于可接受的在线成员阈值的 ClusterSets，返回 OK_NO_TOLERANCE而不是返回。OK_NO_TOLERANCE_PARTIAL（缺陷号 33989031）
如果检测到过时的路由器实例，则无法停止 InnoDB 集群元数据升级。当提示是否继续升级时，无论用户的选择如何，都会执行升级。（缺陷号 33941759）
AdminAPI 的 Cluster.rescan() 命令没有识别 MySQL 8.0.27 中引入的新版本的 Group Replication 通信协议。该命令现在提供对可用的新通信协议的升级。（缺陷号 33922830）
InnoDB Cluster 命令在执行操作之前验证目标实例是否属于集群。当服务器地址与集群元数据中注册的服务器实例进行比较时，主机名使用区分大小写进行比较，这与 RFC 1034 中的域名比较规则相反。这可能导致目标实例未被识别为集群的一部分。现在使用不区分大小写的比较来检查主机名。（缺陷号 33893435）
Cluster.dissolve()如果集群已使用该 force选项从 ClusterSet 中删除，则不会清除与集群关联的元数据和配置。

从此版本开始，Cluster.dissolve() 确保删除所有恢复和 ClusterSet 复制帐户，并删除元数据模式。（缺陷号 33239404）
尽管它已经是 ReplicaSet 的成员，但仍可以将实例添加到集群中。当实例从 ReplicaSet 中移除并添加到集群时，没有生成错误。从这个版本开始，会生成一个错误并且操作失败。（缺陷号 31964273）
报告的replicationLag值 Cluster.status()未正确计算。

截至此版本，它返回以下内容之一：
- 最后一个事务提交时间戳和最后一个事务应用时间戳之间的时间差，格式为 HH:MM:SS。
  
  如果使用多个工作人员，则从执行最旧事务的工作人员中检索该值。
- null: 复制连接或 SQL 线程未运行。
- applier_queue_applied: 应用程序队列已应用所有内容。即，如果最后排队的事务和最后申请的事务相同，或者申请的事务为0。
有关详细信息，请参阅使用检查集群的状态Cluster.status()。（错误#31693765、错误#106826、错误#34002328）
InnoDB Cluster Cluster.status() 命令没有检查服务器实例是否已通过设置 offline_mode系统变量手动进入离线模式。该命令现在检查这种情况并报告模式，就 n/a好像已设置系统变量一样。

它还会报告警告，例如：
```
        "instanceErrors": [
                    "WARNING: Instance has offline_mode enabled."
         ],
```
（错误#107057，错误#34109382）
如果在实例从 ReplicaSet 中删除并更改后尝试将实例重新加入 ReplicaSet，则 MySQL Shell 意外关闭 server_uuid。

从此版本开始，该rejoinInstance 命令确保元数据模式使用新的 server_uuid. （错误#106847，错误#34038210）

添加或更改的功能

MySQL Server 8.0.30 引入了 GIPK 模式， Generated Invisible Primary Keys。在这种模式下运行时，对于任何没有显式主键创建的 InnoDB 表，MySQL 服务器会自动将生成的不可见主键 (GIPK) 添加到表中。通过设置 sql_generate_invisible_primary_key 为 ON 启用此模式。

MySQL Shell 的加载实用程序选项 createInvisiblePKs使用服务器的 GIPK 模式为没有主键的表生成不可见的主键。

在某些情况下，如果用户没有足够的权限使用 GIPK 模式，MySQL Shell 可以回退到以前生成不可见主键的方法。

有关详细信息，请参阅转储加载实用程序。（缺陷号 34409792）
util.checkForServerUpgrade"ocimds": true如果定义了转储选项并且目标实例是 MySQL 5.7 ，则现在由任何转储实用程序自动运行。

有关的详细信息 util.checkForServerUpgrade，请参阅升级检查器实用程序。有关转储实用程序的更多信息，请参阅实例转储实用程序、架构转储实用程序和表转储实用程序。（缺陷号 34052980）
MySQL Shell 8.0.30 支持 MySQL 8.0.27 中引入的组复制通信栈。这允许更简单和更安全的设置，因为它废弃了 IP 白名单的使用，消除了对用于内部 GCS 通信的另一个网络地址的明确需求，并引入了基于用户的身份验证。

此补丁通过以下方式在 AdminAPI 中添加了对新通信堆栈的支持：
- 添加支持以选择在创建集群或副本集群时必须使用哪个 GR 通信堆栈，方法是公开一个名为 communicationStacksupporting XCOM或的新选项MYSQL。
- EnsuresMYSQL是运行 MySQL 8.0.27 或更高版本的集群使用的默认通信堆栈。
- addInstance自动透明地生成和设置集群创建时通信堆栈和拓扑更改 ( / rejoinInstance/ ) 所需的所有配置rescan，无需用户干预。
- 通过公开一个名为 switchCommunicationStack.
- 允许通过使用新选项扩展命令来设置group_replication_local_addressin 的值。 Cluster.rejoinInstance()localAddress
- 添加一个新的签入Cluster.rescan()以验证是否有任何集群成员使用不是为自己创建的恢复帐户，并确保使用正确的帐户。这确保属于该类别的实例（添加了克隆恢复和 waitRecovery:0）能够自动重新加入集群。
- 扩展Cluster.rejoinInstance()and dba.rebootClusterFromCompleteOutage()以包含ipAllowList和 localAddress选项。
- 扩展Cluster.rejoinInstance()并 dba.rebootClusterFromCompleteOutage()执行集群合规性的实例检查 Cluster.addInstance()。
- Extends Cluster.status({extended:1}), ClusterSet.status({extended:2}), 并 Cluster.options()返回 communicationStack值。
笔记

从此版本开始， group_replication_tls_source不得设置为mysql_admin.
新选项 logSql/--log-sql使您能够将 MySQL Shell 命令或实用程序执行的所有 SQL 语句记录到 MySQL Shell 日志文件中。

笔记

此选项弃用dba.logSql.

有关详细信息，请参阅 MySQL Shell 日志记录和调试。
MySQL Shell 支持兼容 S3 的云存储服务、AWS S3 和 Oracle Cloud Infrastructure 的 S3 兼容 API。

请参阅MySQL Shell 实用程序。

修正错误

在某些情况下，从某些兼容数据库转储实例以进行迁移时，在分块期间返回以下错误：
```
        ERROR: [Worker004]: Error while chunking `xxxx`.`xxxx`: get_uint(8): field type is String
```
（缺陷号 34206985）
每个块中加载的行数未写入进度文件。（缺陷号 34201239）
在某些情况下，loadDump 在语句中包含语法错误的转储操作 CREATE USER可能会导致用户密码显示在 SQL 语法错误消息中。

从此版本开始，如果失败的查询包含 IDENTIFIED或PASSWORD 关键字，则引用的字符串将被匿名化。（缺陷号 34141432）
当dryRun为 MySQL Shell 的转储加载实用程序设置选项时util.loadDump()，如果 updateGtidSet选项设置为 replace或append，则gtid_purged目标服务器实例上的系统变量值会更改，尽管空运行并不意味着影响目标服务器。该问题现已解决。（缺陷号 34127069）
在 Linux 系统上，MySQL Shell 的密码存储使用 MySQL 配置实用程序mysql_config_editor作为 Secret Store Helper，前提是系统上安装了 MySQL 客户端包，并且 mysql_config_editor在系统的 PATH 中可用。否则，密码存储功能将不可用，并且 MySQL Shell 的凭证辅助函数将不可用。MySQL Shell 现在捆绑 mysql_config_editor在 Linux 构建中，因此如果系统上未安装 MySQL 客户端包，则可以使用该功能。（缺陷号 34097411）
util.debug.collectDiagnostics如果命令中未包含文件名，则不会产生错误。创建了一个无名的 zip 文件。从此版本开始，如果命令中未包含文件名，则会显示错误并且不会创建 zip 文件。（缺陷号 34048754）
当您shell.create_context 在 MySQL Shell 的 Python 模式下使用该函数为程序创建作用域和上下文包装器时，您现在可以使用该 finalize()函数来要求释放为 shell 上下文中的记录器对象创建的文件句柄。（缺陷号 33988826）
当 MySQL Shell 的实例转储实用程序 util.dumpInstance()、模式转储实用程序 util.dumpSchemas()和表转储实用程序 util.dumpTables()用于转储具有复合主键的表时，分块过程可能会产生filesort优化 ORDER BY子句的操作。在同时转储具有多个块的大表的情况下，该操作可能会导致转储因磁盘空间不足而失败。当一个BETWEEN子句使用相同的下限和上限时会发生这种情况，因此分块过程现在在这种情况下使用替代条件。（缺陷号 33976259）
在使用MySQL Shell的Python API读取日期时间数据时，转换没有考虑到MySQL在某些SQL模式下可以接受无效的日期时间值，导致Python错误。数据现在只在可能的情况下转换为 Python 值，在转换错误的情况下，返回原始值的字符串表示形式。（缺陷号 33972939）
MySQL Shell 的并行表导入实用程序 util.importTable()和转储加载实用程序 util.loadDump()有一个新选项 sessionInitSQL，它允许您指定在每个客户端会话开始时运行的 SQL 语句列表，用于将数据加载到目标 MySQL 实例中。您可以使用此选项更改会话变量。如果在运行 SQL 语句时发生错误，导入将停止并返回一条错误消息。（缺陷号 33969606）
在d_type成员不出现在dirent结构中的文件系统中，GCC 8.4.0 之前的版本无法检测文件类型。MySQL Shell 会忽略文件类型未知的文件，因此如果它是使用受影响的 GCC 版本编译的，则无法加载存储在此类文件系统上的转储。现在，MySQL Shell 检查它自己的 GCC 版本，如果它受到影响，则使用该 stat()函数来确定文件类型。（缺陷号 33951851）
随着 shell.prompt()MySQL Shell 8.0.29 对 MySQL Shell 功能的扩展，生成的 JSON 文档不再在末尾包含一个新行，以便识别文档的末尾并读取后续的用户输入。该问题现已解决。（缺陷号 33949419）
shell.reconnect()如果在没有全局会话的情况下调用，则 MySQL Shell 意外关闭。（缺陷号 33945641）
使用 X DevAPICollectionModify 对象时，接受文档路径作为参数的方法无法正确处理包含空格的参数。例如，以下尝试删除名为的属性 some：
```
        col.modify("_id='1'").unset("some path")
```
带空格的路径必须使用路径表达式指定或使用反引号字符引用。例如：
```
        col.modify("_id='1'").unset("$.'some path'")
```
或者
```
        col.modify("_id='1'").unset("`some path`")
```
从此版本开始，包含未使用路径表达式正确定义的空格的路径（例如some pathor 'some path'）将被视为错误。（错误#33795166，错误#33795149）
MySQL Shell 8.0.28 和 8.0.29 的通用 Linux 包由于间接依赖于 krb5SSH 支持的库而返回错误。该库现在与 MySQL Shell 捆绑在一起，捆绑版本优先于任何系统版本。（缺陷号 33787652）
/n在 Python 或 JavaScript 模式下，如果 MySQL Shell 以 --json. 返回错误。（缺陷号 33678846）
MySQL Shell 的实例转储实用程序 util.dumpInstance()、模式转储实用程序 util.dumpSchemas()和表转储实用程序 util.dumpTables()通过分块和使用分段上传将大文件上传到 Oracle 云基础设施对象存储桶。如果转储操作被用户取消或由于线程中的异常而停止，则已经开始的分段上传将在存储桶中保持活动状态。这些实用程序现在会尝试在这些情况下停止任何等待完成的分段上传。（缺陷号 32583524）
MySQL Shell 的升级检查器实用程序 util.checkForServerUpgrade()现在检查生成的列上使用的索引 CONVERT()，这改变了它在 MySQL 8.0.28 中的行为，并警告您检查依赖于以前行为的应用程序。（错误#106419，错误#33840716）
升级检查器实用程序返回空表名和孤立表错误。从这个版本开始，该实用程序会分析innodb_sys_tables表中是否存在孤立表。（错误#106372，错误#33822225）
在 5.7 到 8.0 的升级检查期间，升级检查器实用程序针对使用保留名称（如、或）创建的 MySQL 5.7 模式或表名LPT3引发 AUX错误PRN。这些是 INFORMATION_SCHEMA.INNODB_SYS_TABLES通过附加@@@到他们的名字来注册的。但是，它们的原始名称在TABLES. 升级检查器针对此类表引发了模式一致性错误。（缺陷 #105958，缺陷 #33707127）