8.1 MySQL管理标准规则

以下是MySQL管理标准的遵从规则:

禁用二进制日志调试信息

描述二进制日志捕获发生的DML、DDL和安全更改,并以二进制格式存储这些更改。二进制日志支持按时间点进行恢复,防止在灾难恢复过程中数据丢失。它还使您能够检查对数据库所做的所有更改。的binlog_rows_query_log_events系统变量只影响基于行的日志记录。当启用时,它会导致MySQL 5.6.2或更高版本的服务器将信息日志事件(如行查询日志事件)写入其二进制日志。这些信息可以用于调试和相关目的;例如,当无法从行更新重构主机上发出的原始查询时,获取该查询。这些事件通常会被MySQL 5.6.2以及以后读取二进制日志的程序忽略,因此在复制或从备份中恢复时不会引起任何问题。这对a不成立mysqldmysqlbinlog从MySQL 5.6.1或更早版本。如果读取日志的旧版本程序遇到信息日志事件,则会失败,并在该点停止读取。使二进制日志可读从复制MySQL服务器和其他,如mysqlbinlog从MySQL 5.6.1或更早版本,binlog_rows_query_log_events必须在日志记录期间禁用。

严重程度轻微的警告

建议研究将信息日志事件(如行查询日志事件)写入二进制日志是否适合您的环境。也就是说,如果读取您的日志的所有服务器和其他日志读取器(如mysqlbinlog)都是MySQL 5.6.2及更高版本。如果是,请打开此功能以捕获日志中的额外信息。的值可以动态设置binlog_rows_query_log_events系统变量,将新值放入(mysqld)的my.cnf/my.ini文件,以便它在重新启动服务器时仍然有效。

二进制日志记录有限

描述二进制日志捕获发生的DML、DDL和安全更改,并以二进制格式存储这些更改。二进制日志支持按时间点进行恢复,防止在灾难恢复过程中数据丢失。它还使您能够检查对数据库所做的所有更改。方法可以将二进制日志记录限制在特定的数据库中——binlog-do-db——binlog-ignore-db选项。但是,如果使用了这些选项,那么您的时间点恢复选项将受到相应的限制,同时您检查对系统所做更改的能力也会受到限制。

严重程度轻微的警告

建议检查——binlog-do-db——binlog-ignore-db在my.cnf/my.ini文件中进行设置,以确保捕获到所有重要数据库的更新。它们在服务器上的设置如下:——binlog-do-db: % binlog_do_db %而且——binlog-ignore-db: % binlog_ignore_db %

未启用二进制日志记录

描述二进制日志捕获发生的DML、DDL和安全更改,并以二进制格式存储这些更改。二进制日志支持按时间点进行恢复,防止在灾难恢复过程中数据丢失。它还使您能够检查对数据库所做的所有更改。

严重程度轻微的警告

建议为时间点恢复启用二进制日志记录log-bin中的配置变量(mysqld)my.cnf/my.ini文件的一部分。

每次写入时二进制日志记录不同步到磁盘

描述缺省情况下,二进制日志内容不同步到磁盘。如果服务器主机或操作系统崩溃,则二进制日志中的最新事件有可能没有持久保存在磁盘上。您可以使用sync_binlog服务器变量来改变这种行为。如果这个变量的值大于0,MySQL服务器在sync_binlog提交组写入二进制日志后,将它的二进制日志同步到磁盘(使用fdatasync())。sync_binlog的默认值是0,它不同步到磁盘——在这种情况下,服务器依赖于操作系统不时地刷新二进制日志的内容,就像对任何其他文件一样。值为1是最安全的选择,因为在发生崩溃时,您最多会从二进制日志中丢失一个提交组。然而,它也是最慢的选择(除非磁盘有电池支持的缓存,这会使同步非常快)。

严重程度轻微的警告

建议在my.cnf/my.ini文件的[mysqld]部分设置sync_binlog = 1,以确保从硬件、操作系统和MySQL服务器崩溃中恢复的最大安全性。

二进制日志自动删除过快

