MySQL Shell 8.0.16 的变化（2019-04-25，全面上市）

MySQL Shell 8.0 发行说明 / MySQL Shell 8.0.16 的变化（2019-04-25，全面上市）

MySQL Shell 8.0.16 的变化（2019-04-25，全面上市）

AdminAPI 添加或更改的功能

新autoRejoinTries选项使您能够配置实例在被驱逐后尝试重新加入组的次数。在发生网络故障但恢复很快的场景中，设置此选项可以避免您必须手动将被驱逐的实例添加回组。该autoRejoinTries选项接受 0 到 2016 之间的正整数值，默认值为 0，这意味着实例不会尝试自动重新加入。将该值设置为一个有效的整数，以配置被驱逐的实例重新加入该组的尝试次数。您可以将autoRejoinTries选项传递给这些 AdminAPI 操作：
- dba.createCluster()
- Cluster.addInstance()
- Cluster.setOption()
- Cluster.setInstanceOption()
配置autoRejoinTries 选项时，它会设置 group_replication_autorejoin_tries 系统变量。将选项传递给 dba.createCluster()或 Cluster.addInstance() 为 Cluster.setInstanceOption() 特定集群实例配置自动重新加入。传递选项以 Cluster.setOption() 配置所有集群实例的自动重新加入。

有关详细信息，请参阅对故障检测和网络分区的响应。
AdminAPI 现在报告有关实例上运行的 MySQL 版本的信息。此信息可从以下操作获得：
- Cluster.status()
- Cluster.describe()
- Cluster.rescan()
有关详细信息，请参阅检查实例上的 MySQL 版本。
每当使用 AdminAPI 操作更改集群拓扑时，MySQL InnoDB 集群会自动透明地管理其成员的通信协议版本。InnoDB 集群始终使用最新的通信协议版本，该版本由属于集群或加入集群的所有实例支持。
- 当实例加入集群、移除实例、重新加入集群，或对集群进行重新扫描或重启操作时，通信协议版本自动设置为当前最早的MySQL Server实例支持的版本版本。
- 当您通过从集群中删除实例、升级它们并将它们添加回集群来执行滚动升级时，当旧 MySQL Server 版本的最后一个剩余实例在之前从集群中删除时，通信协议版本会自动升级它的升级。
要查看 InnoDB 集群中使用的通信协议版本，请使用启用Cluster.status() 该'extended'选项的功能。通信协议版本在该 'GRProtocolVersion'字段中返回，前提是集群具有法定人数并且没有集群成员不可访问。

修复了 AdminAPI 错误

当要删除的实例没有为 group_replication_recovery通道定义的用户时，从集群中删除一个实例会导致在集群的其余实例上删除用户。（漏洞#29617572）
该failoverConsistency选项已被弃用，并consistency 添加了一个名为 name 的新选项，以使其与目标组复制 group_replication_consistency 系统变量名称更加一致。MySQL Shell 在线文档现在也正确地描述了您可以分配给该 consistency选项的所有值。（漏洞#29356599）
该操作将从提供的选项文件中dba.configureLocalInstance()删除任何不以开头的部分。mysqld这可以从选项文件中删除诸如客户端部分之类的部分。（错误号 29349014）
将禁用 X 插件的实例添加到 InnoDB 集群时，如果稍后使用 Cluster.removeInstance() 操作失败从集群中删除该实例，并出现LogicError "get_string(7): field is NULL"。这是 Bug#27677227 修复引入的回归。（漏洞 #29304183）
关于本地主机和环回地址验证dba.checkInstanceConfiguration()，将实例添加到集群的行为和命令之间存在不一致（dba.createCluster()和）。Cluster.addInstance()特别是，打印了一个简单的错误， dba.checkInstanceConfiguration()但是操作的执行继续显示在操作结束时一切都是正确的，而发出错误并停止执行 dba.createCluster()和 Cluster.addInstance()。

