MySQL Shell 8.0.20 的变化（2020-04-20，全面上市）

MySQL Shell 8.0 发行说明 / MySQL Shell 8.0.20 的变化（2020-04-20，全面上市）

MySQL Shell 8.0.20 的变化（2020-04-20，全面上市）

AdminAPI 添加或更改的功能

MySQL Shell 现在使您能够使用 AdminAPI 操作创建和配置 InnoDB Cluster、InnoDB ReplicaSet 和 MySQL Router 所需的 MySQL 用户帐户。以前，InnoDB Cluster 和 InnoDB ReplicaSet 所需的帐户必须使用clusterAdmin选项配置，而 MySQL Router 所需的帐户必须使用 SQL 手动配置。现在可以使用以下 AdminAPI 操作：
- 使用 Cluster.setupAdminAccount(user, [options])和 Replicaset.setupAdminAccount(user, [options])配置具有管理 InnoDB Cluster 或 InnoDB ReplicaSet 所需权限的 MySQL 用户帐户。
- 使用 Cluster.setupRouterAccount(user, [options])和 Replicaset.setupRouterAccount(user, [options])创建 MySQL 用户帐户或升级现有帐户，以便 MySQL Router 可以使用它在 InnoDB Cluster 或 InnoDB ReplicaSet 上运行。这是现在推荐的添加 MySQL 路由器帐户以与 InnoDB Cluster 和 InnoDB ReplicaSet 一起使用的方法。
AdminAPI 现在使用锁定机制来避免不同的操作同时对 InnoDB ReplicaSet 执行更改。以前，MySQL Shell 的不同实例可以同时连接到 InnoDB ReplicaSet 并同时执行 AdminAPI 操作。这可能会导致不一致的实例状态和错误，例如，如果 ReplicaSet.addInstance() 和 ReplicaSet.setPrimary() 是并行执行的。

现在，InnoDB ReplicaSet 操作具有以下锁定：
- dba.upgradeMetadata()并且 dba.createReplicaSet()是全球独家经营。这意味着如果 MySQL Shell 在 InnoDB ReplicaSet 上执行这些操作，则不能对 InnoDB ReplicaSet 或其任何实例执行其他操作。
- ReplicaSet.forcePrimaryInstance() 并且 ReplicaSet.setPrimaryInstance() 是改变主要的操作。这意味着如果 MySQL Shell 对 InnoDB ReplicaSet 执行这些操作，则在第一个操作完成之前，不能执行其他更改主或实例更改操作的操作。
- ReplicaSet.addInstance(), ReplicaSet.rejoinInstance()，并且 ReplicaSet.removeInstance() 是改变实例的操作。这意味着如果 MySQL Shell 在实例上执行这些操作，则该实例将被锁定以进行任何进一步的实例更改操作。然而，这个锁只在实例级别，InnoDB ReplicaSet 中的多个实例可以同时执行一个这种类型的操作。换句话说，对于 InnoDB ReplicaSet 中的每个实例，一次最多可以执行一个实例更改操作。
- dba.getReplicaSet()并且 ReplicaSet.status() 是 InnoDB ReplicaSet 读取操作并且不需要任何锁定。
参考资料：另请参阅：Bug #30349849。
使用该--replicaset选项将 MySQL Shell 配置为在启动时使用 InnoDB ReplicaSet。您必须指定与副本集实例的连接才能使此选项正常工作。如果找到副本集，此选项将填充rs全局对象，然后可以使用该对象与 InnoDB ReplicaSet 一起使用。作为此添加的一部分， --redirect-primary和 --redirect-secondary选项已更新为也可与 InnoDB ReplicaSet 一起使用。

在运行 MySQL Shell 时，使用来检查目标实例是否属于 InnoDB Cluster 或 InnoDB ReplicaSet。如果是这样，MySQL Shell 打开一个新的会话到主会话，将全局会话设置为已建立的会话并返回它。如果没有提供，则使用当前的全局会话。 shell.connectToPrimary([connectionData, password])connectionData

修复了 AdminAPI 错误

