MySQL 8.0 OCP 1Z0-908 题目解析(11)

题目041

Choose the best answer.

Examine these commands and output:

mysql> SHOW FULL PROCESSLIST;

Id	User	State	Info
6	event_scheduler	Waiting on empty queue	NULL
20	root		NULL
21	root		NULL
22	root	Waiting for table metadata lock	optimize table test.demo_test
24	root	Waiting for table metadata lock	select * from test.demo_test
25	root	starting	SHOW FULL PROCESSLIST

mysql> SELECT object_type, object_schema, object_name, lock_type, lock_status, owner_thread_id, owner_event_id
    -> FROM performance_schema.metadata_locks WHERE object_schema != 'performance_schema';

OBJECT_TYPE	OBJECT_SCHEMA	OBJECT_NAME	LOCK_TYPE	LOCK_STATUS	OWNER_THREAD_ID	OWNER_EVENT_ID
TABLE	test	demo_test	SHARED_READ	GRANTED	60	7
TABLE	test	demo_test	SHARED_WRITE	GRANTED	60	9
SCHEMA	test	NULL	INTENTION_EXCLUSIVE	GRANTED	62	6
TABLE	test	demo_test	SHARED_NO_READ_WRITE	PENDING	62	6

mysql> SELECT thread_id, processlist_id, processlist_user, parent_thread_id
    -> FROM performance_schema.threads WHERE processlist_user='root';

THREAD_ID	PROCESSLIST_ID	PROCESSLIST_USER	PARENT_THREAD_ID
60	20	root	NULL
61	21	root	NULL
62	22	root	1
64	24	root	1
65	25	root	NULL

Which connection ID is holding the metadata lock?

○ A) 21

○ B) 25

○ C) 6

○ D) 22

○ E) 20

○ F) 24

翻译

选择最佳答案。

查看以下命令及输出：

mysql> SHOW FULL PROCESSLIST;

Id	User	State	Info
6	event_scheduler	Waiting on empty queue	NULL
20	root		NULL
21	root		NULL
22	root	Waiting for table metadata lock	optimize table test.demo_test
24	root	Waiting for table metadata lock	select * from test.demo_test
25	root	starting	SHOW FULL PROCESSLIST

mysql> SELECT object_type, object_schema, object_name, lock_type, lock_status, owner_thread_id, owner_event_id
    -> FROM performance_schema.metadata_locks WHERE object_schema != 'performance_schema';

OBJECT_TYPE	OBJECT_SCHEMA	OBJECT_NAME	LOCK_TYPE	LOCK_STATUS	OWNER_THREAD_ID	OWNER_EVENT_ID
TABLE	test	demo_test	SHARED_READ	GRANTED	60	7
TABLE	test	demo_test	SHARED_WRITE	GRANTED	60	9
SCHEMA	test	NULL	INTENTION_EXCLUSIVE	GRANTED	62	6
TABLE	test	demo_test	SHARED_NO_READ_WRITE	PENDING	62	6

mysql> SELECT thread_id, processlist_id, processlist_user, parent_thread_id
    -> FROM performance_schema.threads WHERE processlist_user='root';

THREAD_ID	PROCESSLIST_ID	PROCESSLIST_USER	PARENT_THREAD_ID
60	20	root	NULL
61	21	root	NULL
62	22	root	1
64	24	root	1
65	25	root	NULL

哪个连接ID持有元数据锁？

○ A) 21

○ B) 25

○ C) 6

○ D) 22

○ E) 20

○ F) 24

解析和答案

• A选项 ：从 performance_schema.threads 表可知，连接ID为21对应的线程ID为61 ，但在 performance_schema.metadata_locks 表中，未发现线程ID为61持有元数据锁相关记录，所以A选项错误。
• B选项 ：连接ID为25对应的线程ID为65 ，在 performance_schema.metadata_locks 表中，没有线程ID为65持有元数据锁的相关信息，所以B选项错误。
• C选项：连接ID为6对应的是事件调度器，且从相关表查询结果中，没有体现其持有元数据锁，所以C选项错误。
• D选项 ：连接ID为22对应的线程ID为62 ，虽然在 performance_schema.metadata_locks 表中有线程ID为62的锁记录，但结合其他信息可知其不是持有锁的连接ID，所以D选项错误。
• E选项 ：连接ID为20对应的线程ID为60 ，在 performance_schema.metadata_locks 表中，线程ID为60有相关锁已授予的记录，所以连接ID 20持有元数据锁，E选项正确。
• F选项 ：连接ID为24对应的线程ID为64 ，在 performance_schema.metadata_locks 表中，没有线程ID为64持有元数据锁的相关记录，所以F选项错误。

