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

题目166

Choose the best answer.

Your MySQL instance is capturing a huge amount of financial transactions every day in the finance database.
Company policy is to create a backup every day.

The main tables being updated are prefixed with transactions-.
These tables are archived into tables that are prefixed with archives- each month.

mysqlbackup --optimistic-busy-tables="^finance\.transactions-.*" backup

Which optimization process best describes what happens with the redo logs?

○ A) The redo logs are backed up first, then the transaction and archive tables.
○ B) The redo logs are backed up only if there are changes showing for the transactions tables.
○ C) The redo logs are not backed up at all.
○ D) The transaction tables are backed up first, then the archive tables and redo logs.
○ E) The archive tables are backed up first, then the transaction tables and redo logs.

翻译

选择最佳答案。

你的 MySQL 实例每天在 finance 数据库中捕获大量金融交易。
公司策略要求每天创建备份。

主要更新的表以 transactions- 为前缀。
这些表每月归档到以 archives- 为前缀的表中。

mysqlbackup --optimistic-busy-tables="^finance\.transactions-.*" backup

哪个优化过程最能描述重做日志的处理方式？

○ A) 重做日志首先被备份，然后是事务表和归档表。
○ B) 只有当事务表显示有更改时，重做日志才会被备份。
○ C) 重做日志根本不会被备份。
○ D) 事务表首先被备份，然后是归档表和重做日志。
○ E) 归档表首先被备份，然后是事务表和重做日志。

解析和答案

• 选项A：在 mysqlbackup 中，重做日志并非首先被备份，而是在最后用于恢复，A错误。
• 选项B：重做日志始终会被备份，与事务表是否有变化无关，B错误。
• 选项C：重做日志必须被备份，否则无法恢复“busy”表的事务，C错误。
• 选项D：事务表因被标记为“busy”会被跳过，不会首先被备份，D错误。
• 选项E：archives-* 表未被标记为“busy”，会被优先备份；之后处理事务表和重做日志，E正确。

综上，正确答案是 E。

知识点总结

• mysqlbackup 优化策略：--optimistic-busy-tables 允许在备份时跳过“busy”表，优先备份其他表，最后通过重做日志恢复“busy”表的事务，确保备份效率和一致性。
• 重做日志的作用：重做日志记录事务的修改操作，是备份恢复的关键，用于补全“busy”表在备份期间的事务变化。

题目167

Choose two.

The data in this instance is transient; no backup or replication will be required. It is currently under performing.

• The database size is static and including indexes is 19G.
• Total system memory is 32G.

After profiling the system, you highlight these MySQL status and global variables:

Com_rollback              | 85408355 |
Com_commit                | 1242342  |
Innodb_buffer_pool_pages_free | 163840 |[mysqld]
buffer_pool_size=20G
innodb_flush_log_at_trx_commit=2
disable-log-bin

The OS metrics indicate that disk is a bottleneck.
Other variables retain their default values.

Which two changes will provide the most benefit to the instance?

□ A) sync_binlog=0
□ B) buffer_pool_size=24G
□ C) innodb_flush_log_at_trx_commit=1
□ D) innodb_doublewrite=0
□ E) max_connections=10000
□ F) innodb_log_file_size=1G

翻译

选择两项。

该实例中的数据是临时的；不需要备份或复制。当前性能不佳。

• 数据库大小是静态的，包括索引为 19G。
• 系统总内存为 32G。

在分析系统后，你发现以下 MySQL 状态和全局变量：

Com_rollback              | 85408355 |
Com_commit                | 1242342  |
Innodb_buffer_pool_pages_free | 163840 |[mysqld]
buffer_pool_size=20G
innodb_flush_log_at_trx_commit=2
disable-log-bin

操作系统指标表明磁盘是瓶颈。
其他变量保持默认值。

哪两项更改将为实例带来最大好处？

□ A) sync_binlog=0
□ B) buffer_pool_size=24G
□ C) innodb_flush_log_at_trx_commit=1
□ D) innodb_doublewrite=0
□ E) max_connections=10000
□ F) innodb_log_file_size=1G

解析和答案