作为解决此问题的一部分，已决定不再需要现有的本地主机和环回地址验证，应该将其删除。特别是，无论为指定什么地址report_host，即使它是本地主机或环回地址 (127.0.0.1)，都应该被允许，因为用户明确指定要使用它。（漏洞#29279941）
该dba.rebootClusterFromCompleteOutage() 操作未保留先前为实例设置的现有组复制配置。特别是，Group Replication 本地地址和退出状态操作值正在更改。现在，在重新启动集群时会读取所有设置。（漏洞 #29265869）
在运行 MySQL 5.7 的实例上使用 Cluster.setOption() 或 Cluster.setInstanceOption() 设置仅存在于 MySQL 8.0 中的选项未被正确捕获。（缺陷号 29246657）
在基于 Debian 的平台（例如 Ubuntu）上，如果主机名解析为 127.0.1.1（这是这些平台上的默认设置），则无法使用默认设置创建集群。现在，在这种情况下，会在创建集群并向其中添加实例之前对实例进行适当的验证。（缺陷号 29246110）
该dba.checkInstanceConfiguration() 操作未验证为集群管理提供的帐户的主机限制，例如，该帐户是否可以实际连接到集群中的所有实例。特别是，如果提供的用户帐户只能通过本地主机连接，现在会发出错误。（漏洞 #29018457）
InnoDB Cluster 已配置 auto_increment_increment并 auto_increment_offset位于以多主模式运行的集群的实例上，并且根据 InnoDB Cluster 和 Auto-increment中描述的逻辑最多包含 7 个实例。但是 Group Replication 允许组最多包含 9 个成员，并且 Cluster.addInstance() 不 Cluster.removeInstance() 遵循用于其他操作的逻辑。现在，无论使用何种操作，InnoDB Cluster 都使用相同的自动递增逻辑，并正确处理超过 7 个实例的多主集群。（漏洞 #28812763）
MySQL Shell 使用提供的连接参数的主机值作为目标主机名用于 AdminAPI 操作，即在元数据中注册实例（用于dba.createCluster()和 cluster.addInstance()操作）。但是，用于连接参数的主机可能与 Group Replication 使用或报告的主机名不匹配， report_host它在定义时使用系统变量的值（换句话说它不是 NULL），否则使用的 hostname值. 因此，AdminAPI 现在遵循相同的逻辑在元数据中注册目标实例并将其作为默认值 group_replication_local_address 实例上的变量，而不是使用实例连接参数中的主机值。在此修复期间，检测到当report_host 变量设置为空时，Group Replication 对主机使用空值，但 AdminAPI（例如，在 , , 等命令中 dba.checkInstanceConfiguration()） dba.configureInstance()将 dba.createCluster()主机名报告为使用的值，这与报告的值不一致通过组复制。report_host如果为系统变量设置了空值，AdminAPI 现在会发出错误。（缺陷号 28285389）
如果dba.createCluster()失败并执行回滚以删除创建的复制（恢复）用户，则创建的帐户 localhost和任何 ipWhitelist地址都不会被删除。该修复程序可确保在 dba.createCluster()执行相关回滚时删除复制帐户。这项工作基于 Bin Hong 的代码贡献。（缺陷 #94182，缺陷 #29308037）

添加或更改的功能

重要更改： 尝试连接到 X 协议端口，默认情况下为 33060，使用经典 MySQL 协议导致以下错误： ERROR 2013 (HY000): Lost connection to MySQL server at 'reading initial communication packet', system error: 0

这是因为 X 协议和经典 MySQL 协议客户端对连接初始化方式的期望不同。现在，在这种情况下，生成的错误消息是ERROR 2007 (HY000): Protocol mismatch; 服务器版本 = 11，客户端版本 = 10。如果您遇到此错误，那么您可能正在尝试为您的客户端使用的协议使用错误的端口。

作为此改进的一部分， mysqlx_enable_hello_notice 已添加系统变量，它控制发送到尝试通过 X 协议连接的经典 MySQL 协议客户端的消息。启用后，不支持 X 协议的客户端尝试连接到服务器 X 协议端口时会收到一条错误消息，说明它们使用了错误的协议。设置 mysqlx_enable_hello_notice为 false 以允许不识别 hello 消息的客户端仍然连接。
MySQL Shell 的升级检查器实用程序现在可以检查服务器实例的配置文件（my.cnf或 my.ini）。该实用程序检查配置文件中定义但已在目标 MySQL Server 版本中删除的任何系统变量，以及配置文件中未定义且在目标 MySQL 中具有不同默认值的任何系统变量服务器发布。对于这些检查，当您调用 checkForServerUpgrade()，您必须提供配置文件的文件路径。如果您省略文件路径并且升级检查器实用程序需要运行需要配置文件的检查，则该检查将失败并显示一条消息通知您必须指定文件路径。（错误#27801824，错误#29222179）
MySQL Shell 现在有一个框架和命令，您可以使用它们来设置和运行报告以显示来自 MySQL 服务器的实时信息，例如状态和性能信息。报告可以使用 MySQL Shell \show命令运行一次，或者运行然后使用命令在 MySQL Shell 会话中连续刷新 \watch。它们也可以作为shell.reports对象中的 API 函数进行访问。

报告工具支持内置报告和用户定义的报告。用户定义的报告可以用支持的脚本语言 JavaScript 和 Python 创建，并且可以在任何 MySQL Shell 模式（JavaScript、Python 或 SQL）中运行，而不管报告是用什么语言编写的。报告可以保存在MySQL Shell 配置路径中的一个文件夹，并在启动时自动加载。您还可以直接在 MySQL Shell 提示符下创建报告。您使用该方法向 MySQL Shell 注册报告以 shell.registerReport提供有关报告及其支持的选项和参数的信息。

有关详细信息，请参阅使用 MySQL Shell 进行报告。
在交互模式下运行 MySQL Shell 时，您现在可以执行 SQL 语句而无需切换到 SQL 模式，然后再切换回来。此功能使您能够以 JavaScript 或 Python 模式在较长的 AdminAPI 工作流程的上下文中方便地发出一些 SQL 语句。使用 \sql紧跟 SQL 语句的命令，例如：
```
\sql select * from sakila.actor limit 3;
```
SQL 语句不需要任何额外的引号，语句分隔符是可选的。使用这种格式，MySQL Shell 不会像您输入 \sql命令那样切换模式。SQL 语句执行后，MySQL Shell 仍处于 JavaScript 或 Python 模式。