综上，答案是E。

知识点总结

• MySQL进程与锁监控 ：掌握 SHOW FULL PROCESSLIST 命令的作用，能够通过该命令查看当前数据库连接及相关操作状态。了解 performance_schema 中 metadata_locks 和 threads 等表的结构和用途，学会通过这些表查询元数据锁信息以及线程与连接ID的对应关系，进而排查数据库锁相关问题。
• 数据库性能优化：理解元数据锁在数据库操作中的影响，当出现等待元数据锁等情况时，能借助上述工具和方法分析原因，为数据库性能优化提供依据，如优化表结构、调整查询语句等，以减少锁等待时间，提升数据库整体性能。

题目042

Choose two.

Which two statements are true about MySQL server multi-source replication?

□ A) It must use GTID replication.

□ B) It is not compatible with auto - positioning.

□ C) It needs to be re - instanced after a crash to maintain consistency.

□ D) It uses only time - based replication conflict resolution.

□ E) It does not attempt to detect or resolve replication conflicts.

□ F) It relies on relay_log_recovery for resilient operations.

翻译

选择两项。

关于MySQL服务器多源复制，以下哪两个陈述是正确的？

□ A) 它必须使用GTID复制。

□ B) 它与自动定位不兼容。

□ C) 为保持一致性，崩溃后需要重新实例化。

□ D) 它仅使用基于时间的复制冲突解决方法。

□ E) 它不尝试检测或解决复制冲突。

□ F) 它依靠relay_log_recovery实现弹性操作。

解析和答案

• 选项A：多源复制并非必须使用GTID复制，A错误。
• 选项B：多源复制是可以与自动定位兼容的，B错误。
• 选项C：崩溃后不需要重新实例化来维持一致性，C错误。
• 选项D：多源复制不是仅使用基于时间的复制冲突解决方法，D错误。
• 选项E：MySQL服务器多源复制本身不尝试检测或解决复制冲突，E正确。
• 选项F ：多源复制依赖 relay_log_recovery 来实现弹性操作，F正确。

所以答案是E、F。

知识点总结

• MySQL多源复制：理解MySQL多源复制的原理和特性，明确其与GTID复制、自动定位等功能的关系，以及在处理复制冲突和保障弹性操作方面的特点。
• 数据库复制技术：掌握数据库复制技术中的相关概念和机制，如复制冲突解决、日志恢复等，以及多源复制在实际应用中的优势和局限性。

题目043

Choose two.

An existing asynchronous replication setup is running MySQL 8.

Which two steps are a part of implementing GTID replication?

□ A) Enable GTID by executing this on the master and the slave:

SET GLOBAL GTID_ENABLED=on;

□ B) On the slave, alter the MySQL master connection setting with:

ALTER channel CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

□ C) Execute this on the slave to enable GTID:

RESET SLAVE; START SLAVE GTID_NEXT=AUTOMATIC;

□ D) Execute this on the slave to enable GTID:

START SLAVE IO_THREAD WITH GTID;

□ E) Restart MySQL (master and slave) with these options enabled:

--gtid_mode=ON

--log-bin

--log-slave-updates

--enforce-gtid-consistency

□ F) On the slave, alter the MySQL master connection setting with:

CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

翻译

选择两项。

现有的异步复制设置运行在MySQL 8上。

以下哪两个步骤是实现GTID复制的一部分？

□ A) 在主库和从库上执行以下操作启用GTID：

SET GLOBAL GTID_ENABLED=on;

□ B) 在从库上，使用以下语句更改MySQL主库连接设置：

ALTER channel CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

□ C) 在从库上执行以下操作启用GTID：

RESET SLAVE; START SLAVE GTID_NEXT=AUTOMATIC;

□ D) 在从库上执行以下操作启用GTID：

START SLAVE IO_THREAD WITH GTID;