• 选项A：sync_binlog 用于控制二进制日志的刷新策略，sync_binlog=0 表示二进制日志由操作系统控制刷新。但当前配置中 disable-log-bin 已禁用二进制日志，此选项无效，A错误。
• 选项B：buffer_pool_size 是 InnoDB 缓冲池大小，当前设置为 20G，数据库大小为 19G，20G 的缓冲池已足够缓存数据，增大到 24G 对性能提升有限，B错误。
• 选项C：innodb_flush_log_at_trx_commit 控制事务提交时日志的刷新策略，innodb_flush_log_at_trx_commit=1 表示每次事务提交都将日志刷新到磁盘，这会增加磁盘 I/O 操作，加重磁盘瓶颈，C错误。
• 选项D：innodb_doublewrite 用于启用或禁用 InnoDB 双写缓冲，双写缓冲用于保障数据一致性，在数据是临时且不需要严格一致性保障的情况下，禁用双写缓冲（innodb_doublewrite=0）可以减少磁盘 I/O 操作，缓解磁盘瓶颈，D正确。
• 选项E：max_connections 控制 MySQL 最大连接数，当前没有连接数瓶颈的迹象，增大连接数对解决磁盘瓶颈问题没有帮助，E错误。
• 选项F：innodb_log_file_size 是 InnoDB 重做日志文件大小，增大重做日志文件大小（innodb_log_file_size=1G）可以减少日志切换频率，从而降低磁盘 I/O 操作，缓解磁盘瓶颈，F正确。

综上，正确答案是 DF。

知识点总结

• 磁盘瓶颈优化：当磁盘成为性能瓶颈时，可通过减少磁盘 I/O 操作来优化性能，如禁用双写缓冲（innodb_doublewrite=0）、增大重做日志文件大小（innodb_log_file_size）等。
• 临时数据场景特性：在数据是临时且不需要严格数据一致性保障的场景下，可适当牺牲一致性来提升性能，例如禁用双写缓冲。
• 缓冲池配置：InnoDB 缓冲池大小应根据数据库数据量和系统内存合理配置，避免过度分配导致内存浪费或竞争。

题目168

Choose the best answer.

Examine this output:

mysql> SELECT FORMAT_BYTES(@@global.innodb_buffer_pool_size) AS BufferPoolSize,@@global.innodb_buffer_pool_instances AS NumInstances,FORMAT_BYTES(@@global.innodb_buffer_pool_chunk_size) AS ChunkSize;
+----------------+---------------+------------+
| BufferPoolSize | NumInstances  | ChunkSize  |
+----------------+---------------+------------+
| 12.00 GiB      | 8             | 128.00 MiB |
+----------------+---------------+------------+
1 row in set (0.01 sec)mysql> SELECT * FROM sys.metrics WHERE Variable_name LIKE 'Threads%';
+-----------------+----------------+---------------+---------+
| Variable_name   | Variable_value | Type          | Enabled |
+-----------------+----------------+---------------+---------+
| threads_cached  | 4              | Global Status | YES     |
| threads_connected | 32            | Global Status | YES     |
| threads_created | 112            | Global Status | YES     |
| threads_running | 16             | Global Status | YES     |
+-----------------+----------------+---------------+---------+
4 rows in set (0.06 sec)

Which change should optimize the number of buffer pool instances for this workload?

○ A) Decrease the number of buffer pool instances to 4.
○ B) Increase the number of buffer pool instances to 16.
○ C) Increase the number of buffer pool instances to 32.
○ D) Decrease the number of buffer pool instances to 1.
○ E) Increase the number of buffer pool instances to 12.

翻译

选择最佳答案。

查看输出：

mysql> SELECT FORMAT_BYTES(@@global.innodb_buffer_pool_size) AS BufferPoolSize,@@global.innodb_buffer_pool_instances AS NumInstances,FORMAT_BYTES(@@global.innodb_buffer_pool_chunk_size) AS ChunkSize;
+----------------+---------------+------------+
| BufferPoolSize | NumInstances  | ChunkSize  |
+----------------+---------------+------------+
| 12.00 GiB      | 8             | 128.00 MiB |
+----------------+---------------+------------+
1 row in set (0.01 sec)mysql> SELECT * FROM sys.metrics WHERE Variable_name LIKE 'Threads%';
+-----------------+----------------+---------------+---------+
| Variable_name   | Variable_value | Type          | Enabled |
+-----------------+----------------+---------------+---------+
| threads_cached  | 4              | Global Status | YES     |
| threads_connected | 32            | Global Status | YES     |
| threads_created | 112            | Global Status | YES     |
| threads_running | 16             | Global Status | YES     |
+-----------------+----------------+---------------+---------+
4 rows in set (0.06 sec)

对于此工作负载，应如何更改以优化缓冲池实例的数量？

○ A) 将缓冲池实例的数量减少到 4。
○ B) 将缓冲池实例的数量增加到 16。
○ C) 将缓冲池实例的数量增加到 32。
○ D) 将缓冲池实例的数量减少到 1。
○ E) 将缓冲池实例的数量增加到 12。

解析和答案

