-
用于编写 MySQL Shell 脚本的 API 命令行集成已得到改进,可以使用函数和选项元数据来正确解析参数并将它们与 API 调用中的相应参数相关联。以前,命令行集成将所有参数作为字符串处理,使用以下操作会导致错误:
> mysqlsh user@hostname:3306 -- cluster setOption "autoRejoinTries" 5
命令行集成现在根据 API 函数期望接收的内容解释传入的数据。此增强功能还引入了对命令行集成调用中的列表的支持。
此外,您现在可以从命令行集成访问 MySQL Shell 在线帮助。例如,要获得有关
shell.options
功能的帮助,请发出:$ mysqlsh -- shell options --help
有关更多信息,请参阅 API 命令行集成。
此外,在注册新的 MySQL Shell 扩展函数时,操作
cli
支持新的 boolean 选项shell.addExtensionObjectMember()
。cli
当使用设置为 的选项注册操作时true
,对象和函数可用于命令行集成。这使您能够扩展 MySQL Shell 的脚本可能性。(缺陷号 31186637)
大多数 AdminAPI 操作都包含元数据前提条件,以确定执行它们是否有效。完成此检查时,它会向日志中添加两个条目,一个指示即将完成检查,另一个指示元数据状态。这意味着诸如监视集群之类的操作(这意味着执行常规状态请求)会导致大量日志条目。现在,这两条日志消息已合并为一个条目,当元数据状态不正确时,该条目将记录在信息级别,而当状态正确时,则作为调试信息记录。换句话说,如果元数据状态正确,则消息仅在
log_level=debug
. (缺陷号 32582745)现在
memberRole
包含在 的默认输出中
。Previously, this information was only included when theCluster
.status()extended
option had a value of 1 or higher. 这样可以更容易地知道一个实例在集群中的角色是什么,而不管它的运行模式是 R/W 还是 R/O。(缺陷号 32381513)dba.checkInstanceConfiguration()
正在执行有关所需权限的错误验证。这导致无限循环,操作检测到缺少权限,您可以按照交互式帮助指定的方式授予授权,但操作会失败,表明缺少授权。现在,验证检查正确的列表。此外,还包括所需授权的内部列表SUPER
,这在 8.0 中已弃用。该修复程序将SUPER
授权替换为细粒度授权。(缺陷号 32287986)-
该
memberSslMode
选项不支持 以下操作 的VERIFY_CA
和 模式:VERIFY_IDENTITY
dba.createCluster()
Cluster
.addInstance()Cluster
.rejoinInstance()
现在,该
memberSslMode
选项支持这些模式,并且在使用它们时会进行验证以确保提供 CA 证书。如果您选择使用VERIFY_CA
or 模式,则必须在每个集群实例上使用and/or 选项VERIFY_IDENTITY
手动提供 CA 证书 。有关更多信息,请参阅 保护 InnoDB 集群。ssl_ca
ssl_capath
感谢 Daniël van Eeden 的贡献。(错误#32247631,错误#32241000)
在 8.0.23 版本中,添加了一个检查以验证
server_id
所有集群实例的 是否作为实例属性在元数据中注册,如果没有,则相应地更新元数据。此检查在添加、重新加入和重新扫描操作时执行。但是,将集群从 8.0.23 之前的版本升级到 8.0.23 及更高版本时,server_id
除非您执行手动重新加入,否则不会在元数据中注册。这被默默地忽略了,因为它没有包含在任何诊断消息中。现在,新的验证检查server_id
元数据中是否缺少集群实例,并instanceErrors
在输出的属性中 包含注释消息
指示用于Cluster
.status()
修复它。(缺陷号 32226871)Cluster
.rescan()从 MySQL Shell 版本 8.0.17 开始,AdminAPI 将用于元数据模式中每个添加实例的复制或恢复帐户存储在实例表中。但是,特定事务可能会失败,或者该条目可能已从元数据模式中手动删除,从而导致在尝试将其他实例添加到集群时失败,并且无法使用 AdminAPI 解决此问题。在这种情况下,如果您尝试添加实例,操作将因错误而失败。现在,AdminAPI 尝试检测与 InnoDB Cluster 或 InnoDB ReplicaSet 的这些帐户相关的元数据中的问题。这
status()
如果元数据模式中缺少所需的帐户,并且它不是实际使用的帐户,则操作会打印一条消息。在这种情况下,MySQL Shell 帮助指示您重新添加实例或rescan()
根据检测到的问题运行。 如果在元数据中发现任何丢失的恢复用户,该addInstance()
操作还会打印一个调用提示。rescan()
(缺陷号 32157182)
在不应该 的时候允许使用Cluster
.addInstance()expelTimeout
和 选项。consistency
这些选项是集群级别的设置,只能使用dba.createCluster()
和 进行设置
。(漏洞#29779995)Cluster
.setOption()该
dba.checkInstanceConfiguration()
操作检测实例是否有任何没有主键的表。组复制要求组复制的每个表都具有定义的主键。但是,这并不意味着没有主键的表会导致组复制阻塞或失败。相反,结果是不会复制对该表的更改,但该组会继续运行。以前,如果该dba.checkInstanceConfiguration()
操作检测到没有主键的表,则该操作返回状态为ok
并且仅提及缺少主键和不受支持的引擎的表。现在,如果操作检测到这样的表,它会返回状态error
. 作为这项工作的一部分,dba.createCluster()
如果找到此类表,操作已更改为失败。(漏洞#29771457)作为 Bug#28701263 修复的一部分,AdminAPI 开始设置并保留 系统变量
READ_ONLY
的 默认值。group_replication_exit_state_action
Group Replication 使用的默认值是ABORT_SERVER
. 但是,在 MySQL Server 8.0.16 中,默认值group_replication_exit_state_action
变成了 AdminAPI,READ_ONLY
因此 AdminAPI 不应更改并保留它。现在,在运行 8.0.16 及更高版本的实例上,group_replication_exit_state_action
不会修改 的值。(缺陷号 29037274)-
联机帮助中列出的异常信息对于交互式 MySQL Shell 来说已经过时且难以使用,因此已将其删除。(漏洞#28542904)
参考资料:另请参阅:Bug #29853828、Bug #32426083、Bug #32157120、Bug #28825389。
根据 MySQL Shell 是否以交互模式运行, 将
allowRootFrom
选项与 操作一起使用会创建不同的远程 root 帐户。dba.deploySandboxInstance()
现在,默认值allowRootFrom
在两种模式之间是一致的,并且帐户是root@%
在交互和非交互模式下创建的。(漏洞 #27369121)当您发出
dba.createCluster()
anddba.createReplica()
时,将创建表来存储元数据。如果默认存储引擎不是InnoDB
,这些操作可能会失败。现在,元数据创建操作总是使用InnoDB
存储引擎。(错误#101446,错误#32110085)
从 MySQL 8.0.24 开始,您在 MySQL Shell 的 SQL 模式下发出的 SQL 语句可以发送到操作系统的系统日志记录工具(
syslog
在 Unix 上,或 Windows 事件日志)。您可以通过--syslog
在启动 MySQL Shell 时指定命令行选项或通过设置history.sql.syslog
MySQL Shell 配置选项来选择此选项。将从 MySQL Shell 代码历史中排除的 SQL 语句也从系统日志记录工具中排除。(错误#31995742,错误#31514599)MySQL Shell 的实例转储实用程序
util.dumpInstance()
、模式转储实用程序util.dumpSchemas()
和表转储实用程序util.dumpTables()
现在可以检查不包含主键的表。当ocimds
启用检查与 MySQL 数据库服务的兼容性的选项时执行检查,并且为转储中包含的每个没有主键的表报告错误。这compatibility
选项,它实现了适当的兼容性措施,有两个新的修改选项来通知 MySQL Shell 的转储加载实用程序在不可见列中为没有主键的表创建主键,或者忽略丢失的主键。MySQL 数据库服务高可用性需要主键,它使用组复制。
以前,MySQL Shell 最多重试 5 次对 Oracle Cloud Infrastructure 对象存储的请求,两次重试之间有 30 秒的等待时间,最长总等待时间为 5 分钟。现在已更改重试策略以增加等待窗口并降低转储或加载操作失败的可能性。MySQL Shell 现在最多重试 10 次,两次重试之间等待 1 分钟,总等待时间最长为 10 分钟。(缺陷号 32592962)
util.dumpInstance()
如果要转储的最后一个模式是不包含表的模式,则 MySQL Shell 的实例转储实用程序 会因错误而停止。该问题现已解决。(缺陷号 32540460)MySQL Shell 的实例转储实用程序
util.dumpInstance()
已经过优化,因此如果服务器资源(如磁盘空间或线程堆栈)存在限制,它仍然可以成功使用。为了处理这种情况,如果需要,可以重复实用程序的查询以检索更小的数据块,并且避免文件排序。(缺陷号 32528186)MySQL Shell 的实例转储实用程序
util.dumpInstance()
错误地删除了授予用户的所有权限。该实用程序现在扩展GRANT ALL
转储中的语句以列出对所有模式和表 (*.*
) 授予的所有权限,并列出系统模式允许的权限。转储加载实用程序util.loadDump()
现在在加载期间提取允许和撤销的全局权限列表,并将这些从GRANT
与系统架构和所有架构和表相关的语句中剥离。(缺陷号 32526567)MySQL Shell 的转储加载实用程序
util.loadDump()
现在在加载所有数据后授予权限。以前,如果该实用程序尝试授予对尚不存在的例程的特权,则可能会发生错误。(缺陷号 32526496)如果系统变量或信息模式的 表不可用,则 MySQL Shell 的实例转储实用程序
util.dumpInstance()
、模式转储实用程序util.dumpSchemas()
和表转储实用程序util.dumpTables()
无法完成转储。在这种情况下,实用程序现在会显示警告消息并记录详细的错误消息。成功转储不需要这些项目。(缺陷号 32515696)gtid_executed
COLUMN_STATISTICS
MySQL Shell 的处理和格式化已针对您在注册 Python 插件时为字典参数及其选项提供的帮助文本进行了改进。(缺陷号 32509309)
MySQL Shell 的实例转储实用程序
util.dumpInstance()
、模式转储实用程序util.dumpSchemas()
和表转储实用程序util.dumpTables()
不再将FLUSH TABLES
语句写入二进制日志,因为这会干扰复制。(缺陷号 32490714)-
从 MySQL 8.0.23 开始,MySQL 服务器支持从未启用 GTID 且未使用基于 GTID 的复制的源服务器复制到已启用 GTID 的副本,使用 语句的
ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS
选项。CHANGE REPLICATION SOURCE TO
MySQL Shell 的实例转储实用程序util.dumpInstance()
、模式转储实用程序util.dumpSchemas()
和表转储实用程序util.dumpTables()
现在通过在转储元数据中存储二进制日志文件名和位置以及gtid_executed
GTID 集来支持此功能。额外特权REPLICATION CLIENT
是必需的,以便实用程序能够收集此信息,尽管如果用户 ID 没有该权限,转储将继续但没有二进制日志信息。将转储数据加载到副本服务器后,可以使用二进制日志信息来设置与非 GTID 源服务器的复制。
util.loadDump()
当您指定新选项时,MySQL Shell 的转储加载实用程序 会从转储元数据(以 YAML 格式)打印二进制日志和 GTID 集信息showMetadata: true
。(缺陷号 32430402) MySQL Shell 没有正确处理添加到集合中的空数组。通常从服务器返回的结果集现在在这种情况下被跳过。(缺陷号 32377134)
MySQL Shell 的实例转储实用程序
util.dumpInstance()
、模式转储实用程序util.dumpSchemas()
和表转储实用程序util.dumpTables()
无法从 MySQL 5.6 服务器实例分块表数据,因为EXPLAIN SELECT
该版本的语句输出存在差异。这些实用程序现在解决了差异,并且还缓存了服务器版本信息以便更快地访问。(缺陷号 32376447)MySQL Shell 的并行表导入实用程序
util.importTable()
在发生不中断导入的非严重错误(例如未找到目录或文件)时设置零退出代码。该实用程序现在会在观察到第一个非严重错误时设置一个非零错误代码。(缺陷号 32286186)MySQL Shell 的升级检查器实用程序
util.checkForServerUpgrade()
现在检查最初在 MySQL 5.6 中创建的空间数据列。MySQL 5.6 中此类列的底层数据类型与其在 MySQL 8.0 中的底层数据类型不匹配,因此禁止升级表,必须重新创建。(错误#32257211,错误#101944)当 MySQL Shell 将字符串转换为布尔值时,该操作现在不区分大小写。以前,结果可能因平台而异。(缺陷号 32217910)
当使用 MySQL Shell 的
\warnings
命令在每个语句后显示警告时,经典 MySQL 协议连接不会显示警告。(缺陷号 32151137)MySQL Shell 的并行表导入实用程序
util.importTable()
现在检查上传的对象是否是目录,并将它们从为文件指定的通配符匹配中排除。(漏洞#31991122)MySQL Shell 的转储加载实用程序
util.loadDump()
可以将超大数据块拆分为较小的数据块以供上传。以前,如果加载停止然后在此阶段中途恢复,则不会考虑并跳过已加载的较小块中的行,这可能会导致死锁。该实用程序的进度文件现在单独记录较小的块,以便在加载停止和恢复时可以跳过它们。(缺陷号 31961688)包含两个分号序列的事件导致 MySQL Shell 的实例转储实用程序
util.dumpInstance()
、模式转储实用程序util.dumpSchemas()
和表转储实用程序util.dumpTables()
进入无限循环寻找分隔符。(缺陷号 31820571)decodeColumns
MySQL Shell 的并行表导入实用程序 的选项util.importTable()
可以在没有附带columns
选项的情况下指定,导致导入因错误而停止。(缺陷号 31407058)如果在 MySQL Shell 的 Python 模式下交互式运行的脚本末尾没有换行符,并且脚本以多行命令结束,则 MySQL Shell 等待输入而不是处理命令。用户必须按 Enter 才能完成脚本的运行,并且脚本的最后一行错误地保存在 MySQL Shell 的代码历史记录中。MySQL Shell 现在在处理脚本输入流后添加一个空行,以确保不会发生这种情况。(缺陷号 30765725)
MySQL Shell 使用不同的字符集进行排序,具体取决于使用 X 协议还是经典 MySQL 协议连接到 MySQL 服务器实例,导致不一致,在某些情况下会导致错误。对于 MySQL 5.7 实例,MySQL Shell 现在使用一条
SET NAMES
语句将所有相关会话系统变量设置为utf8mb4
字符集。对于 MySQL 8.0 实例,MySQL Shell 现在将collation_connection
系统变量设置为utf8mb4_0900_ai_ci
字符集。(缺陷号 30516645)