描述二进制日志捕获发生的DML、DDL和安全更改,并以二进制格式存储这些更改。二进制日志支持按时间点进行恢复,防止在灾难恢复过程中数据丢失。它在主复制服务器上用作要发送到从服务器的语句的记录。它还使您能够检查对数据库所做的所有更改。但是,日志文件的数量和它们所使用的空间可能会迅速增长,特别是在繁忙的服务器上,因此在不再需要这些文件时定期删除它们是很重要的,只要已经进行了适当的备份。的binlog_expire_logs_seconds参数启用自动删除二进制日志。

严重程度轻微的警告

建议调查为什么二进制日志每%expire_logs_days%天自动删除一次。对于您的环境,这可能是一个合适的设置,但是这个设置异常低,因此请确保您的备份计划和执行足以支持您的灾难恢复场景。如果有必要,将expire_logs_days的设置增加到一个值,以确保在您的环境中进行安全可靠的操作,同时最小化磁盘使用,并确保二进制日志至少与上一次完全备份的时间相同。一定要更新my.cnf/my.ini文件中expire_logs_days的值,以便在服务器重新启动时正确设置。

由于标识符大小写敏感,数据库可能无法移植

描述底层操作系统的大小写敏感性决定了数据库和表名的大小写敏感性。如果您只在一个平台上使用MySQL,通常不必担心这个问题。但是,如果您想在文件系统大小写不同的平台之间传输表,可能会遇到困难,这取决于您配置服务器的方式。

严重程度轻微的警告

建议在my.cnf/my.ini文件中设置lower_case_table_names=1并重新启动MySQL服务器。注意,如果您计划在Unix上将lower_case_table_names系统变量设置为1,那么在使用新变量设置重新启动mysqld之前,必须先将旧的数据库和表名转换为小写。

事件调度器禁用

描述事件调度器在启用时是一个非常有用的特性。它是一个在特定时间或定期执行SQL命令的框架。从概念上讲,它类似于Unix crontab(也称为“cron作业”)或Windows任务调度程序的思想。其架构的基础很简单。事件是一个存储的例程,具有开始日期和时间,以及一个循环标记。一旦定义并激活,它将在请求时运行。与触发器不同,事件不链接到特定的表操作,而是链接到日期和时间。使用事件调度程序,数据库管理员可以以最小的麻烦执行重复发生的事件。常见的用途是清除过时的数据、创建统计汇总表以及监视服务器性能和使用情况。

严重程度轻微的警告

建议启用事件调度器并使用它自动化重复发生的事件。在my.cnf/my.ini文件的[mysqld]部分添加一行event_scheduler=1,以便在服务器重新启动时正确设置该变量。

已启用一般查询日志

描述一般查询日志是mysqld正在做什么的一般记录。当客户端连接或断开连接时,服务器将信息写入此日志,并记录从客户端接收到的每条SQL语句。当您怀疑客户机中有错误并想确切地知道客户机向mysqld发送了什么时,通用查询日志可能非常有用。但是,一般的查询日志不应该在生产环境中启用,因为:它会增加服务器的开销;它记录语句的顺序是接收它们的顺序,而不是执行它们的顺序,因此备份/恢复不可靠;它增长很快,可以使用大量磁盘空间。您应该使用二进制日志。

严重程度轻微的警告

建议禁用通用查询日志:从my.cnf/my.ini文件中删除log选项,或者从启动MySQL服务器的脚本中删除——log选项。

内存中临时表大小受最大堆表大小限制

描述如果构建临时表所需的空间超过了tmp_table_size或max_heap_table_size, MySQL将在服务器的tmpdir目录中创建一个基于磁盘的表。出于性能考虑,最好在内存中创建大多数临时表,而在磁盘上创建超大的临时表。许多dba适当地配置tmp_table_size,但忘记了max_heap_table_size也起着作用。

严重程度轻微的警告

建议考虑将max_heap_table_size设置为等于或大于tmp_table_size。变量tmp_table_size当前设置为%tmp_table_size%, max_heap_table_size设置为%max_heap_table_size%。

关闭InnoDB严格模式