• 选项A：减少实例数量可能会降低并发性能，A错误。
• 选项B：增加到16虽然比当前8多，但根据公式，12更合适，B错误。
• 选项C：增加到32可能超过了根据内存和线程数计算的合理数量，C错误。
• 选项D：减少到1会严重影响并发性能，D错误。
• 选项E：根据 innodb_buffer_pool_instances 的优化原则，通常建议将其设置为与 CPU 核心数、并发线程数或缓冲池大小的 chunk 数相匹配。本题中 threads_running 为16，当前实例数为8，增加到12更接近并发线程数，有助于优化性能，E正确。

所以答案是E。

知识点总结

• InnoDB缓冲池实例：了解 innodb_buffer_pool_instances 参数的作用，它用于将 InnoDB 缓冲池划分为多个实例，每个实例有自己的锁和 LRU 列表，从而减少并发操作时的锁竞争，提高性能。
• 优化原则：掌握优化 innodb_buffer_pool_instances 的基本原则，通常建议将其设置为与 CPU 核心数、并发线程数或缓冲池大小的 chunk 数相匹配。例如，当有较多的并发线程时，增加缓冲池实例的数量可以减少锁竞争，提高并发性能。
• 参数与性能关系：明白 innodb_buffer_pool_instances 的数量与系统性能的关系，过少的实例可能导致锁竞争加剧，过多的实例可能导致内存碎片和管理开销增加，因此需要根据实际的工作负载（如并发线程数、CPU 核心数等 ）来调整。
• 系统状态分析：能够通过查看系统状态变量（如 threads_running ）来了解当前的并发线程数，从而为优化 innodb_buffer_pool_instances 提供依据。例如，本题中 threads_running 为16，当前缓冲池实例数为8，增加到12更接近并发线程数，有助于提高性能。
• 缓冲池大小与实例数：了解缓冲池大小（innodb_buffer_pool_size ）和缓冲池实例数（innodb_buffer_pool_instances ）之间的关系，通常每个缓冲池实例的大小应该足够大（例如，不小于 1GB ），以避免过多的实例导致内存管理开销增加。
• chunk大小影响：清楚 innodb_buffer_pool_chunk_size 参数的作用，它用于指定缓冲池 chunk 的大小，缓冲池实例的数量和 chunk 大小共同决定了缓冲池的管理方式，因此在调整 innodb_buffer_pool_instances 时需要考虑 innodb_buffer_pool_chunk_size 的值。

题目169

Choose the best answer.

You recently upgraded your MySQL installation to MySQL 8.0.
Examine this client error:

ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/local/mysql/lib/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory

Which option will allow this client to connect to MySQL Server?

○ A) ALTER USER user
IDENTIFIED WITH caching_sha2_password
BY ‘password’;
○ B) [mysqld]
default_authentication_plugin=sha256_password
○ C) [mysqld]
default_authentication_plugin=caching_sha2_password
○ D) ALTER USER user
IDENTIFIED WITH mysql_native_password
BY ‘password’;
○ E) ALTER USER user
IDENTIFIED WITH sha256_password
BY ‘password’;
○ F) [mysqld]
default_authentication_plugin=mysql_native_password

翻译

选择最佳答案。

你最近将 MySQL 安装升级到了 MySQL 8.0。
查看此客户端错误：

ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded: /usr/local/mysql/lib/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory

哪个选项将允许此客户端连接到 MySQL 服务器？

○ A) ALTER USER user
IDENTIFIED WITH caching_sha2_password
BY ‘password’;
○ B) [mysqld]
default_authentication_plugin=sha256_password
○ C) [mysqld]
default_authentication_plugin=caching_sha2_password
○ D) ALTER USER user
IDENTIFIED WITH mysql_native_password
BY ‘password’;
○ E) ALTER USER user
IDENTIFIED WITH sha256_password
BY ‘password’;
○ F) [mysqld]
default_authentication_plugin=mysql_native_password

解析和答案

• 选项A：问题是客户端无法加载 caching_sha2_password 插件，所以将用户认证方式改为该插件并不能解决问题，A错误。
• 选项B：sha256_password 不是 MySQL 8.0 中有效的认证插件，B错误。
• 选项C：设置默认认证插件为 caching_sha2_password 会导致客户端仍然尝试加载该插件，无法解决问题，C错误。
• 选项D：将用户的认证方式改为 mysql_native_password，这是一个较旧但兼容性较好的认证插件，客户端可能支持，D正确。
• 选项E：sha256_password 不是有效的认证插件，E错误。
• 选项F：虽然设置默认认证插件为 mysql_native_password 可以解决新用户的认证问题，但对于已存在的用户，需要修改用户的认证方式，F错误。

所以答案是D。

知识点总结

