MySql Study之--MySql日志管理

一、日志文件类型

MySQL有几个不同的日志文件，可以帮助你找出mysqld内部发生的事情：

二、查询日志存放位置

1、错误日志（log_err指定了错误日志的位置）

       错误日志文件包含了当mysqld启动和停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。

       如果mysqld莫名其妙地死掉并且mysqld_safe需要重新启动它，mysqld_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自动检查或着修复一个表，则错误日志中写入一条消息。

      在一些操作系统中，如果mysqld服务终止，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld终止的地方。

       可以用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值，mysqld使用错误日志名host_name.err 并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。

       如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。

2、慢速查询日志（slow_query_log）

    用--log-slow-queries[=file_name]选项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。获得初使表锁定的时间不算作执行时间。

    如果没有给出file_name值， 默认未主机名，后缀为-slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。

语句执行完并且所有锁释放后记入慢查询日志。记录顺序可以与执行顺序不相同。

慢查询日志可以用来找到执行时间长的查询，可以用于优化。但是，检查又长又慢的查询日志会很困难。要想容易些，你可以使用mysqldumpslow命令获得日志中显示的查询摘要来处理慢查询日志。

    在MySQL 5.1的慢查询日志中，不使用索引的慢查询同使用索引的查询一样记录。要想防止不使用索引的慢查询记入慢查询日志，使用--log-short-format选项。

    在MySQL 5.1中,通过--log-slow-admin-statements服务器选项，你可以请求将慢管理语句，例如OPTIMIZE TABLE、ANALYZE TABLE和 ALTER TABLE写入慢查询日志。

用查询缓存处理的查询不加到慢查询日志中，因为表有零行或一行而不能从索引中受益的查询也不写入慢查询日志。

1. 默认情况下MySql没有开启慢查询日志，开启慢查询日志：  

查看慢查询日志：

3、二进制日志（log_bin）

1）二进制文件介绍

     二进制日志以一种更有效的格式，并且是事务安全的方式包含更新日志中可用的所有信息。

     二进制日志包含了所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。

      备注：二进制日志已经代替了老的更新日志，更新日志在MySQL 5.1中不再使用。

2）二进制文件的功能

       二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果你想要记录所有语句（例如，为了识别有问题的查询），你应使用一般查询日志。

      二进制日志的主要目的是在恢复使能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。

      二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。

运行服务器时若启用二进制日志则性能大约慢1%。但是，二进制日志的好处，即用于恢复并允许设置复制超过了这个小小的性能损失。

3）二进制文件的存储路径

       当用--log-bin[=file_name]选项启动时，mysqld写入包含所有更新数据的SQL命令的日志文件。如果未给出file_name值， 默认名为-bin后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。建议指定一个文件名.

       如果你在日志名中提供了扩展名(例如，--log-bin=file_name.extension)，则扩展名被悄悄除掉并忽略。

mysqld在每个二进制日志名后面添加一个数字扩展名。每次你启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size，还会自动创建新的二进制日志。如果你正使用大的事务，二进制日志还会超过max_binlog_size：事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。

      为了能够知道还使用了哪个不同的二进制日志文件，mysqld还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为'.index'。你可以用--log-bin-index[=file_name]选项更改二进制日志索引文件的文件名。当mysqld在运行时，不应手动编辑该文件；如果这样做将会使mysqld变得混乱。

开启二进制日志后：

查看二进制文件内容：

mysql-bin.index 是二进制文件的索引，一般不能更改

通过mysqlbinlog工具读取二进制文件内容：

     如果每天都会生成大量的二进制日志，这些日志长时间不清理的话，将会对磁盘空间带来很大的浪费，所以定期清理日志是DBA维护mysql的一个重要工作

1)reset master

   在上面查看日志存放的文件夹中，二进制日志命名的格式是以mysql-bin.*，*代表日志的序号,序号是递增的,其中还有mysql-bin.index是日志的索引文件,记录了日志的最大序号

--可以看到日志又重新从000001开始

2)PURGE MASTER LOGS TO & PURGE MASTER LOGS BEFORE
      执行PURGE MASTER LOGS TO 'mysql-bin.******'命令，是将'******'编号之前的所有日志进行删除
     执行PURGE MASTER LOGS BEFORE 'yyyy-mm-dd hh:mm:ss'命令，是将在'yyyy-mm-dd hh:mm:ss'时间之前的所有日志进行删除

3)EXPIRE_LOGS_DAYS
    此参数是设置日志的过期天数，过期的日志将会被自动删除，这有利于减少我们管理日志的工作量，需要修改my.cnf

    expire_logs_days=3

这里我们设定保存日志为3天，3天之后过期的日志将被自动删除

通过二进制日志恢复数据

   bin-log是记录着mysql所有事件的操作，当mysql发生灾难性错误时，可以通过bin-log做完整恢复，基于时间点的恢复，和基于位置的恢复

完整恢复：

   假定我们每天凌晨2点都会使用mysqldump备份数据库，但在第二天早上9点由于数据库出现了故障，数据无法访问，需要恢复数据，先使用昨天凌晨备份的文件进行恢复到凌晨2点的状态，在使用mysqlbinlog恢复自mysqldump备份以来的binlog
    mysql localhost mysql-bin.000001 | mysql -uroot -p
这样数据库就可以完全的恢复到崩溃前的完全状态

基于时间点的恢复：

  由于误操作，比如说删除了一张表，这时使用上面讲的完全恢复是没有用的，因为日志里面还存在误操作的语句，，我们需要的是恢复到误操作前的状态，然后跳过误操作的语句，再恢复后面操作的语句，假定我们删除了一张表的误操作发生在10:00这个时间点，我们可以使用下面的语句用备份和binlog将数据恢复到故障前

基于位置恢复：

  由于上面提到的，使用基于时间点的恢复可能出现，在一个时间点里面可能存在误操作和其他正确的操作，所以我们需要一种更为精确的恢复方式

主从复制
   mysql的复制是指将主数据库的DDL和DML操作通过二进制日志传到从服务器上，然后在从服务器上对这些日志做重新执行的操作，从而使得从服务器和主服务器保持数据的同步