Mysql日志维护策略

[这几天要折腾mysql服务器，因此在网上搜罗了一些维护策略，而后本身总结实验，下面是个人总结经验和别人的一些建议]

1、日志类型：

MySQL有几个不一样的日志文件，能够帮助你找出mysqld内部发生的事情：

日志文件	记入文件中的信息类型
错误日志	记录启动、运行或中止时出现的问题。
查询日志	记录创建的客户端链接和执行的语句。
二进制日志	记录全部更改数据的语句。主要用于复制和即时点恢复。
慢日志	记录全部执行时间超过long_query_time秒的全部查询或不使用索引的查询。
事务日志	记录InnoDB等支持事务的存储引擎执行事务时产生的日志。

1.启动慢查询日志：

@MySQL若是启用了slow_query_log=ON选项，就会记录执行时间超过long_query_time（默认10s）的查询（初使表锁定的时间不算做执行 时间）。日志记录文件为slow_query_log_file[=file_name]，若是没有给出file_name值， 默认为主机名，后缀为-slow.log。若是给出了文件名，但不是绝对路径名，文件则写入数据目录。

【这个能够在调试mysql性能的时候启用,能够找出是哪一个sql指令最浪费时间。生产环境中建议关闭】

2.生产环境中关闭通用查询日志：

@因为打开通用查询日志是记录用户的全部操做，在生产环境中这个日志的量是很是大的，因此通常状况下都是不打开的，myslq默认的该日志功能也是关闭的，在特殊状况下才进行打开【通常只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短期段内打开该日志来作相应的分析。】；

mysql> set global general_log = 1; #1：启动通用查询日志，0：关闭通用查询日志

mysql> show global variables like '%general_log%';

+------------------+----------------------------+

| Variable_name    | Value                      |

+------------------+----------------------------+

| general_log      | ON                        | #是否启用了通用查询日志

| general_log_file | /var/run/mysqld/mysqld.log | #日志路径

+------------------+----------------------------+

2 rows in set (0.00 sec)

3.按期备份二进制日志和sql数据：【本地一份，远程日志主机一份，存储主机一份】

@在my.cnf中log-bin = [filename]是启用二进制日志，默认以[filename].000001往上记录的，从启用log-bin以后【此时最好用mysqldump保存当前的mysql某个库的数据，由于二进制日志只是记录了从如今起到最近一次mysql当机重启中的全部sql语句】，mysql就会开始记录每个sql语句，一旦mysql因各类缘由须要重启，则会产生新的二进制日志，000001的后缀名会不断往上自加。如果在mysql当机期间mysql的数据遭到了破坏(如磁盘损坏)，以前的数据所有都被破坏了，这时候这个备份策略就能够帮你挽回损失。你能够从二进制日志中恢复从开始到最近一次mysql重启这段时间的数据。【二进制日志中记录的是每个sql语句，能够用mysqlbinlog [filename]查看日志内容】

4.sync_binlog全局变量的取值必定要合适：

@默认状况下，并非每次写入时都将二进制日志与硬盘同步。所以若是操做系统或机器(不只仅是MySQL服务器)崩溃，有可能二进制日志中最后的语句丢失了。要想防止这种状况，你可使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使二进制日志在每N次二进制日志写入后与硬盘同步。对非事务表的更新执行完毕后当即保存到二进制日志中。

下面解释下sync_binlog:

“sync_binlog”：这个参数是对于MySQL系统来讲是相当重要的，他不只影响到Binlog对MySQL所带来的性能损耗，并且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各类设置的说明以下：

sync_binlog=0，当事务提交以后，MySQL不作fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定何时来作同步，或者cache满了以后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交以后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不作任何强制性的磁盘刷新指令，这时候的性能是最好的，可是风险也是最大的。由于一旦系统Crash，在binlog_cache中的全部binlog信息都会被丢失。而当设置为“1”的时候，是最安全可是性能损耗最大的设置。由于当设置为1的时候，即便系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看,对于高并发事务的系统来讲,“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

5.若是数据库有不少的事务型操做，则建议把二进制日志的回滚上限设置大一些：

@对于事务表，例如BDB或InnoDB表，全部更改表的更新(UPDATE、DELETE或INSERT)被缓存起来，直到服务器接收到COMMIT语句。在该点，执行完COMMIT以前，mysqld将整个事务写入二进制日志。当处理事务的线程启动时，它为 缓冲查询分配binlog_cache_size大小的内存。若是语句大于该值，线程则打开临时文件来保存事务【因此若是bunlog_cache_size足够大，就避免了过多的磁盘的I/O操做,能够把数据所有缓存在内存中】。线程结束后临时文件被删除。【“max_binlog_cache_size”：和"binlog_cache_size"相对应，可是所表明的是binlog可以使用的最大cache内存大小。当咱们执行多语句事务的时候，max_binlog_cache_size若是不够大的话，系统可能会报出“Multi- statementtransactionrequiredmorethan'max_binlog_cache_size'bytesofstorage”的错误。因此最好也把max_binlog_cache_size也调大些(具体多大看你的服务器了)】

