MySQL 日志
在 MySQL 中有 4 种不同的日志, 分别为错误日志, 查询日志和慢查询日志, 二进制日志. 默认情况下, 为尽量减少 IO 损耗, 系统只打开错误日志. 若需要复制, 就必须要打开二进制日志.
错误日志
错误日志在 MySQL 数据库中很重要, 它记录着 MySQL 启动和停止, 以及服务器在运行过程中发生的任何错误的相关信息.
配置
如果配置文件 my.cnf 没有指定 log_eror, 则错问日志默认文件名为 hostname.err, 存放于 datadir 目录中.
mysql> SHOW VARIABLES LIKE \'log_error\'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_error | | +---------------+-------+ 1 row in set (0.00 sec)
将 log-error 配置到 my.cnf 文件中
[mysqld] log_error=/usr/local/mysql/var/mysql-error.err
查询日志
查询日志记录了所有操作的语句. 由于它记录数据库所有操作, 对于访问频繁的系统, 此种日志会造成性能影响, 所以一般不会将其打开.
配置
如果配置文件 my.cnf 有打开log选项, 但未指定具体文件名和路径, 则其默认文件名为 hostname.log, 存放于 datadir 目录中.
默认时查询日志变量值
mysql> SHOW VARIABLES LIKE \'log\'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log | OFF | +---------------+-------+ 1 row in set (0.00 sec)
如果有需要使用到查询日志, 将 log 配置到 my.cnf 文件中
[mysqld] log=/usr/local/mysql/var/mysql_query.log
查询日志是纯文本格式, 可使用文本读取工具直接打开查看.
慢查询日志
慢查询日志是记录执行时间超过参数 slow_launch_time(unit: s, v5.1 默认 2s)所设定值的 SQL 语句日志. 它有助于发现性能有问题的 SQL.
打开慢日志对系统性能的整体影响没有 binlog 那么大, 但系统需要计算每一条查询的执行时间, 所有, 在 CPU 方面还是有损耗的. 如果 CPU 资源不够, 可在大部分时候关闭这个, 只需间断性的打开来定位可能存在的慢查询.
配置
如果配置文件 my.cnf 有打开log_slow_queries选项, 但未指定具体文件名和路径, 则其默认文件名为 hostname-slow.log, 存放于 datadir 目录中.
默认情况下慢日志查询变量(v5.1):
mysql> SHOW VARIABLES LIKE \'%slow%\'; +---------------------+----------------------------------+ | Variable_name | Value | +---------------------+----------------------------------+ | log_slow_queries | OFF | | slow_launch_time | 2 | | slow_query_log | OFF | | slow_query_log_file | /usr/local/mysql/var/db-slow.log | +---------------------+----------------------------------+ 4 rows in set (0.00 sec)
如果有需要使用到慢查询日志, 将 log_slow_queries 配置到 my.cnf 文件中
[mysqld] log_slow_queries=/usr/local/mysql/var/mysql_slow_query.log
也可以在启动 MySQL 服务时, 加上 --log_slow_queries=filename.log
若需要进一步缩短慢查询时间限制, 可使用 Percona 提供的 microslow-patch(msl Patch). 它不仅能将时间减小到毫秒级别, 还能通过一些特定的规则来过滤记录的SQL, 如只记录某个表的慢查询.
二进制日志
二进制日志记录了所有的 DDL 和 DML 的语句, 但不包括查询语句, 语句以事件方式保存, 此日志对发生灾难时数据恢复极为重要. MySQL 复制时, 必须将其打开.
配置
如果配置文件 my.cnf 有打开log-bin=mysql-bin选项, 则默认存放于 datadir 目录中.
打开配置时各变量值(v5.1)
mysql> SHOW VARIABLES LIKE \'%bin%\'; +-----------------------------------------+----------------------+ | Variable_name | Value | +-----------------------------------------+----------------------+ | binlog_cache_size | 32768 | | binlog_direct_non_transactional_updates | OFF | | binlog_format | STATEMENT | | binlog_stmt_cache_size | 32768 | | innodb_locks_unsafe_for_binlog | OFF | | log_bin | ON | | log_bin_trust_function_creators | OFF | | max_binlog_cache_size | 18446744073709547520 | | max_binlog_size | 1073741824 | | max_binlog_stmt_cache_size | 18446744073709547520 | | sql_log_bin | ON | | sync_binlog | 0 | +-----------------------------------------+----------------------+ 12 rows in set (0.00 sec)
部分变量值说明
sync_binlog=0 事务提交后, 仅仅是将 binlog_cache 中的数据写入到 binlog 文件中, 但不执行 fsync 之类的磁盘操作指令通知文件系统将缓存刷新到磁盘, 而让文件系统自行决定什么时候来同步. sync_binlog=N 进行 N 次事务提交后, 系统将执行一次 fsync 之类的磁盘同步指令, 通知文件系统将 binlog 文件的缓存刷新到磁盘. 默认是 sync_binlog=0, 性能是最好, 但是风险是最大, 因为一旦系统 crash, 文件系统缓存中的 binlog 将都会丢失.设置为 1 时, 最安全但性能损耗最大, 当系统 crash 时, 最多只会丢失 binlog_cache 中未完成的一个事务, 对实际数据没有任何的影响.sync_binlog=0 性能 有可能是 sync_binlog=1 时的5倍.
建议继续学习:
- server日志的路径分析 (阅读:10079)
- AWStats简介:Apache/Windows IIS的日志分析工具的下载,安装,配置样例和使用(含6.9中文定义补丁) (阅读:8833)
- 利用脚本分析日志并利用snmp自定义OID,再通过cacti画图 (阅读:8671)
- tomcat catalina.out日志切割每天生成一个文件 (阅读:8066)
- 分布式日志系统scribe使用手记 (阅读:8022)
- AWStats是一个基于Perl的WEB日志分析工具。 (阅读:6089)
- 使用nginx记日志 (阅读:5047)
- 大于2GB的Listener.log和运行超过198天的主机上的Oracle实例 (阅读:4841)
- 在 shell 脚本里打日志 (阅读:4767)
- Sentry: 错误日志集中管理 (阅读:4335)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:gettyying 来源: 生活在别处
- 标签: 日志
- 发布时间:2011-03-27 23:56:02
- [66] Oracle MTS模式下 进程地址与会话信
- [66] Go Reflect 性能
- [65] 如何拿下简短的域名
- [59] android 开发入门
- [59] 图书馆的世界纪录
- [59] IOS安全–浅谈关于IOS加固的几种方法
- [58] 【社会化设计】自我(self)部分――欢迎区
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 界面设计速成
- [46] 读书笔记-壹百度:百度十年千倍的29条法则