Mysql之日志

Mysql数据库服务日志

1、错误日志  error log

mysql> show variables like "%log_error%";
+---------------+------------------+
| Variable_name | Value            |
+---------------+------------------+
| log_error     | /data/node80.err |
+---------------+------------------+

  my.cnf配置(也可以在mysql_safe启动数据库时指定  --log-error=)
  [mysqld_safe]
  log-error=

2、普通查询日志 general query log (默认关,io开销大)

mysql> show variables like 'general_log%';
+------------------+------------------+
| Variable_name    | Value            |
+------------------+------------------+
| general_log      | OFF              |
| general_log_file | /data/node80.log |
+------------------+------------------+

=>临时开启:mysql> set global general_log = on;
=>mysql>set global general_log_file = "/path/file" 
my.cnf配置   
  [mysqld]   
  general_log = on   
  general_log_file =

 

3、慢查询日志 slow query log

  默认情况,关闭,如果不是调优需要,一般不建议启动,或多或少会带来一定的性能影响

mysql> show variables like "%slow%";
+---------------------+-----------------------+
| Variable_name       | Value                 |
+---------------------+-----------------------+
| log_slow_queries    | OFF                   |
| slow_launch_time    | 2                     |
| slow_query_log      | OFF                   |
| slow_query_log_file | /data/node80-slow.log |
+---------------------+-----------------------+

my.cnf配置   
[mysqld]
  long_query_time = 2    超过2秒以上的查询记录下来
  log-slow-queries = /data/slow.log
  log_queries_not_using_indexes   没有走索引的记录下来

mysql> show variables like "%long_query_time%";
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| long_query_time | 2.000000 |
+-----------------+----------+

 

[root@node80 ~]# mysqldumpslow --help
Usage: mysqldumpslow [ OPTS... ] [ LOGS... ]

Parse and summarize the MySQL slow query log. Options are

  --verbose    verbose
  --debug      debug
  --help       write this text to standard output

  -v           verbose
  -d           debug
  -s ORDER     what to sort by (al, at, ar, c, l, r, t), 'at' is default
                al: average lock time 平均锁定时间
                ar: average rows sent    平均返回记录数
                at: average query time    平均查询时间
                 c: count    访问次数
                 l: lock time    锁定时间
                 r: rows sent    返回记录
                 t: query time  查询时间
  -r           reverse the sort order (largest last instead of first)
  -t NUM       just show the top n queries    返回前NUM条记录
  -a           don't abstract all numbers to N and strings to 'S'
  -n NUM       abstract numbers with at least n digits within names
  -g PATTERN   grep: only consider stmts that include this string  匹配模式
  -h HOSTNAME  hostname of db server for *-slow.log filename (can be wildcard),
               default is '*', i.e. match all
  -i NAME      name of server instance (if using mysql.server startup script)
  -l           don't subtract lock time from total time
取返回记录集最多的10个sql
mysqldumpslow -s r -t 10 file
取访问次数最多的10个sql
mysqldumpslow -s c -t 10 file
取按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" file
配合管道使用,否则可能出现爆瓶
msysqldumpslow -s r -t 10 file | more

 

4、二进制日志  binary log

  作用:1、记录数据被修改的信息 2、主从 3、增量备份
  临时不记录binlog:set session sql_log_bin = OFF; 
  临时修改binlog format:  mysql> set session[global] binlog_format=mixed[row,statement];

  mysqlbinlog --base64-output="decode-rows" --verbose  mysql-bin.000001 查看binlog中row模式语句逐条分解情况(测试结论,只能解析原设置模式的binlog)

mysql> show variables like '%log_bin%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| log_bin                         | ON    |
| log_bin_trust_function_creators | OFF   |
| sql_log_bin                     | ON    |
+---------------------------------+-------+

 

mysql> show variables like "%binlog_format%";  #查看当前binlog模式
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

    [mysqld]
  log-bin =
  binlog_format="<format>"

 

mysql binlog三种模式

1、rowlevel 
日志中会记录成每一行数据被修改的形式,然后在slave端再对相同的数据进行修改
delete from test; 此种模式会生成5条语句。
优点:记录详细细节,不会出现某些特定情况下的存储过程或function,以及trigger的调用和触发无法被正确复制的问题。
缺点:是语句被拆分,日志量巨大

2、statement level
(互联网公司存储过程,触发器,函数等一般不用,所以问题不大) 
语句级别,每条修改数据的sql都被记录,slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行 
优点:解决了row level的缺点,不是记录每一行数据的变化,减少了日志量,减少io,提高了性能。他只需要记录在master上所执行的语句,以及执行语句的时候的上下文信息 
缺点:因为记录的是语句,所以为了这些语句在slave端也能正确执行,那么还必须记录每条语句在执行时候的上下文信息,保证能在slave端执行结果和master端相同。因为记录的内容较少,主从复制的时候涉及到复杂内容,bug就越容易出现,主要是修改数据的时候用了某些特定函数或功能时候会出现,比如sleep()函数在有些版本中就不能正确复制,在存储过程中使用last_insert_id()函数,可能会使slave和master上得到不一致的id等,而row level基于每行记录变化,所以不会出现类似问题

3、mixed 
前面两种模式的结合。此模式会区别对待记录的日志形式

 

posted @ 2017-03-18 22:41  黑色月牙  阅读(250)  评论(0)    收藏  举报