6.尽可能把max_binlog_size设置大些

@“max_binlog_size”：Binlog日志最大值，通常来讲设置为512M或者1G，但不能超过1G。该大小并不能很是严格控制Binlog大小，尤为是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候，系统为了保证事务的完整性，不可能作切换日志的动做，只能将该事务的全部SQL都记录进入当前日志，直到该事务结束。

7.下面是mysql环境的状况：

mysql> show variables like '%binlog%';

+--------------------------------+------------+ | Variable_name | Value | +--------------------------------+------------+
 | binlog_cache_size | 1048576 |
 | innodb_locks_unsafe_for_binlog | OFF |
 | max_binlog_cache_size| 4294967295 |
 | max_binlog_size| 1073741824 |
 | sync_binlog| 0|
+--------------------------------+------------+

8.只对一些必需要备份的库进行备份 [尤为是在主从架构中]

@这一点在使用mysql的主从架构的时候特别要注意，由于从服务器是根据主服务器的Binlog来实现同步的。若是对master上每个库都要进行Binlog备份,则在master的操做极其频繁的状况下，mysqlI/O线程的I/O量就会很是大，则可能会有slave端的数据的延时，形成slave端可能有和master端数据不一样步的状况。

@MySQL中Binlog的产生量是没办法改变的,只要咱们的SQL语句 改变了数据库中的数据,那么就 必须将该 SQL语句 所对应的 事件 记录到 Binlog中。那咱们是否是就没有办法优化复制了呢?当 然不是,在MySQL复制环境中,其实是是有8个参数可让咱们控制须要复制或者须要忽

略而不进行复制的DB 或者Table 的,分别为:

binlog_do_db:设定哪些数据库(Schema)须要记录Binlog; 【j建议master端设置】

binlog_ignore_db:设定哪些数据库(Schema)不要记录Binlog; 【建议master端设置】

replicate_do_db:设定须要复制的数据库(Schema),多个DB用逗号(“,”)分隔;【建议slave端设置】

replicate_ignore_db:设定能够忽略的数据库(Schema);【建议slave端设置】

replicate_do_table:设定须要复制的Table;【建议slave端设置】

replicate_ignore_table:设定能够忽略的Table;【建议slave端设置】

replicate_wild_Do_table:功能同Replicate_Do_Table,但能够带通配符来进行设置;【建议slave端设置】

replicate_wild_ignore_table:功能同Replicate_Ignore_Table,可带通配符设置;【建议slave端设置】

经过上面这八个参数,咱们就能够很是方便按照实际需求,控制从Master 端到Slave 端的Binlog量尽量的少,从而减少Master 端到Slave端的网络流量,减小IO 线程的IO 量,还能 减小 SQL线程的解析与应用SQL 的数量,最终达到改善Slave上的数据延时问题。

@实际上,上面这八个参数中的前面两个是设置在Master端的,然后面六个参数则是设置在

Slave端的。虽然前面两个参数和后面六个参数在功能上 并无很是直接的关系,可是对于优

化MySQL 的Replication来讲均可以启到类似的功能。固然也有必定的区别,其主要区别以下:

若是在Master端设置前面两个参数,不只仅会让Master 端的Binlog 记录所带来的IO 量减小,

还会让Master端的IO线程就能够减 少 Binlog的读取量,传递给Slave端的IO线程的Binlog量 天然就会较少。这样作的好处是能够减小网络 IO,减小Slave端IO线程的IO量,减小Slave端 的 SQL线程的工做量,从而最大幅度的优化复制性能。固然,在Master端设置也存在必定的弊 端,由于MySQL的判断是否须要复制某个事件不是根据产生该事件的SQL语句所更改的数据 所在的 DB,而是根据执行SQL语句时刻所在的默认DB,也就是咱们登陆时候指定的DB或 者运行“use database”中所指定的DB。只有当前默认DB和配置中所设定的DB彻底吻合的 时候 IO线程才会将该事件读取给Slave的IO线程。因此若是在系统中出如今默认DB和设 定须要复制的 DB不同的状况下改变了须要复制的DB中某个Table的数据的时候,该事件 是不会被复制到 Slave中去的,这样就会形成Slave端的数据和Master的数据不一致的状况出 现。一样,若是在默认Schema下更改了不须要复制的Schema中的数据,则会被复制到Slave端,当Slave端并无该Schema的时候,则会形成复制出错而中止。

而若是是在 Slave端设置后面的六个参数,在性能优化方面可能比在Master端要稍微逊色一点,由于无论是须要仍是不须要复制的 事件 都被 会被 IO线程读取到Slave端,这样不只仅增长了 网络 IO量,也给Slave端的IO线程增长了RelayLog的写入量。可是仍然能够减小Slave的SQL线程在Slave端的日志应用量。虽然性能方面稍有逊色,可是在Slave端设置复制过滤机制,能够保证不会出现由于默认模式的问题而造 成 Slave和Master数据不一致或者复制出错的 问题。