\sql在另一种语言处于活动状态时，当您使用带有查询的命令来执行单个 SQL 语句时，您不能使用多行模式。该命令仅在一行中接受单个 SQL 查询。
MySQL Shell 历史现在按发出命令的活动语言拆分。这意味着您的历史记录现在与活动语言匹配，例如，当您以 JavaScript 模式运行 having issued\js时，历史记录包含您之前发出的 JavaScript 语句，而当您\sql更改为 SQL 模式时，您的历史记录包含您之前的 SQL 语句发布。同样，现在任何与历史相关的命令，例如 \history clear或\history delete对当前活动语言的历史执行。安装此版本时，将复制任何现有的 MySQL Shell 历史文件以确保现有历史不会丢失。然后将后续操作添加到特定于语言的历史文件中。

当resultFormat设置为 jsonorjson/raw时，每个结果都作为 JSON 文档返回。当 JSON 包装关闭时，此行为是预期的（换句话说， --json启动 MySQL Shell 时未使用命令选项）。现在，出于一致性原因，当 JSON 包装关闭并resultFormat设置为json或json/raw时，每条记录都打印在单独的文档中，统计信息和警告以纯文本打印。

例如，如果 MySQL Shell 在没有 --jsonand 的情况下启动resultFormat=json/raw：

mysqlsh-sql> SHOW DATABASES;
{"Database":"information_schema"}
{"Database":"mysql"}
{"Database":"performance_schema"}
{"Database":"sys"}
4 rows in set (0.0035 sec)

如果 MySQL Shell 以 --json和启动resultFormat=json/raw：

mysqlsh-sql> SHOW DATABASES;		
{
    "hasData": true,
    "rows": [
        {
            "Database": "information_schema"
        },
        {
            "Database": "mysql"
        },
        {
            "Database": "performance_schema"
        },
        {
            "Database": "sys"
        }
    ],
    "executionTime": "0.0018 sec",
    "affectedRowCount": 0,
    "affectedItemsCount": 0,
    "warningCount": 0,
    "warningsCount": 0,
    "warnings": [],
    "info": "",
    "autoIncrementValue": 0
}

修正错误

MySQL Shell 可以安装在没有 Python 的环境中，但应用程序依赖于许多标准 Python 模块，导致在启动时出现错误消息。MySQL Shell 的 RPM 和 Debian 包现在明确指定了对 Python 的依赖。（漏洞 #29469201）
Windows Installer 用于安装 MySQL Shell 的 MSI 文件现在将应用程序二进制文件 ( mysqlsh ) 的路径添加到 Windows PATH环境变量，以便可以从命令提示符启动应用程序。（漏洞#29457639）
在从源代码构建 MySQL Shell 的说明（ INSTALL文档）中，可选 V8 依赖项的所需版本已从 3.28.71.19 更新到 6.7.288.46。（缺陷 #29430049，缺陷 #94529）
MySQL Shell 的升级检查器实用程序 checkForServerUpgrade()可能会错误地报告名称包含特殊字符（如连字符）的表的架构不一致错误。（缺陷 #29346836，缺陷 #94303）
在 Windows 上，MySQL Shell 的升级检查器实用程序 checkForServerUpgrade()错误地报告了分区表的架构不一致错误。（漏洞 #29256562）
如果 Python 代码以交互模式运行并从 C++ 库中抛出异常，则 MySQL Shell 会意外停止。这些异常现在被捕获并转换为 Python 的内置 RuntimeError 异常。（缺陷号 29057116）
MySQL Shell 方法中使用键值对指定连接时shell.connect()，主机名不能为空字符串。MySQL Shell 现在可以一致地处理这种情况，并在提供的主机名是空字符串时返回错误。（漏洞#28899522）
当您使用函数调用实用程序时，MySQL Shell 的 JSON 导入实用程序现在可以接受来自 FIFO 特殊文件（命名管道）的输入util.importJSON，因此您可以通过此方法执行大量导入，而无需将数据放入文件中。（漏洞#28785527）
当您使用 MySQL Shell 命令\help （或\h, 或\?) 使用搜索模式来搜索特定主题的帮助，多个帮助主题标题可以匹配该模式并作为列表返回，通过使用扩展搜索模式再次输入命令来选择。使用此系统，可能无法从这样的列表中访问具有单个单词标题的帮助主题，因为没有其他内容可以添加到搜索模式中。为了避免这种情况，现在改进了多场比赛的处理。如果找到与给定搜索模式完全匹配的主题标题（在多个主题匹配的情况下区分大小写，在不区分大小写的匹配情况下不区分大小写），则该主题被识别为完全匹配及其打印帮助数据。“另见”部分，可以通过进一步的模式匹配来选择。（漏洞 #28393119）