MySQL数据库之中的日志体系，是确保数据安全以及运行稳定的关键构成部分，它就好像数据库的那个“黑匣子”，详尽地记录下了运行时段所出现的全部变化。
当数据库碰到意外遭受损害的状况时，这些日志文件就变成了查询出现错误原因以及执行数据恢复的关键依据。
本文章，会深度探究MySQL各种各样日志文件的运维管控技艺，助力数据库管理员搭建稳固的数据防护体系。
SHOW VARIABLES LIKE 'log_bin%';
一、二进制日志：数据恢复的基石
[mysqld]
log-bin
server-id=201811
expire_logs_days=10
max_binding_size=100M
那二进制日志，记录着全部针对数据库所执行的、会带来更改的操作，它可是数据恢复的核心所用工具呢。
通常状况下，二进制日志处于未开启状态，管理员能够经由对 MySQL 配置文件加以修改变更打开此功能，其中在 Linux 系统对应的是 my.cnf ，而在 Windows 系统对应的则是 my.ini。
[mysqld]
log-bin="d:mysqllogs"
于[mysqld]组里头添加“log-bin”这个参数，之后重启服务，借由“SHOW VARIABLES LIKE 'log_bin'”此条语句能够验证开启状态。
倘若想要进行自定义的日志存储路径，那么能够对“log-bin=/自定义路径/mysql-bin”予以设置。
二进制日志的管理涉及查看、恢复、暂停和删除等操作。
SHOW BINARY LOGS;
MySQL每当进行重启操作，或者当前日志达到由max_binlog_size参数所控制的最大限制之时，便会生成新的日志文件，其后缀名会从1开始呈现递增态势。
mysqlbinlog [日志文件路径]
因为二进制日志是以二进制的格式来进行存储的缘故，所以需要运用mysqlbinlog命令去开展查看的操作。
当数据出现意外丢失的情况时，借助“mysqlbinlog 日志文件 | mysql -u用户名 -p”这种方式，能够达成基于时间点亦或是位置的数据恢复。
mysqlbinlog [option] filename|mysql -uroot -p;
于某些场景当中（犹如执行一系列的大量数据导入之时），管理员极有可能期望暂停二进制日志记录以此来提升性能，能够借助“SET SQL_LOG_BIN=0”予以临时关闭，等到操作完结之后再运用“SET SQL_LOG_BIN=1”使其恢复。
关于过期的日志，能够运用“PURGE BINARY LOGS TO '日志文件名'”来删除在指定文件之前的日志，或者借助“RESET MASTER”去清除全部的二进制日志并且重新开启记录。
二、错误日志：故障排查的第一现场
SET SQL_LOG_BIN={0|1}
在MySQL启动之时，运行之际，以及关闭的进程当中，关键信息被详细记录在了错误日志里，而这种错误日志，乃是用于诊断数据库故障的，最为优先被选用的工具。
该日志在默认情形下是开启的状态，并且是不可以被禁止的，其文件名一般的状况下会是主机名以及.err（就像localhost.err这样）。
去实现查看错误日志位置这件事，能够借助“SHOW VARIABLES LIKE 'log_error'”的方式达成。
# 删除创建时间比指定日志文件早的日志文件,以后缀为判断标准
PURGE {MASTER|BINARY} LOGS TO 'log_name'
# 删除指定时间前的日志文件
PURGE {MASTER|BINARY} LOGS BEFORE 'date'
错误日志以文本格式存储，所以管理员能够直接借助文本编辑器去查看，并且还能够透过“tail -f 错误日志文件”来实时监控最新的错误信息。
当天志文件尺寸处于过大状态之际，能够经由人力方式予以删除，或者在备份之后展开清理操作，MySQL会于重新启动之后自行产生全新的错误日志。
RESET MASTER
三、通用查询日志：审计与调试的利器
所有客户端连接，以及执行的 SQL 语句都被通用查询日记录下了，其对于审计跟调试具备非常重要的价值。
MySQL默认情况下会将该日志处于关闭状态，要开启它的话，需要在配置文件里进行设置，设置内容为“general_log=1”，并且还需要设置“general_log_file=/指定路径/日志名”。
自MySQL 5.1.6起，便开始提供对动态修改的支持，借助“SET GLOBAL general_log=ON”这一操作，能够立刻实现开启，而并不需要进行重启这一动作。
拿文本工具直接将日志内容打开就能查看呀，而停止日志呢，有两种办法，一种是设置”general_log=OFF“，另一种是把配置文件里相关的参数 删除掉。
SHOW VARIABLES LIKE 'log_err%';
手动将日志文件予以删除之后，去执行“FLUSH LOGS”这个命令呢，便可重新构建出新的通用查询日志。
四、慢查询日志：SQL性能优化的依据
记录超过设定阈值执行时间的SQL语句的慢查询日志，是性能优化的核心参考。
处于默认关闭状态时，要于配置文件里设置“slow_query_log=1”，还要设置“slow_query_log_file=/指定路径/日志名”，并且设置“long_query_time=2”，这里的单位是秒，建议在生产环境中将其设置为1至2秒。
[mysqld]
general_log=ON
general_log_file=[path[filename]]
经由“SHOW VARIABLES LIKE'slow_query_log%'”能够察看日志状态以及路径，运用“SET GLOBAL long_query_time=1”可以动态性地调整那个慢查询阈值。
通过设置“slow_query_log=OFF”的方式能够实现停止慢查询日志一事，在删除日志文件之后，执行“FLUSH LOGS”的操作同样可以重新构建新的日志。
五、日志运维的最佳实践
SET GLOBAL general_log=on;
SET GLOBAL general_log=off;
SET GLOBAL general_log_file='path/filename';
在实际生产环境中，合理的日志管理策略至关重要。
首先，要按照磁盘空间以及业务需求来设定合理的日志保留策略，二进制日志能够借助expire_logs_days参数来设置自动清理的天数，这些天数建议设置为7到15天。
SHOW VARIABLES LIKE 'general_log%';
其次，定期监控日志文件大小，避免日志文件过大耗尽磁盘空间。
对于核心业务系统而言，建议把日志文件存储于和数据文件不一样的独立磁盘之上，用来降低I/O竞争。
最终，构建起规范的日志备份体制，把重要日志按照一定周期进行归档，使之存放于安全存储处，借以保证在灾难出现的时候，能够将数据完整地恢复过来。
经深入领会且娴熟运用MySQL的各种日志功能，数据库管理员得以搭建起从日常监测、故障查找直至灾难恢复的整全运维体系，给业务系统的稳定运转予以坚实保障。
Comments NOTHING