在使用 MySQL Clone 的分布式恢复期间，实例会在数据文件被克隆后重新启动，但如果实例必须应用大量事务积压日志来完成恢复过程，则重新启动过程可能需要比默认的 1 分钟更长的时间暂停。现在，当有大量积压日志时，使用该dba.restartWaitTimeout 选项配置更长的超时以确保应用进程有时间处理事务。（缺陷号 30866632）
如果您尝试删除不存在的沙箱，该dba.deleteSandboxInstance()操作不会提供错误。现在，在这种情况下， dba.deleteSandboxInstance()操作会抛出一个runtimeError. （缺陷号 30863587）
该 Cluster.forceQuorumUsingPartitionOf() 操作不会在不属于目标实例可见成员资格的任何可访问实例上停止组复制，如果这些实例中的任何一个自动重新加入集群，这可能会导致未定义的行为。该修复程序会在任何不包含在新的强制仲裁成员资格中的可访问实例上停止组复制。（缺陷号 30739252）
AdminAPI 有可能选择一个无效的实例作为最新的主实例，尽管它具有较低的 view_id. 这是因为如果它是 InnoDB ReplicaSet 中的最后一个实例，则获取 InnoDB ReplicaSet 的主节点的过程会错误地重新连接到无效的成员。（缺陷号 30735124）
当使用低于8.0.19版本的MySQL Shell创建的集群离线时（例如实例服务器升级后），如果您随后使用MySQL Shell 8.0.19连接集群， dba.upgradeMetadata()并 dba.rebootClusterFromCompleteOutage()相互阻塞。您无法运行 dba.upgradeMetadata()，因为它需要 dba.rebootClusterFromCompleteOutage()先运行才能使集群重新联机。你不能跑dba.rebootClusterFromCompleteOutage() ，因为dba.upgradeMetadata()没有被跑过。为避免此问题，请升级到 MySQL Shell 8.0.20，其中前提条件为 dba.rebootClusterFromCompleteOutage()和 dba.forceQuorumUsingPartitionOf()已更新以确保它们与使用早期版本创建的集群兼容。换句话说，即使元数据是使用较旧的 MySQL Shell 版本创建的，它们也是可用的。（缺陷号 30661129）
如果目标实例不支持，使用 MySQL Clone 作为分布式恢复方法将实例添加到 InnoDB ReplicaSet 会导致分段错误 RESTART。现在， ReplicaSet.addInstance() 操作会在这种情况下中止，并在达到连接超时限制后恢复更改。这是因为添加操作需要连接到目标实例才能完成操作。在这种情况下，如果无法将实例升级到支持的 MySQL 版本， RESTART则必须手动重启服务器，然后发出 ReplicaSet.addInstance() 再次重试。然后重试可以使用增量恢复，这不会触发克隆和后续重启。（缺陷号 30657911）
Cluster.addInstance() 如果添加的实例中存在错误的 GTID，通常会失败，但如果 MySQL 克隆用于分布式恢复，则该检查将被绕过，因为克隆过程修复了问题。但是，如果所有成员都使用 IPv6，则无法使用 MySQL Clone，因此改为使用增量恢复。在这种情况下，实例被无误地添加到集群中，但错误的事务仍然存在。现在，如果集群的所有在线实例都使用 IPv6 地址并且操作尝试使用 MySQL Clone 进行分布式恢复，则会抛出错误。（缺陷号 30645697）
当 InnoDB Cluster 或 InnoDB ReplicaSet 使用 MySQL Clone 插件时，AdminAPI 确保 performance_schema.clone_status在克隆过程开始时清除表。但是，在一些罕见且非常具体的情况下，可能会发生竞争条件，并且在实际清除表之前克隆操作被认为正在运行。在这种情况下，MySQL Shell 克隆监控可能会导致意外停止。

