Innodb status 解析,binlog日志自动清理及手动删除

show engine innodb status \G

mysql> show engine innodb status \G

mysql中，在sql语句后面加\G表示将查询结果按列打印。默认情况下，mysql的查询结果是横向输出的，第一行是列头，后面是记录集，这样的话，假如字段比如多，出来的结果就非常乱，非常不适合人类阅读，而加上\G参数之后，表结构就变成纵向输出，即每条记录都会用

• 字段名1:字段值1
• 字段名2:字段值2

的形式显示，方便人类阅读

PS：如何导出：

mysql -u root -p --execute="show engine innodb status \G" > c:/mysql.log*************************** 1. row ***************************Type: InnoDBName: Status: 2016-08-21 01:19:58 0x7fc0b6e9d700 INNODB MONITOR OUTPUT（第一段是头部信息，仅仅声明了输出的开始，内容包括当前的日期和时间，以及自上次输出以来经过的时长。）Per second averages calculated from the last 48 seconds（计算出这一平均值的时间间隔，即自上次输出以来的时间，或者是距上次内部复位的时长。）-----------------BACKGROUND THREAD（后台线程）-----------------srv_master_thread loops: 1 srv_active, 0 srv_shutdown, 637 srv_idlesrv_master_thread log flush and writes: 638（主循环进行的运行的次数/s和挂起的次数/s）----------SEMAPHORES（信号量）（主要显示系统的当前的信号等待信息及各种等待信号的统计信息，这部分对调整innodb_thread_concurrency参数有非常大的帮助。当等待信号量非常大的时候，可能就需要禁用并发线程检测设置innodb_thread_concurrency=0;）（semaphore是一种保护便量或抽象数据类型用于构成限制共享资源（比如并行计算环境下的共享内存）访问的方法。基本上以锁的方式实现。）----------OS WAIT ARRAY INFO: reservation count 6（当前等待列表，如果并发数很大，Innodb就必须频繁等待 OS（该部分不包含由spinlock解决的等待）。reservation count（保留统计）和signal count（信号计数）表明InnoDB使用内部同步数组的频繁程度，这些数值表示InnoDB需要等待OS的频率。）OS WAIT ARRAY INFO: signal count 5RW-shared spins 0, rounds 5, OS waits 2    （读写的共享锁的计数器）RW-excl spins 0, rounds 0, OS waits 0    （读写的排他锁的计数器）RW-sx spins 0, rounds 0, OS waits 0   Spin rounds per wait: 5.00 RW-shared, 0.00 RW-excl, 0.00 RW-sx（spin waits（空转等待）和spin rounds：与OS wait相比，Spin locks 是低消耗的等待，但它是一种活跃的等待，会浪费CPU资源，因此spin waits和spin rounds 如果很大，CPU资源会被浪费。如果该值达到几十万，CPU危险了。OS Waits：表明由于互斥的OS的等待。 OS Waits 相对较慢，如果每秒钟该值有几万，就有问题。另外一种方式来看该值是通过OS状态的 context switch.）------------TRANSACTIONS（主要展示系统的锁等待信息和当前活动事务信息，通过这部分，可以追踪到死锁的详细信息。）------------Trx id counter 2819Purge done for trx's n:o < 818 undo n:o < 0 state: running but idleHistory list length 6LIST OF TRANSACTIONS FOR EACH SESSION:---TRANSACTION 421941539907408, not started0 lock struct(s), heap size 1136, 0 row lock(s)--------FILE I/O（文件I/O相关信息，主要是IO等待信息。）--------I/O thread 0 state: waiting for completed aio requests (insert buffer thread)   --》1个插入缓冲线程I/O thread 1 state: waiting for completed aio requests (log thread)    --》一个日志线程I/O thread 2 state: waiting for completed aio requests (read thread)    --》开始 默认4个读线程I/O thread 3 state: waiting for completed aio requests (read thread)I/O thread 4 state: waiting for completed aio requests (read thread)I/O thread 5 state: waiting for completed aio requests (read thread)I/O thread 6 state: waiting for completed aio requests (write thread)    --》开始默认4个写线程I/O thread 7 state: waiting for completed aio requests (write thread)I/O thread 8 state: waiting for completed aio requests (write thread)I/O thread 9 state: waiting for completed aio requests (write thread)Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] ,ibuf aio reads:, log i/o's:, sync i/o's:Pending flushes (fsync) log: 0; buffer pool: 0249 OS file reads, 53 OS file writes, 7 OS fsyncs0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s-------------------------------------INSERT BUFFER AND ADAPTIVE HASH INDEX（显示插入缓存当前状态信息及自适应hash index的状态）-------------------------------------Ibuf: size 1, free list len 0, seg size 2, 0 mergesmerged operations: insert 0, delete mark 0, delete 0discarded operations: insert 0, delete mark 0, delete 0Hash table size 34679, node heap has 0 buffer(s)Hash table size 34679, node heap has 0 buffer(s)Hash table size 34679, node heap has 0 buffer(s)Hash table size 34679, node heap has 0 buffer(s)Hash table size 34679, node heap has 0 buffer(s)Hash table size 34679, node heap has 0 buffer(s)Hash table size 34679, node heap has 0 buffer(s)Hash table size 34679, node heap has 0 buffer(s)0.00 hash searches/s, 0.00 non-hash searches/s---LOG（Innodb 事务日志相关信息，包括当前的日志序列号（Log sequence number），已经刷新同步到那个序列号，最近的check point到那个序列号了。除此之外，还显示了系统从启动到现在已经做了多少次check point，多少次日志刷新。）---Log sequence number 2492861Log flushed up to   2492861Pages flushed up to 2492861Last checkpoint at  24928520 pending log flushes, 0 pending chkp writes10 log i/o's done, 0.00 log i/o's/second----------------------BUFFER POOL AND MEMORY（主要显示innodbbuffer pool相关的各种统计信息，以及其他一些内存使用情况。）----------------------Total large memory allocated 137428992Dictionary memory allocated 292862Buffer pool size   8192Free buffers       7938Database pages     254Old database pages 0Modified db pages  0Pending reads 0Pending writes: LRU 0, flush list 0, single page 0Pages made young 0, not young 00.00 youngs/s, 0.00 non-youngs/sPages read 220, created 34, written 360.00 reads/s, 0.00 creates/s, 0.00 writes/sNo buffer pool page gets since the last printoutPages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/sLRU len: 254, unzip_LRU len: 0I/O sum[0]:cur[0], unzip sum[0]:cur[0]--------------ROW OPERATIONS（主要显示的是与客户端的请求query和query所影响的记录统计信息）--------------0 queries inside InnoDB, 0 queries in queue0 read views open inside InnoDBProcess ID=11915, Main thread ID=140465525053184, state: sleepingNumber of rows inserted 0, updated 0, deleted 0, read 90.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s----------------------------END OF INNODB MONITOR OUTPUT1 row in set (0.01 sec)

