一个新的用户可配置标签框架已被添加到元数据中,以允许集群或 ReplicaSet 的特定实例用附加信息进行标记。标签可以是任何 ASCII 字符并提供命名空间。您可以使用
setInstanceOption()
手术。此外,AdminAPI 和 MySQL Router 8.0.21 支持特定标记,使您能够将实例标记为隐藏并将它们从路由中删除。然后 MySQL Router 从路由目标候选列表中排除这些标记的实例。这使您能够安全地使服务器实例脱机,以便应用程序和 MySQL Router 忽略它,例如在您执行维护任务时,例如服务器升级或配置更改。要使实例重新上线,请使用setInstanceOption()
删除标签的操作,MySQL Router 将实例重新添加到路由目标候选列表中,并变为在线以供应用程序使用。有关详细信息,请参阅 标记元数据。
重要变化: 以前,Group Replication 不支持二进制日志校验和,因此 InnoDB Cluster 中实例的要求之一是通过将
binlog_checksum
系统变量设置为NONE
。binlog_checksum
AdminAPI 在操作期间 验证了值,dba.checkInstanceConfiguration()
并且不允许创建集群或将实例添加到没有禁用二进制日志校验和的集群。在 8.0.21 版本中,Group Replication 取消了这个限制,因此 InnoDB Cluster 现在允许实例使用二进制日志校验和,并binlog_checksum
设置为CRC32
. 设置为binlog_checksum
不必对所有实例都相同。此外,使用 8.0.21 及更高版本部署的沙箱不会设置该binlog_checksum
变量,该变量默认为CRC32
. (缺陷号 31329024)当连接到组的任何成员时,无论它是主要的还是次要的,都可以采用组复制设置作为集群。但是,当使用次要成员时,
super_read_only
在该实例上被错误地禁用。现在,在采用过程中执行的所有操作都是使用组的主要成员完成的。这确保不会发生 GTID 不一致,super_read_only
并且不会在次要成员上被错误地禁用。(缺陷号 31238233)使用该
clusterAdmin
选项创建具有网络掩码作为主机一部分的用户会导致在将此用户传递给dba.createCluster()
操作时出错。现在,指定网络掩码的帐户被视为带有通配符的帐户,这意味着将跳过进一步检查以验证该帐户是否接受来自所有实例的远程连接。(缺陷号 31018091)只读兼容性检查使用了错误的 MySQL 版本作为基础版本。跨版本策略在 8.0.17 版本中添加到 Group Replication,但检查考虑的是运行 8.0.16 的实例。这导致了一条误导性的警告消息,表明添加的实例与集群只读兼容,但事实并非如此(仅适用于实例 8.0.16)。该修复确保仅当目标实例运行 8.0.17 或更高版本时,才会执行检查以验证实例是否与集群读取兼容。(缺陷号 30896344)
InnoDB Cluster 中的最大实例数为 9,但 AdminAPI 并未阻止您尝试向集群添加更多实例,并且生成的错误消息不明确。现在,如果一个集群有 9 个实例,
则会阻止您添加更多实例。(缺陷号 30885157)Cluster
.addInstance-
将具有兼容 GTID 集的实例添加到需要配置的 InnoDB Cluster 或 InnoDB ReplicaSet 应该不需要任何交互,因为这被认为是安全操作。以前,在这种情况下,当支持 MySQL Clone 时,MySQL Shell 仍然会提示在克隆或中止操作之间进行选择。现在,操作继续进行克隆,因为这是提供实例的唯一方法。
笔记与 InnoDB Cluster 或 InnoDB ReplicaSet 相比,具有空 GTID 集的实例不被认为具有兼容的 GTID 集。此类场景被认为是未知的,因此 MySQL Shell 会提示确认应采取何种操作。
(缺陷号 30884590)
group_replication
如果尚未加载插件,则 Group Replication 系统变量(以 为前缀 )不存在。即使系统变量被持久化到实例的选项文件中,它们也不会被加载,除非 Group Replication 插件在服务器启动时也被加载。如果在服务器启动后安装Group Replication插件,则不会重新加载选项文件,因此所有系统变量都有默认值。运行MySQL 8.0的实例没有问题,因为SET PERSIST
是用的。但是,在运行 MySQL 5.7 版本的实例上,dba.rebootCluster()
如果卸载了 Group Replication 插件,该操作将无法恢复部分系统变量。现在dba.configureInstance()
操作将 Group Replication 系统变量持久化到具有loose_
前缀的配置文件中。因此,一旦安装了 Group Replication 插件,在运行 5.7 的实例上,将使用持久值而不是默认值。(缺陷号 30768504)该
updateTopologyMode
选项已被弃用,其行为
已更改为在检测到更改时始终更新元数据中的拓扑模式。MySQL Shell 现在会在检测到此类更改时显示一条消息。(缺陷号 29330769)Cluster
.rescan()和操作未检查实例有效添加到集群所需的全部设置
cluster.addInstance()
。cluster.rejoinInstance()
这导致尝试使用在不同操作系统上运行的实例失败。例如,在基于 Linux 的操作系统上托管的两个实例上运行的集群会阻止添加运行 Microsoft Windows 的实例。现在, 如果 实例的值cluster.addInstance()
与 集群上的不同,则cluster.rejoinInstance()
操作会验证实例并阻止将实例添加或重新加入 集群。(漏洞 #29255212)lower_case_table_names
group_replication_gtid_assignment_block_size
default_table_encryption
MySQL Shell 现在有一个实例转储实用程序 dumpInstance() 和模式转储实用程序 dumpSchemas()。新实用程序支持将所有模式或选定模式从本地 MySQL 服务器实例导出到 Oracle 云基础设施对象存储桶或一组本地文件中。然后可以使用 MySQL Shell 的新转储加载实用程序将模式导入到 MySQL 数据库服务数据库系统中。新实用程序提供 Oracle Cloud Infrastructure 对象存储流、MySQL 数据库服务兼容性检查和修改、多线程并行转储以及文件压缩。请参阅 实例转储实用程序、架构转储实用程序和表转储实用程序。
MySQL Shell 的新转储加载实用程序 loadDump() 支持将使用 MySQL Shell 的新实例转储实用程序和模式转储实用程序转储的模式导入 MySQL 数据库服务数据库系统。转储加载实用程序提供来自远程存储的数据流、表或表块的并行加载、进度状态跟踪、恢复和重置功能,以及在转储发生时并发加载的选项。请参阅 转储加载实用程序。
-
X DevAPI 实现现在支持 JSON 架构验证,这使您能够确保文档在可以插入或更新到集合之前具有特定结构。要启用或修改 JSON 模式验证,您需要传入一个 JSON 对象,例如:
{ validation: { level: "off|strict", schema: "json-schema" } }
这里
validation
是 JSON 对象,其中包含可用于配置 JSON 模式验证的键。第一个键是level
,它可以取值strict
oroff
。第二个键schema
是一个 JSON 架构,如 http://json-schema.org中所定义。如果level
键设置为strict
,则在 将文档json-schema
添加到集合中或操作更新文档时验证文档。如果文档未通过验证,则服务器会生成错误并且操作失败。如果level
密钥设置为off
,则不会根据json-schema
.您可以将
validation
JSON 对象传递给schema.createCollection()
操作,以启用 JSON 模式验证,并schema.modifyCollection()
在操作中更改当前的 JSON 模式验证,例如禁用验证。有关详细信息,请参阅 JSON 架构验证。
MySQL Shell 插件现在支持在插件提供的 Python 中定义的函数中使用 **kwargs 语法。在函数定义中使用 **kwargs 可以让您使用具有任意名称的关键字参数的可变长度列表来调用函数。如果从 MySQL Shell 的 JavaScript 模式调用函数,MySQL Shell 将命名参数及其值传递到 Python 函数的字典对象中。MySQL Shell 首先尝试将传递给函数的关键字参数与函数定义的任何相应关键字参数相关联,如果没有,关键字参数将自动包含在 **kwargs 列表中。作为这种支持的副作用,在 MySQL Shell 中从 Python 调用的任何 API 函数,其具有选项字典作为最后一个参数,支持使用命名参数定义这些选项。(缺陷号 31495448)
当切换到 SQL 模式时,MySQL Shell 查询连接的服务器的 SQL 模式以确定该
ANSI_QUOTES
模式是否启用。以前,如果 MySQL Shell 没有收到响应查询的结果集,它就无法继续。缺少结果现在得到了适当的处理。(错误#31418783,错误#99728)在 SQL 模式下,当查询结果以表格形式打印时,MySQL Shell 在打印前对结果集进行缓冲,以便为表格识别正确的列宽。对于非常大的结果集,这种做法可能会导致内存不足错误。MySQL Shell 现在在继续格式化和打印表之前为结果集缓冲最多 1000 行。请注意,如果前 1000 行之后的一行中的某个字段包含的值比先前在结果集中该列中看到的值长,则该行的表格格式将错位。(缺陷号 31304711)
MySQL Shell 的 SQL 模式中的上下文切换已经过重构和简化,以消除使用 source 命令运行脚本文件时可能返回的 SQL 语法错误。(错误#31175790、错误#31197312、错误#99303)
用于运行 MySQL Shell 的升级检查程序实用程序 checkForServerUpgrade() 的用户帐户以前需要
ALL
权限。用户帐户现在只需要RELOAD
、PROCESS
和SELECT
权限。(缺陷号 31085098)在 Python 模式下,MySQL Shell 不处理查询返回的字符串中的无效 UTF-8 序列。(缺陷号 31083617)
MySQL Shell 的并行表导入实用程序 importTable() 有一个新选项
characterSet
,它指定在导入期间解释输入数据文件的字符集编码。将选项设置为binary
意味着在导入期间不进行任何转换。当您省略此选项时,导入使用character_set_database
系统变量指定的字符集来解释输入数据文件。(缺陷号 31057707)在 Windows 上,如果 MySQL Shell 包被提取到名称包含多字节字符的目录并从中使用,则 MySQL Shell 无法启动。MySQL Shell 现在可以正确处理包含多字节字符的目录名称,包括在设置 Python、加载提示主题和访问凭证助手时。(缺陷号 31056783)
MySQL Shell 的 JSON 导入实用程序 importJSON() 现在可以处理 UTF-8 编码文件,这些文件在开头包含 BOM(字节标记顺序),即序列
0xEF 0xBB 0xBF
. 作为早期版本中的解决方法,删除不需要的字节序列。(错误#30993547,错误#98836)当输出格式设置为 JSON 时,MySQL Shell 的升级检查器实用程序 checkForServerUpgrade() 包含用于检查的描述和文档链接,即使未发现任何问题也是如此。这些现在从输出中省略,因为它们是文本输出格式。(缺陷号 30950035)