作为此修复的一部分，还修复了在克隆过程极快时很少发生的克隆监视阶段的潜在无限循环。（缺陷号 30645665）
Group Replication 系统变量查询被提前执行，没有考虑是否安装了 Group Replication 插件。现在，重启操作已得到修复，如果系统变量查询失败， ER_UNKNOWN_SYSTEM_VARIABLE则会自动安装 Group Replication 插件。（缺陷号 30531848）
该操作未正确处理以下情况： Cluster.removeInstance(instance)
- 如果实例已 report_host设置为与元数据中不同的值，instance_name则使用其 IP 指定实例失败。
- 如果实例不可访问，并且给定地址与元数据中的地址不匹配，则无法将其删除。
- 当实例OFFLINE可访问时（例如，因为组复制停止但服务器仍在运行），失败。现在，在这种情况下，如果您确定删除实例是安全的，请使用该选项，这意味着不再尝试将同步作为删除操作的一部分。 Cluster.removeInstance(instance)force=true
- 如果该实例是OFFLINE可访问的，则通过与元数据中的内容不匹配的地址删除该实例将使操作看起来成功，但该实例实际上并未从元数据中删除。
（错误#30501628，错误#30625424）
在删除实例或解散集群等操作后，group_replication_recovery并 group_replication_applier没有删除复制通道。（错误#29922719，错误#30878446）
MySQL 选项文件的默认位置，例如，在某些平台（Debian 等）上/etc/my.cnf停止被运行检测到。dba.configureInstance()这是一种倒退。此修复可确保选项文件的预定义路径与默认路径相匹配，例如/etc/my.cnf和 /etc/mysql/my.cnf。（缺陷 #96490，缺陷 #30171324）

添加或更改的功能

shell.openSession全局对象中提供了一个新方法shell，让您创建并返回一个会话对象，而不是将其设置为 MySQL Shell 的全局会话。
您现在可以请求压缩使用 X 协议的 MySQL Shell 连接，以及使用经典 MySQL 协议的连接。对于 X 协议连接，默认情况下请求压缩，如果压缩连接的协商不成功，则允许未压缩的连接。对于经典的 MySQL 协议连接，默认情况下禁用压缩。建立连接后，MySQL Shell\status命令会显示会话是否正在使用压缩。

MySQL Shell 中的新压缩控件允许您在连接参数中指定压缩是必需的、首选的还是禁用的，为连接选择压缩算法，并为算法指定数字压缩级别。

修正错误

当您为 MySQL Shell 创建扩展对象 options时，当您指定数据类型为“字典”的参数时，不再需要密钥。如果您确实为字典定义选项，MySQL Shell 会验证最终用户指定的选项，并在将选项传递给不在此列表中的函数时引发错误。如果您创建一个没有选项列表的字典，则最终用户为该字典指定的任何选项都将由 MySQL Shell 直接传递给该函数，而无需验证。（缺陷号 30986260）
MySQL Shell 8.0.19 中的一个错误，仅影响经典 MySQL 协议连接，这意味着如果用户使用 MySQL Shell 存储连接密码并随后更改它，则访问将被拒绝。密码存储现在删除无效密码并按预期向用户显示密码提示。（缺陷 #30912984，缺陷 #98503）
当以交互方式使用MySQL Shell的\source命令执行脚本文件中的代码时，脚本文件中的多行SQL语句会导致MySQL Shell进入重复执行脚本的循环。该问题现已解决。（漏洞 #30906751，漏洞 #98625）
如果在 MySQL Shell 中调用存储过程但未使用其结果，则任何后续 SQL 语句都会返回结果集错误，此时退出 MySQL Shell 会导致错误关闭。MySQL Shell 清除了存储过程检索到的第一个结果集，以便运行后续的 SQL 语句，但没有检查已检索到的任何其他结果集，这些结果集被留下并导致了错误。现在执行此检查，并在执行另一个语句之前丢弃额外的结果集。（缺陷号 30825330）
由于 MySQL Shell 8.0.19 中的回归，checkForServerUpgrade()如果连接数据未作为第一个参数提供，则升级检查器实用程序不接受任何运行时选项。该问题已得到修复，实用程序的参数检查已得到增强。（缺陷号 30689606）
MySQL Shell 现在捆绑了 Python 3.7.4，无法使用 Python 3.8 从源代码构建。不兼容性现已得到纠正，因此可以使用 Python 3.8。（缺陷号 30640012）
MySQL Shell 的升级检查器实用程序 checkForServerUpgrade()没有标记使用连字符而不是下划线指定的已删除系统变量。如果无法在要求的时间执行权限检查，该实用程序现在还会继续其检查序列。（缺陷 #30615030，缺陷 #97855）
MySQL Shell 的\status命令显示，如果连接是在启动 MySQL Shell 时创建的，则连接被压缩，但如果连接是在启动 MySQL Shell 后创建的，则不会。现在在两种情况下都显示压缩。（漏洞 #29006903）