---

binlog日志自动清理

当开启mysql数据库主从时，会产生大量如mysql-bin.00000* log的文件，这会大量耗费您的硬盘空间。
mysql-bin.000001
mysql-bin.000002
mysql-bin.000003
mysql-bin.000004
mysql-bin.000005
…
有三种解决方法：

• 1.关闭mysql主从，关闭binlog；
• 2.开启mysql主从，设置expire_logs_days；
• 3.手动清除binlog文件，> PURGE MASTER LOGS TO ‘MySQL-bin.010′;

实现：
1.关闭mysql主从，关闭binlog

# vim /etc/my.cnf  //注释掉log-bin,binlog_format# Replication Master Server (default)# binary logging is required for replication# log-bin=mysql-bin# binary logging format - mixed recommended# binlog_format=mixed

然后重启数据库

2.重启mysql,开启mysql主从，设置expire_logs_days （自动）

# vim /etc/my.cnf  修改expire_logs_days,x是自动删除的天数，一般将x设置为短点，如10

expire_logs_days = x 

二进制日志自动删除的天数。默认值为0,表示“没有自动删除”
此方法需要重启mysql，附录有关于expire_logs_days的英文说明

当然也可以不重启mysql,开启mysql主从，直接在mysql里设置

expire_logs_days> show binary logs;> show variables like '%log%';> set global expire_logs_days = 10;

3.手动清除binlog文件

# /usr/local/mysql/bin/mysql -u root -p> PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY);   删除10天前的MySQL binlog日志,附录2有关于PURGE MASTER LOGS手动删除用法及示例> show master logs;

也可以重置master，删除所有binlog文件：

# /usr/local/mysql/bin/mysql -u root -p> reset master;  附录3有清除binlog时，对从mysql的影响说明

附录：
1.expire_logs_days英文说明
Where X is the number of days you’d like to keep them around. I would recommend 10, but this depends on how busy your MySQL server is and how fast these log files grow. Just make sure it is longer than the slowest slave takes to replicate the data from your master.
Just a side note: You know that you should do this anyway, but make sure you back up your mysql database. The binary log can be used to recover the database in certain situations; so having a backup ensures that if your database server does crash, you will be able to recover the data.

2.PURGE MASTER LOGS手动删除用法及示例,MASTER和BINARY是同义词

> PURGE {MASTER | BINARY} LOGS TO 'log_name'> PURGE {MASTER | BINARY} LOGS BEFORE 'date'

删除指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除MySQL BIN-LOG 日志，这样被给定的日志成为第一个。

实例：

> PURGE MASTER LOGS TO 'MySQL-bin.010';  清除MySQL-bin.010日志> PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00';   清除2008-06-22 13:00:00前binlog日志> PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);  清除3天前binlog日志BEFORE，变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。

3.清除binlog时，对从mysql的影响
如果您有一个活性的从属服务器，该服务器当前正在读取您正在试图删除的日志之一，则本语句不会起作用，而是会失败，并伴随一个错误。不过，如果从属服务器 是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。当从属服务器正在复制时，本语句可以安全运行。您不需要停止它们。