binlog是Mysql sever层掩护的一种二进制日志，与innodb引擎中的redo/undo log是完备不同的日志；其紧张是用来记录对mysql数据更新或潜在发生更新的SQL语句，并以\"大众事务\"大众的形式保存在磁盘中；
浸染紧张有：
复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志通报给slaves并回放来达到master-slave数据同等的目的
数据规复：通过mysqlbinlog工具规复数据
增量备份
2.binlog管理
开启binlogmy.cnf配置中设置：log_bin=\"大众存放binlog路径目录\"大众
binlog信息查询binlog开启后，可以在配置文件中查看其位置信息，也可以在myslq命令行中查看：show variables like '%log_bin%';+---------------------------------+-------------------------------------+| Variable_name | Value |+---------------------------------+-------------------------------------+| log_bin | ON || log_bin_basename | /var/lib/mysql/3306/mysql-bin || log_bin_index | /var/lib/mysql/3306/mysql-bin.index || log_bin_trust_function_creators | OFF || log_bin_use_v1_row_events | OFF || sql_log_bin | ON |+---------------------------------+-------------------------------------+
binlog文件开启binlog后，会在数据目录（默认）生产host-bin.n（详细binlog信息）文件及host-bin.index索引文件（记录binlog文件列表）。当binlog日志写满(binlog大小max_binlog_size，默认1G),或者数据库重启才会生产新文件，但是也可通过手工进行切换让其重新天生新的文件（flush logs）；其余，如果正利用大的事务，由于一个事务不能横跨两个文件，因此也可能在binlog文件未满的情形下刷新文件mysql> show binary logs; //查看binlog文件列表,+------------------+-----------+| Log_name | File_size |+------------------+-----------+| mysql-bin.000001 | 177 || mysql-bin.000002 | 177 || mysql-bin.000003 | 10343266 || mysql-bin.000004 | 10485660 || mysql-bin.000005 | 53177 || mysql-bin.000006 | 2177 || mysql-bin.000007 | 1383 |+------------------+-----------+
查看binlog的状态：show master status可查看当前二进制日志文件的状态信息，显斧正在写入的二进制文件，及当前positionmysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000007 | 120 | | | |+------------------+----------+--------------+------------------+-------------------+
reset master 清空binlog日志文件
3.binlog内容
默认情形下binlog日志是二进制格式，无法直接查看。可利用两种办法进行查看：
a. mysqlbinlog: /usr/bin/mysqlbinlog mysql-bin.000007- mysqlbinlog是mysql官方供应的一个binlog查看工具， - 也可利用–read-from-remote-server从远程做事器读取二进制日志， - 还可利用--start-position --stop-position、--start-time= --stop-time精确解析binlog日志截取位置1190-1352 binlog如下： # at 1190 //事宜的出发点#171223 21:56:26 server id 123 end_log_pos 1190 CRC32 0xf75c94a7 IntvarSET INSERT_ID=2/!/;#171223 21:56:26 server id 123 end_log_pos 1352 CRC32 0xefa42fea Querythread_id=4exec_time=0error_code=0SET TIMESTAMP=1514123786/!/; //开始事务的韶光出发点 (每个at即为一个event)insert into tb_person set name=\公众name__2\公众, address=\公众beijing\"大众, sex=\公众man\公众, other=\"大众nothing\"大众 //sql语句/!/;# at 1352#171223 21:56:26 server id 123 end_log_pos 1383 CRC32 0x72c565d3 Xid = 5 //实行韶光，及位置戳，Xid:事宜指示提交的XA事务b.直命令行解析SHOW BINLOG EVENTS [IN 'log_name'] //要查询的binlog文件名[FROM pos] [LIMIT [offset,] row_count] 1190-135如下：mysql> show binlog events in 'mysql-bin.000007' from 1190 limit 2\G 13. row Log_name: mysql-bin.000007Pos: 1190Event_type: Query //事宜类型Server_id: 123End_log_pos: 1352 //结束pose点，下个事宜的出发点Info: use `test`; insert into tb_person set name=\公众name__2\公众, address=\公众beijing\公众, sex=\"大众man\"大众, other=\公众nothing\"大众 14. row Log_name: mysql-bin.000007Pos: 1352Event_type: XidServer_id: 123End_log_pos: 1383Info: COMMIT / xid=51 /
4.binlog格式
Mysql binlog日志有ROW,Statement,MiXED三种格式；可通过my.cnf配置文件及 ==set global binlog_format='ROW/STATEMENT/MIXED'== 进行修正，命令行 ==show variables like 'binlog_format'== 命令查看binglog格式；。
Row level: 仅保存记录被修正细节，不记录sql语句高下文干系信息优点：能非常清晰的记录下每行数据的修正细节，不须要记录高下文干系信息，因此不会发生某些特定情形下的procedure、function、及trigger的调用触发无法被精确复制的问题，任何情形都可以被复制，且能加快从库重放日志的效率，担保从库数据的同等性缺陷:由于所有的实行的语句在日志中都将以每行记录的修正细节来记录，因此，可能会产生大量的日志内容，滋扰内容也较多；比如一条update语句，如修正多条记录，则binlog中每一条修正都会有记录，这样造成binlog日志量会很大，特殊是当实行alter table之类的语句的时候，由于表构造修正，每条记录都发生改变，那么该表每一条记录都会记录到日志中，实际即是重修了表。 tip: - row模式天生的sql编码须要解码，不能用常规的办法去天生，须要加上相应的参数(--base64-output=decode-rows -v)才能显示出sql语句; - 新版本binlog默认为ROW level，且5.6新增了一个参数：binlog_row_image；把binlog_row_image设置为minimal往后，binlog记录的就只是影响的列，大大减少了日志内容
Statement level: 每一条会修正数据的sql都会记录在binlog中优点：只须要记录实行语句的细节和高下文环境，避免了记录每一行的变革，在一些修正记录较多的情形下比较ROW level能大大减少binlog日志量，节约IO，提高性能；还可以用于实时的还原；同时主从版本可以不一样，从做事器版本可以比主理事器版本高缺陷：为了担保sql语句能在slave上精确实行，必须记录高下文信息，以担保所有语句能在slave得到和在master端实行时候相同的结果；其余，主从复制时，存在部分函数（如sleep）及存储过程在slave上会涌现与master结果不一致的情形，而比较Row level记录每一行的变革细节，绝不会发生这种不一致的情形
Mixedlevel level: 以上两种level的稠浊利用经由前面的比拟，可以创造ROW level和statement level各有上风，如能根据sql语句取舍可能会有更好地性能和效果；Mixed level便是以上两种leve的结合。不过，新版本的MySQL对row level模式也被做了优化，并不是所有的修正都会以row level来记录，像碰着表构造变更的时候就会以statement模式来记录，如果sql语句确实便是update或者delete等修正数据的语句，那么还是会记录所有行的变更；因此，现在一样平常利用row level即可。
选取规则如果是采取 INSERT，UPDATE，DELETE 直接操作表的情形，则日志格式根据 binlog_format 的设定而记录如果是采取 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何都采取statement模式记录
5.复制
复制是mysql最主要的功能之一，mysql集群的高可用、负载均衡和读写分离都是基于复制来实现的；从5.6开始复制有两种实现办法，基于binlog和基于GTID（全局事务标示符）；本文接下来将先容基于binlog的一主一从复制；其复制的基本过程如下：
a.Master将数据改变记录到二进制日志(binary log)中b.Slave上面的IO进程连接上Master，并要求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容c.Master吸收到来自Slave的IO进程的要求后，卖力复制的IO进程会根据要求信息读取日志指定位置之后的日志信息，返回给Slave的IO进程。返复书息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master真个bin-log文件的名称以及bin-log的位置d.Slave的IO进程吸收到信息后，将吸收到的日志内容依次添加到Slave真个relay-log文件的最末端，并将读取到的Master真个 bin-log的文件名和位置记录到master-info文件中，以便不才一次读取的时候能够清楚的见告Master从某个bin-log的哪个位置开始今后的日志内容e.Slave的Sql进程检测到relay-log中新增加了内容后，会立时解析relay-log的内容成为在Master端真实实行时候的那些可实行的内容，并在自身实行
接下来利用实例演示基于binlog的主从复制：
a.配置master紧张包括设置复制账号，并付与REPLICATION SLAVE权限，详细信息会存储在于master.info文件中，及开启binlog；mysql> CREATE USER 'test'@'%' IDENTIFIED BY '123456';mysql> GRANT REPLICATION SLAVE ON . TO 'test'@'%';mysql> show variables like \公众log_bin\"大众;+---------------+-------+| Variable_name | Value |+---------------+-------+| log_bin | ON |+---------------+-------+查看master当前binlogmysql状态：mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000003 | 120 | | | |+------------------+----------+--------------+------------------+-------------------+建表插入数据：CREATE TABLE `tb_person` (`id` int(11) NOT NULL AUTO_INCREMENT,`name` varchar(36) NOT NULL, `address` varchar(36) NOT NULL DEFAULT '', `sex` varchar(12) NOT NULL DEFAULT 'Man' ,`other` varchar(256) NOT NULL ,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;insert into tb_person set name=\"大众name1\"大众, address=\公众beijing\"大众, sex=\公众man\"大众, other=\"大众nothing\"大众;insert into tb_person set name=\公众name2\"大众, address=\公众beijing\"大众, sex=\"大众man\"大众, other=\"大众nothing\"大众;insert into tb_person set name=\公众name3\公众, address=\"大众beijing\公众, sex=\公众man\公众, other=\"大众nothing\"大众;insert into tb_person set name=\公众name4\"大众, address=\公众beijing\公众, sex=\"大众man\"大众, other=\公众nothing\"大众;b.配置slaveSlave的配置类似master，需额外设置relay_log参数，slave没有必要开启二进制日志，如果slave为其它slave的master，须设置bin_logc.连接mastermysql> CHANGE MASTER TOMASTER_HOST='10.108.111.14',MASTER_USER='test',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000003',MASTER_LOG_POS=120;d.show slave status;mysql> show slave status\G 1. row Slave_IO_State: ---------------------------- slave io状态，表示还未启动Master_Host: 10.108.111.14 Master_User: test Master_Port: 20126 Connect_Retry: 60 ------------------------- master宕机或连接丢失从做事器线程重新考试测验连接主理事器之前就寝韶光Master_Log_File: mysql-bin.000003 ------------ 当前读取master binlog文件Read_Master_Log_Pos: 120 ------------------------- slave读取master binlog文件位置Relay_Log_File: relay-bin.000001 ------------ 回放binlogRelay_Log_Pos: 4 -------------------------- 回放relay log位置Relay_Master_Log_File: mysql-bin.000003 ------------ 回放log对应maser binlog文件Slave_IO_Running: NoSlave_SQL_Running: NoExec_Master_Log_Pos: 0 --------------------------- 相对付master从库的sql线程实行到的位置Seconds_Behind_Master: NULLSlave_IO_State, Slave_IO_Running, 和Slave_SQL_Running为NO解释slave还没有开始复制过程。e.启动复制start slavef.再次不雅观察slave状态mysql> show slave status\G 1. row Slave_IO_State: Waiting for master to send event -- 等待master新的eventMaster_Host: 10.108.111.14Master_User: testMaster_Port: 20126Connect_Retry: 60Master_Log_File: mysql-bin.000003Read_Master_Log_Pos: 3469 ---------------------------- 3469 即是Exec_Master_Log_Pos，已完成回放Relay_Log_File: relay-bin.000002 ||Relay_Log_Pos: 1423 ||Relay_Master_Log_File: mysql-bin.000003 ||Slave_IO_Running: Yes ||Slave_SQL_Running: Yes ||Exec_Master_Log_Pos: 3469 -----------------------------3469 即是slave读取master binlog位置，已完成回放Seconds_Behind_Master: 0可看到slave的I/O和SQL线程都已经开始运行，而且Seconds_Behind_Master=0。Relay_Log_Pos增加，意味着一些事宜被获取并实行了。末了看下如何精确判断SLAVE的延迟情形，剖断slave是否追上master的binlog： 1、首先看 Relay_Master_Log_File 和 Maser_Log_File 是否有差异； 2、如果Relay_Master_Log_File 和 Master_Log_File 是一样的话，再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异，比拟SQL线程比IO线程慢了多少个binlog事宜； 3、如果Relay_Master_Log_File 和 Master_Log_File 不一样，那解释延迟可能较大，须要从MASTER上取得binlog status，判断当前的binlog和MASTER上的差距； 4、如果以上都不能创造问题，可利用pt_heartbeat工具来监控主备复制的延迟。g.查询slave数据，主从同等mysql> select from tb_person;+----+-------+---------+-----+---------+| id | name | address | sex | other |+----+-------+---------+-----+---------+| 5 | name4 | beijing | man | nothing || 6 | name2 | beijing | man | nothing || 7 | name1 | beijing | man | nothing || 8 | name3 | beijing | man | nothing |+----+-------+---------+-----+---------+关于mysql复制的内容还有很多，比如不同的同步办法、复制格式情形下有什么差异，有什么特点，该当在什么情形下利用....这里不再逐一先容。
6.规复
规复是binlog的两大紧张浸染之一，接下来通过实例演示如何利用binlog规复数据：a.首先，看下当前binlog位置mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000008 | 1847 | | | |+------------------+----------+--------------+------------------+-------------------+b.向表tb_person中插入两条记录：insert into tb_person set name=\公众person_1\"大众, address=\公众beijing\"大众, sex=\"大众man\公众, other=\"大众test-1\公众;insert into tb_person set name=\公众person_2\公众, address=\"大众beijing\"大众, sex=\"大众man\"大众, other=\"大众test-2\"大众;c.记录当前binlog位置：mysql> show master status;+------------------+----------+--------------+------------------+-------------------+| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |+------------------+----------+--------------+------------------+-------------------+| mysql-bin.000008 | 2585 | | | |+------------------+----------+--------------+------------------+-------------------+d.查询数据mysql> select from tb_person where name =\公众person_2\"大众 or name=\"大众person_1\"大众;+----+----------+---------+-----+--------+| id | name | address | sex | other |+----+----------+---------+-----+--------+| 6 | person_1 | beijing | man | test-1 || 7 | person_2 | beijing | man | test-2 |+----+----------+---------+-----+--------+e.删除一条: delete from tb_person where name =\公众person_2\"大众;mysql> select from tb_person where name =\"大众person_2\"大众 or name=\"大众person_1\"大众;+----+----------+---------+-----+--------+| id | name | address | sex | other |+----+----------+---------+-----+--------+| 6 | person_1 | beijing | man | test-1 |+----+----------+---------+-----+--------+f. binlog规复（指定pos点规复/部分规复）mysqlbinlog --start-position=1847 --stop-position=2585 mysql-bin.000008 > test.sqlmysql> source /var/lib/mysql/3306/test.sqld.数据规复完成mysql> select from tb_person where name =\公众person_2\公众 or name=\"大众person_1\"大众;+----+----------+---------+-----+--------+| id | name | address | sex | other |+----+----------+---------+-----+--------+| 6 | person_1 | beijing | man | test-1 || 7 | person_2 | beijing | man | test-2 |+----+----------+---------+-----+--------+e.总结规复，便是让mysql将保存在binlog日志中指定段落区间的sql语句逐个重新实行一次而已
7.总结
本文简要先容binlog事理及其在规复、复制中的利用方法。
8.参考
https://dev.mysql.com/doc/internals/en/binary-log-versions.html
http://www.php.cn/mysql-tutorials-361643.html
https://www.jianshu.com/p/c16686b35807
https://www.cnblogs.com/jackluo/p/3336585.html
http://www.cnblogs.com/hustcat/archive/2009/12/19/1627525.html
