MySQL OCP888题解068-删除旧的二进制日志

Posted 2023-04-02 oddrock

文章目录

• 1、原题
• • 1.1、英文原题
  • 1.2、答案
• 2、题目解析
• • 2.1、题干解析
  • 2.2、选项解析
• 3、知识点
• • 3.1、知识点1：删除二进制日志和PURGE BINARY LOGS语句
• 4、总结

1、原题

1.1、英文原题

1.2、答案

C、E

2、题目解析

2.1、题干解析

本题考察二进制日志文件的删除。

2.2、选项解析

1. 可以通过PURGE BINARY LOGS删除已不需要的二进制日志文件（既不需要用来恢复，也没有SLAVE需要基于这个文件进行复制）。删除前务必通过SHOW SLAVE STATUS确认该日志文件在各个SLAVE都用不到了，并且最好做个备份。所以选项C和E是正确的。

3、知识点

3.1、知识点1：删除二进制日志和PURGE BINARY LOGS语句

• PURGE BINARY LOGS 语句会删除了在指定的日志文件名称或日期之前、并在日志索引文件中列出的所有二进制日志文件。BINARY和MASTER是同义词。被删除的日志文件也会从索引文件中记录的列表中删除，这样，给定的日志文件就成为列表中的第一个。BEFORE变量的datetime_expr参数应该为一个DATETIME值（一个’YYYY-MM-DD hh:mm:ss’格式的值）。
• 语法：

PURGE  BINARY | MASTER  LOGS 
    TO 'log_name'
  | BEFORE datetime_expr

• 示例：

PURGE BINARY LOGS TO 'mysql-bin.010';
PURGE BINARY LOGS BEFORE '2019-04-02 22:46:26';

• PURGE BINARY LOGS需要BINLOG_ADMIN权限。如果服务器在启动时没有使用-log-bin选项来启用二进制日志，则该语句没有效果。
• 如果有一个SLAVE目前正在读取你试图删除的一个日志文件，PURGE语句不会删除正在使用的日志文件或比它晚的任何日志文件，但它会删除任何早期的日志文件。但如果运行PURGE语句时凑巧有个SLAVE没有连接，那么被清除的日志文件可能导致SLAVE无法正常复制。所以在运行PURGE语句时要确认所有SLAVE的复制进度，不会用到即将被删除的日志文件。
• 要安全地清除二进制日志文件，请遵循以下程序。
  1. 在每个副本上，使用SHOW SLAVE STATUS来检查它正在读取哪个日志文件。
  2. 用SHOW BINARY LOGS获得复制源服务器上的二进制日志文件的列表。
  3. 确定所有副本中最早的日志文件。这就是目标文件。
  4. 对你要删除的所有日志文件做一个备份。(这一步是可选的，但总是建议的）。
  5. 清除所有的日志文件，直到但不包括目标文件。
• PURGE BINARY LOGS TO和PURGE BINARY LOGS BEFORE在.index文件中列出的二进制日志文件已经通过其他方式从系统中删除时（例如在Linux上使用rm），都会出现错误。要处理这样的错误，可以手动编辑.index文件（这是一个简单的文本文件），确保它只列出实际存在的二进制日志文件，然后重新运行失败的PURGE BINARY LOGS语句。

官方参考文档

4、总结

1. 可以通过PURGE BINARY LOGS删除已不需要的二进制日志文件（既不需要用来恢复，也没有SLAVE需要基于这个文件进行复制）。删除前务必通过SHOW SLAVE STATUS确认该日志文件在各个SLAVE都用不到了，并且最好做个备份。

MySQL OCP888题解063-突然变慢的可能原因

文章目录

• 1、原题
• • 1.1、英文原题
  • 1.2、中文翻译
  • 1.3、答案
• 2、题目解析
• • 2.1、题干解析
  • 2.2、选项解析
• 3、总结

1、原题

1.1、英文原题

What are three typical causes of MySQL becoming suddenly slow or unavailable?
A、OPTIMIZE TABLE is not executed for the InnoDB tables.
B、A configuration change was made.
C、The hardware includes a single point of failure.
D、The MySQL Query Cache is disabled.
E、The application executes a new untested query.
F、Monitoring has not enabled Performance Schema instruments.

1.2、中文翻译

MySQL突然变慢或不可用的三个典型原因是什么？
A、 对于InnoDB表，不执行OPTIMIZE TABLE。
B、 进行了配置更改。
C、 硬件包括一个单点故障。
D、 MySQL查询缓存已禁用。
E、 应用程序执行一个新的未经测试的查询。
F、 监视尚未启用性能架构工具。

1.3、答案

2、题目解析

2.1、题干解析

本题考查MySQL性能影响的因素。

2.2、选项解析

1. OPTIMIZE TABLE会让表的统计信息变准，更有利于索引的选择等优化措施。但由于表的统计信息是随着数据量逐步变化的，并不会突然变差，所以不符合题干说的突然变慢或不可用这一点，所以选项A错误。
2. Query Cache已经被废弃了，而且本身作用不大，所以不会突然影响性能，选项D是错误的。
3. 监控更不会影响性能，所以选项F是错误的。

3、总结

1. OPTIMIZE TABLE会让表的统计信息变准，更有利于索引的选择等优化措施。
2. Query Cache已经被废弃了，而且本身作用不大。
3. MySQL的performance_schema等监控不会影响性能和正常运行。