□ E) 使用以下启用的选项重启MySQL（主库和从库）：

--gtid_mode=ON

--log-bin

--log-slave-updates

--enforce-gtid-consistency

□ F) 在从库上，使用以下语句更改MySQL主库连接设置：

CHANGE MASTER TO MASTER_AUTO_POSITION = 1;

解析和答案

• 选项A ：SET GLOBAL GTID_ENABLED=on; 这种设置只是临时启用，重启后失效，不是实现GTID复制的正确完整步骤 ，A错误。
• 选项B ：语法错误，正确的是 CHANGE MASTER TO MASTER_AUTO_POSITION = 1; ，不是 ALTER channel CHANGE MASTER TO MASTER_AUTO_POSITION = 1; ，B错误。
• 选项C ：RESET SLAVE; START SLAVE GTID_NEXT=AUTOMATIC; 不是启用GTID复制的标准步骤 ，C错误。
• 选项D ：START SLAVE IO_THREAD WITH GTID; 不存在这样启用GTID的标准语法 ，D错误。
• 选项E ：在主库和从库上，通过启用 --gtid_mode=ON 等相关选项重启MySQL ，是实现GTID复制的必要步骤 ，E正确。
• 选项F ：在从库上使用 CHANGE MASTER TO MASTER_AUTO_POSITION = 1; 来更改主库连接设置，是GTID复制设置的步骤之一 ，F正确。

所以答案是E、F。

知识点总结

• GTID复制 ：理解GTID（全局事务标识符）复制的原理和机制，掌握在MySQL 8中实现GTID复制的具体步骤和相关配置选项（如 --gtid_mode、--log-bin 等），以及主从库上的不同操作要点。
• MySQL复制配置：深入了解MySQL异步复制转换为GTID复制的过程，明确不同操作语句的正确语法和作用，能够准确进行相关配置以保障复制功能的正常运行和数据一致性。

题目044

Choose two.

Examine this MySQL Shell command:

dba.rebootClusterFromCompleteOutage()

Which two statements are true?

□ A) It stops and restarts all InnoDB Cluster instances and initializes the metadata.

□ B) It only stops and restarts all InnoDB Cluster instances.

□ C) It is not mandatory that all instances are running and reachable before running the command.

□ D) It performs InnoDB Cluster instances rolling restart.

□ E) It reconfigures InnoDB Cluster if the cluster was stopped.

□ F) It picks the minimum number of instances necessary to rebuild the quorum and reconfigures InnoDB Cluster.

□ G) It only starts all InnoDB Cluster instances.

翻译

选择两项。

查看这条MySQL Shell命令：

dba.rebootClusterFromCompleteOutage()

以下哪两个陈述是正确的？

□ A) 它会停止并重启所有InnoDB集群实例，并初始化元数据。

□ B) 它仅停止并重启所有InnoDB集群实例。

□ C) 在运行此命令之前，并非必须所有实例都处于运行且可访问状态。

□ D) 它执行InnoDB集群实例的滚动重启。

□ E) 如果集群已停止，它会重新配置InnoDB集群。

□ F) 它会选取重建法定人数所需的最少实例数量并重新配置InnoDB集群。

□ G) 它仅启动所有InnoDB集群实例。

解析和答案

• 选项A：该命令并非会初始化元数据，A错误。
• 选项B：它不仅是停止和重启实例这么简单，B错误。
• 选项C ：dba.rebootClusterFromCompleteOutage() 命令在执行时，不要求所有实例都处于运行且可访问状态，C正确。
• 选项D：此命令执行过程涉及InnoDB集群实例的滚动重启操作，D正确。
• 选项E：命令重点不是单纯在集群停止时重新配置集群，E错误。
• 选项F：该命令不是选取最少实例数量重建法定人数并配置集群，F错误。
• 选项G：不是仅启动所有实例，G错误。

所以答案是C、D。

知识点总结

• InnoDB集群管理命令 ：掌握 dba.rebootClusterFromCompleteOutage() 等MySQL Shell命令在InnoDB集群管理中的功能和特性，明确其操作范围和执行条件。
• InnoDB集群重启机制：理解InnoDB集群在出现完全故障后的重启机制，包括滚动重启等概念，以及相关命令在保障集群恢复和正常运行中的作用。