• MySQL 8.0 认证插件变化：了解 MySQL 8.0 默认使用 caching_sha2_password 作为认证插件，而旧版本的客户端可能不支持该插件，导致连接错误。
• 认证插件兼容性：清楚 mysql_native_password 是 MySQL 5.7 及之前版本的默认认证插件，具有较好的兼容性，适用于不支持 caching_sha2_password 的客户端。
• 用户认证方式修改：掌握如何使用 ALTER USER 语句修改用户的认证方式，以解决客户端连接问题。
• 默认认证插件设置：知道如何在 MySQL 配置文件（my.cnf 或 my.ini ）中设置 default_authentication_plugin 参数，以指定默认的认证插件。
• 错误分析与解决：能够根据客户端连接错误信息（如无法加载 caching_sha2_password 插件 ），分析问题原因，并选择合适的解决方案（如修改用户认证方式或设置默认认证插件 ）。
• 插件文件问题：了解如果插件文件（如 caching_sha2_password.so ）不存在或无法访问，会导致客户端无法加载插件，此时需要确保插件文件存在且权限正确，或者选择其他认证插件。
• 版本升级影响：明白在 MySQL 版本升级（如从 5.7 升级到 8.0 ）后，认证插件的变化可能导致客户端连接问题，需要根据实际情况进行调整。
• 多种解决方案：知道解决客户端连接问题的多种方法，包括修改用户认证方式、设置默认认证插件、更新客户端驱动等，需要根据具体情况选择最合适的方法。
• 安全性考虑：了解不同认证插件的安全性差异，caching_sha2_password 比 mysql_native_password 更安全，因此在解决兼容性问题的同时，也需要考虑安全性需求。
• 配置文件修改：掌握如何修改 MySQL 配置文件来设置默认认证插件，以及修改后的配置文件需要重启 MySQL 服务器才能生效。
• 用户管理：清楚用户认证方式的修改是针对每个用户的，而默认认证插件的设置是针对所有新用户的，因此在处理连接问题时需要根据用户的具体情况进行选择。

题目170

Choose two.

You are asked to review possible options for a new MySQL instance. It will be a large, busy reporting data warehousing instance.

[mysqld]
innodb_data_file_path=

Which two configurations would satisfy long-term storage demands?

□ A) ibdata1:12M:autoextend
□ B) ibdata1:12M;ibdata2:12M:autoextend
□ C) ibdata1:12M;ibdata2:12M;ibdata3:12M
□ D) ibdata1:12M;/tmp/ibdata2:12M:autoextend
□ E) ibdata1:12M
□ F) ibdata1:12M:autoextend;ibdata2:12M:autoextend

翻译

选择两项。

你需要为一个新的 MySQL 实例评估可能的配置选项。该实例将是一个大型、繁忙的报表数据仓库实例。

[mysqld]
innodb_data_file_path=

哪两个配置能满足长期存储需求？

□ A) ibdata1:12M:autoextend
□ B) ibdata1:12M;ibdata2:12M:autoextend
□ C) ibdata1:12M;ibdata2:12M;ibdata3:12M
□ D) ibdata1:12M;/tmp/ibdata2:12M:autoextend
□ E) ibdata1:12M
□ F) ibdata1:12M:autoextend;ibdata2:12M:autoextend

解析和答案

• 选项A：ibdata1:12M:autoextend 表示初始大小为 12M，且自动扩展。对于大型数据仓库，自动扩展可以应对数据增长，满足长期存储需求，A正确。
• 选项B：ibdata1:12M;ibdata2:12M:autoextend 有两个数据文件，其中 ibdata2 自动扩展。多个数据文件且有自动扩展的设置，能更好地应对数据增长，满足长期存储需求，B正确。
• 选项C：ibdata1:12M;ibdata2:12M;ibdata3:12M 三个数据文件但都没有自动扩展，当数据增长到一定程度后，无法自动扩展，不能满足长期存储需求，C错误。
• 选项D：/tmp 目录通常是临时目录，不适合用于存储重要的数据库数据文件，存在数据丢失风险，D错误。
• 选项E：ibdata1:12M 只有一个固定大小的数据文件，无法应对数据增长，不能满足长期存储需求，E错误。
• 选项F：虽然两个数据文件都自动扩展，但在 InnoDB 中，多个数据文件都设置为 autoextend 可能会导致一些管理上的问题，且通常不需要两个都设置为自动扩展，A和B的配置更合理，F错误。

综上，正确答案是 AB。

知识点总结

• InnoDB 数据文件配置：了解 innodb_data_file_path 参数的配置方式，包括数据文件的命名、大小和自动扩展设置。
• 自动扩展的重要性：对于大型、数据不断增长的数据库，数据文件的自动扩展（autoextend）是满足长期存储需求的关键配置。
• 数据文件的位置选择：数据文件应存放在稳定、可靠且有足够空间的目录，避免存放在临时目录等不稳定的位置。