描述为了防止SQL中被忽略的错别字和语法错误,或者各种操作模式和SQL命令的组合带来的其他意想不到的后果,InnoDB提供了一种“严格模式”的操作。在这种模式下,InnoDB会在某些情况下抛出错误条件,而不是发出警告并处理指定的命令(可能会有一些意想不到的默认值)。这类似于MySQL的sql_mode,它控制MySQL将接受什么样的SQL语法,并决定它是静默地忽略错误,还是验证输入语法和数据值。在CREATE TABLE和ALTER TABLE命令以及CREATE INDEX命令上使用ROW_FORMAT和KEY_BLOCK_SIZE的新子句和设置,如果不是在严格模式下运行,可能会造成混乱。除非你在严格模式下运行,否则InnoDB会忽略某些语法错误并创建表或索引,只在消息日志中发出警告。然而,如果InnoDB的严格模式是打开的,这样的错误将立即产生错误,表或索引将不会被创建,因此可以通过在命令发出时捕获错误来节省时间。

严重程度轻微的警告

建议研究为什么innodb_strict_mode变量被设置为OFF。在my.cnf/my.ini文件中添加innodb_strict_mode=1,以便服务器重新启动时设置正确。

InnoDB系统表空间不能自动扩展

描述如果InnoDB系统表空间不允许自动增长以满足输入数据的需求,而你的应用程序生成的数据超过了空间,就会发生空间不足的错误,你的应用程序可能会遇到问题。

严重程度轻微的警告

建议通过在my.cnf/my.ini文件的innodb_data_file_path变量中包含autoextend关键字来配置InnoDB系统表空间自动扩展。为了确保低级别的碎片,将autoextend增量(InnoDB表空间将增长的空间量)设置为较大的大小。

InnoDB事务日志大小不正确

描述为了避免频繁的检查点活动和减少总体物理I/O,这会降低写量大的系统的速度,InnoDB事务日志应该大约是InnoDB缓冲池大小的50-100%,这取决于缓冲池的大小。

严重程度轻微的警告

建议增加InnoDB事务日志的大小。但是请注意,更大的事务日志可能意味着更多的崩溃恢复时间和更密集的检查点周期,因为必须将更多的数据从缓冲池和日志刷新到表空间数据文件。考虑到这一点,建议的最大大小是每个日志文件1 GB。要更改日志文件的大小,请彻底关闭MySQL,相应地修改my.cnf/my.ini文件中innodb_log_file_size的值,将当前的ib_logfile*文件从data目录移动到另一个位置,并重新启动MySQL,以便可以自动创建新的日志文件。

警告未被记录

描述MySQL服务器遇到的错误条件总是会记录在错误日志中,但是只有当log_warnings设置为大于0的值时,才会记录警告条件。如果没有记录警告,则无法获得有关连接中止和各种其他通信错误的有价值信息。如果使用复制,就可以获得关于正在发生的事情的更多信息,比如关于网络故障和重新连接的消息,那么这一点就特别重要。注意,从MySQL 5.7.2开始,log_error_verbosity系统变量优先于log_warnings,并且应该代替log_warnings。

严重程度轻微的警告

建议研究为什么log_warnings设置为0。除非有明确且令人信服的理由不记录警告,否则将log_warnings设置为大于0的值。但是,在为log_warnings选择值时,请注意错误#42851和错误#46265。当对某些语句使用二进制日志记录时,设置log_warnings = 2可能会使错误日志充满关于这些语句的警告。在这些情况下,检查是否可以使用基于行的日志记录,因为这种格式总是安全的。重要提示:从MySQL 5.7.2开始,log_error_verbosity系统变量优先于log_warnings,并且应该代替log_warnings。有关该变量如何与log_error_verbosity相关的信息,请10bet靠谱参见//www.delbede.com/doc/mysql/en/server-system-variables.html#sysvar_log_warnings的描述。特别是,给log_warnings赋值会给log_error_verbosity赋值,反之亦然。另外,要注意MySQL Server 5.7.11中添加的log_statements_unsafe_for_binlog选项。如果遇到错误1592,它将控制是否将生成的警告添加到错误日志中。