MySQL binlog格式解析

 

binlog想必大家都不陌生，在主从复制或者某些情况下的数据恢复会用到。由于binlog是二进制数据，要查看一般都借助mysqlbinlog工具。这篇笔记分析了binlog格式，希望能够了解下mysqlbinlog工具背后所做的事情。

1.什么时候写binlog

在说明什么时候写binlog前，先简单介绍下binlog的用途。binlog是二进制日志文件，用于记录mysql的数据更新或者潜在更新(比如DELETE语句执行删除而实际并没有符合条件的数据)，在mysql主从复制中就是依靠的binlog。在mysql中开启binlog需要设置my.cnf中的log_bin参数，另外也可以通过binlog_do_db
指定要记录binlog的数据库和binlog_ignore_db指定不记录binlog的数据库。对运行中的mysql要启用binlog可以通过命令SET SQL_LOG_BIN=1来设置。设置完成，我们就可以来测试binlog了。

需要注意下innodb引擎中的redo/undo log与mysql binlog是完全不同的日志，它们主要有以下几个区别：

  • a）层次不同。redo/undo log是innodb层维护的，而binlog是mysql server层维护的，跟采用何种引擎没有关系，记录的是所有引擎的更新操作的日志记录。innodb的redo/undo log更详细的说明可以参见姜承尧的《mysql技术内幕-innodb存储引擎》一书中相关章节。
  • b）记录内容不同。redo/undo日志记录的是每个页的修改情况，属于物理日志+逻辑日志结合的方式（redo log物理到页，页内采用逻辑日志，undo log采用的是逻辑日志），目的是保证数据的一致性。binlog记录的都是事务操作内容，比如一条语句DELETE FROM TABLE WHERE i > 1之类的，不管采用的是什么引擎，当然格式是二进制的，要解析日志内容可以用这个命令mysqlbinlog -vv BINLOG。
  • c）记录时机不同。redo/undo日志在事务执行过程中会不断的写入;而binlog仅仅在事务提交后才写入到日志，之前描述有误，binlog是在事务最终commit前写入的，多谢anti-semicolon 指出。当然，binlog什么时候刷新到磁盘跟参数sync_binlog相关。

显然，我们执行SELECT等不涉及数据更新的语句是不会记binlog的，而涉及到数据更新则会记录。要注意的是，对支持事务的引擎如innodb而言，必须要提交了事务才会记录binlog。

binlog刷新到磁盘的时机跟sync_binlog参数相关，如果设置为0，则表示MySQL不控制binlog的刷新，由文件系统去控制它缓存的刷新，而如果设置为不为0的值则表示每sync_binlog次事务，MySQL调用文件系统的刷新操作刷新binlog到磁盘中。设为1是最安全的，在系统故障时最多丢失一个事务的更新，但是会对性能有所影响，一般情况下会设置为100或者0，牺牲一定的一致性来获取更好的性能。

通过命令SHOW MASTER LOGS可以看到当前的binlog数目。如下面就是我机器上的mysql的binlog情况，第一列是binlog文件名，第二列是binlog文件大小。可以通过设置expire_logs_days来指定binlog保留时间，要手动清理binlog可以通过指定binlog名字或者指定保留的日期，命令分别是:purge master logs to BINLOGNAME;和purge master logs before DATE;。

  1. ......
  2. | mysql-bin.000018 |       515 |
  3. | mysql-bin.000019 |       504 |
  4. | mysql-bin.000020 |       107 |
  5. +------------------+-----------+

2 binlog格式解析

2.1 binlog文件格式简介

binlog格式分为statement，row以及mixed三种，mysql5.5默认的还是statement模式，当然我们在主从同步中一般是不建议用statement模式的，因为会有些语句不支持，比如语句中包含UUID函数，以及LOAD DATA IN FILE语句等，一般推荐的是mixed格式。暂且不管这三种格式的区别，看看binlog的存储格式是什么样的。binlog是一个二进制文件集合，当然除了我们看到的mysql-bin.xxxxxx这些binlog文件外，还有个binlog索引文件mysql-bin.index。如官方文档中所写，binlog格式如下：

  • binlog文件以一个值为0Xfe62696e的魔数开头，这个魔数对应0xfe 'b''i''n'。
  • binlog由一系列的binlog event构成。每个binlog event包含header和data两部分。
    • header部分提供的是event的公共的类型信息，包括event的创建时间，服务器等等。
    • data部分提供的是针对该event的具体信息，如具体数据的修改。
  • 从mysql5.0版本开始，binlog采用的是v4版本，第一个event都是format_desc event 用于描述binlog文件的格式版本，这个格式就是event写入binlog文件的格式。关于之前版本的binlog格式，可以参见http://dev.mysql.com/doc/internals/en/binary-log-versions.html
  • 接下来的event就是按照上面的格式版本写入的event。
  • 最后一个rotate event用于说明下一个binlog文件。
  • binlog索引文件是一个文本文件，其中内容为当前的binlog文件列表。比如下面就是一个mysql-bin.index文件的内容。
  1. /var/log/mysql/mysql-bin.000019
  2. /var/log/mysql/mysql-bin.000020
  3. /var/log/mysql/mysql-bin.000021

接下来分析下几种常见的event，其他的event类型可以参见官方文档。event数据结构如下：

  1. +=====================================+
  2. | event  | timestamp         0 : 4    |
  3. | header +----------------------------+
  4. |        | type_code         4 : 1    |
  5. |        +----------------------------+
  6. |        | server_id         5 : 4    |
  7. |        +----------------------------+
  8. |        | event_length      9 : 4    |
  9. |        +----------------------------+
  10. |        | next_position    13 : 4    |
  11. |        +----------------------------+
  12. |        | flags            17 : 2    |
  13. |        +----------------------------+
  14. |        | extra_headers    19 : x-19 |
  15. +=====================================+
  16. | event  | fixed part        x : y    |
  17. | data   +----------------------------+
  18. |        | variable part              |
  19. +=====================================+

2.2 format_desc event

下面是我在FLUSH LOGS之后新建的一个全新的binlog文件mysql-bin.000053，从binlog第一个event也就是format_desc event开始分析（mysql日志是小端字节序）：

  1. root@ubuntu:/var/log/mysql# hexdump -C mysql-bin.000053
  3. 00000000  fe 62 69 6e b8 b2 7f 56  0f 04 00 00 00 67 00 00  |.bin...V.....g..|
  4. 00000010  00 6b 00 00 00 01 00 04  00 35 2e 35 2e 34 36 2d  |.k.......5.5.46-|
  5. 00000020  30 75 62 75 6e 74 75 30  2e 31 34 2e 30 34 2e 32  |0ubuntu0.14.04.2|
  6. 00000030  2d 6c 6f 67 00 00 00 00  00 00 00 00 00 00 00 00  |-log............|
  7. 00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 13  |................|
  8. 00000050  38 0d 00 08 00 12 00 04  04 04 04 12 00 00 54 00  |8.............T.|
  9. 00000060  04 1a 08 00 00 00 08 08  08 02 00                 |...........|

对照官方文档中的说明来看下format_desc event格式：

  1. +=====================================+
  2. | event  | timestamp         0 : 4    |
  3. | header +----------------------------+
  4. |        | type_code         4 : 1    | = FORMAT_DESCRIPTION_EVENT = 15
  5. |        +----------------------------+
  6. |        | server_id         5 : 4    |
  7. |        +----------------------------+
  8. |        | event_length      9 : 4    | >= 91
  9. |        +----------------------------+
  10. |        | next_position    13 : 4    |
  11. |        +----------------------------+
  12. |        | flags            17 : 2    |
  13. +=====================================+
  14. | event  | binlog_version   19 : 2    | = 4
  15. | data   +----------------------------+
  16. |        | server_version   21 : 50   |
  17. |        +----------------------------+
  18. |        | create_timestamp 71 : 4    |
  19. |        +----------------------------+
  20. |        | header_length    75 : 1    |
  21. |        +----------------------------+
  22. |        | post-header      76 : n    | = array of n bytes, one byte per event
  23. |        | lengths for all            |   type that the server knows about
  24. |        | event types                |
  25. +=====================================+

前面4个字节是固定的magic number,值为0x6e6962fe。接着是一个format_desc event，先看下19个字节的header。这19个字节中前4个字节0x567fb2b8是时间戳，第5个字节0x0f是event type，接着4个字节0x00000004是server_id，再接着4个字节0x00000067是长度103，然后的4个字节0x0000006b是下一个event的起始位置107，接着的2个字节的0x0001是flag（1为LOG_EVENT_BINLOG_IN_USE_F，标识binlog还没有关闭，binlog关闭后，flag会被设置为0），这样4+1+4+4+4+2=19个字节的公共头就完了(extra_headers暂时没有用到)。然后是这个event的data部分，event的data分为Fixed data和Variable data两部分，其中Fixed data是event的固定长度和格式的数据，Variable data则是长度变化的数据，比如format_desc event的Fixed data长度是0x54=84个字节。下面看下这84=2+50+4+1+27个字节的分配：开始的2个字节0x0004为binlog的版本号4，接着的50个字节为mysql-server版本，如我的版本是5.5.46-0ubuntu0.14.04.2-log，与SELECT version();查看的结果一致。接下来4个字节是binlog创建时间，这里是0；然后的1个字节0x13是指之后所有event的公共头长度，这里都是19；接着的27个字节中每个字节为mysql已知的event（共27个）的Fixed data的长度；可以发现format_desc event自身的Variable data部分为空。

2.3 rotate event

接着我们不做额外操作，直接FLUSH LOGS，可以看到一个rotate event，此时的binlog内容如下:

  1. ......
  2. 00000060  ................................. c2 b3 7f 56 04  |..............V.|
  3. 00000070  04 00 00 00 2b 00 00 00  96 00 00 00 00 00 04 00  |....+...........|
  4. 00000080  00 00 00 00 00 00 6d 79  73 71 6c 2d 62 69 6e 2e  |......mysql-bin.|
  5. 00000090  30 30 30 30 35 34                                 |000054|
  6. 00000096

前面的内容跟之前的几乎一致，除了format_desc event的flag从0x0001变成了0x0000。然后从0x567fb3c2开始是一个rotate event。依照前面的分析，前面19个字节为event的header，其event type是0x04，长度为0x2b=43，下一个event起始位置为0x96=150，然后是flag为0x0000，接着是event data部分，首先的8个字节为Fixed data部分，记录的是下一个binlog的位置偏移4，而余下来的43-19-8=16个字节为Variable data部分，记录的是下一个binlog的文件名mysql-bin.000054。对照mysqlbinlog -vv mysql-bin.000053可以验证。

  1. ssj@ubuntu:/var/log/mysql$ mysqlbinlog -vv mysql-bin.000053
  2. ...
  3. # at 4
  4. #151227 17:43:20 server id 4  end_log_pos 107   Start: binlog v 4, server v 5.5.46-0ubuntu0.14.04.2-log created 151227 17:43:20
  5. BINLOG '
  6. uLJ/Vg8EAAAAZwAAAGsAAAAAAAQANS41LjQ2LTB1YnVudHUwLjE0LjA0LjItbG9nAAAAAAAAAAAA
  7. AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAVAAEGggAAAAICAgCAA==
  8. '/*!*/;
  9. # at 107
  10. #151227 17:47:46 server id 4  end_log_pos 150   Rotate to mysql-bin.000054  pos: 4
  11. ...

2.4 query event

刷新binlog，设置binlog_format=statement，创建一个表CREATE TABLEtt(ivarchar(100) DEFAULT NULL) ENGINE=InnoDB, 然后在测试表tt中插入一条数据insert into tt values('abc')，会产生3个event，包括2个query event和1个xid event。其中2个query event分别是BEGIN以及INSERT 语句，而xid event则是事务提交语句（xid event是支持XA的存储引擎才有的，因为测试表tt是innodb引擎的，所以会有。如果是myisam引擎的表，也会有BEGIN和COMMIT,只不过COMMIT会是一个query event而不是xid event）。

  1. mysql> show binlog events in 'mysql-bin.000060';
  2. +------------------+-----+-------------+-----------+-------------+--------------------------------------------------------+
  3. | Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                   |
  4. +------------------+-----+-------------+-----------+-------------+--------------------------------------------------------+
  5. | mysql-bin.000060 |   4 | Format_desc |         4 |         107 | Server ver: 5.5.46-0ubuntu0.14.04.2-log, Binlog ver: 4 |
  6. | mysql-bin.000060 | 107 | Query       |         4 |         175 | BEGIN                                                  |
  7. | mysql-bin.000060 | 175 | Query       |         4 |         266 | use `test`; insert into tt values('abc')               |
  8. | mysql-bin.000060 | 266 | Xid         |         4 |         293 | COMMIT /* xid=138 */                                   |
  9. +------------------+-----+-------------+-----------+-------------+--------------------------------------------------

binlog如下：

  1. .......
  2. 0000006b  01 9d 82 56 02 04 00 00  00 44 00 00 00 af 00 00  |...V.....D......|
  3. 0000007b  00 08 00 26 00 00 00 00  00 00 00 04 00 00 1a 00  |...&............|
  4. 0000008b  00 00 00 00 00 01 00 00  00 00 00 00 00 00 06 03  |................|
  5. 0000009b  73 74 64 04 21 00 21 00  08 00 74 65 73 74 00 42  |std.!.!...test.B|
  6. 000000ab  45 47 49 4e                                       |EGIN|
  8. 000000af  01 9d 82 56 02 04 00 00  00 5b 00 00 00 0a 01 00  |...V.....[......|
  9. 000000bf  00 00 00 26 00 00 00 00  00 00 00 04 00 00 1a 00  |...&............|
  10. 000000cf  00 00 00 00 00 01 00 00  00 00 00 00 00 00 06 03  |................|
  11. 000000df  73 74 64 04 21 00 21 00  08 00 74 65 73 74 00 69  |std.!.!...test.i|
  12. 000000ef  6e 73 65 72 74 20 69 6e  74 6f 20 74 74 20 76 61  |nsert into tt va|
  13. 000000ff  6c 75 65 73 28 27 61 62  63 27 29                 |lues('abc')|
  15. 0000010a  01 9d 82 56 10 04 00 00  00 1b 00 00 00 25 01 00  |...V.........%..|
  16. 0000011a  00 00 00 8a 00 00 00 00  00 00 00                 |...........|

抛开format_desc event，从0000006b开始分析第一个query event。头部跟之前的event一样，只是query event的type为0x02，长度为0x44=64，下一个event位置为0xaf=175。flag为8，接着是data部分，从format_desc event我们可以知道query event的Fixed data部分为13个字节，因此也可以算出Variable data部分为64-19-13=32字节。

  • Fixed data：首先的4个字节0x00000026为执行该语句的thread id，接下来的4个字节是执行的时间0(以秒为单位)，接下来的1个字节0x04是语句执行时的默认数据库名字的长度，我这里数据库是test，所以长度为4.接着的2个字节0x0000是错误码（注：通常情况下错误码是0表示没有错误，但是在一些非事务性表如myisam表执行INSERT...SELECT语句时可能插入部分数据后遇到duplicate-key错误会产生错误码1062，或者是事务性表在INSERT...SELECT出错不会插入部分数据，但是在执行过程中CTRL+C终止语句也可能记录错误码。slave db在复制时会执行后检查错误码是否一致，如果不一致，则复制过程会中止）,接着2个字节0x001a为状态变量块的长度26。
  • Variable data：从0x001a之后的26个字节为状态变量块（这个暂时先不管），然后是默认数据库名test，以0x00结尾，然后是sql语句BEGIN，接下来就是第2个query event的内容了。

第二个query event与第一个格式一样，只是执行语句变成了insert into tt values('abc')。

第三个xid event为COMMIT语句。前19个字节是通用头部，type是16。data部分中Fixed data为空，而variable data为8个字节，这8个字节0x000000008a是事务编号（注意事务编号不一定是小端字节序，因为是从内存中拷贝到磁盘的，所以这个字节序跟机器相关）。

2.5 table_map event & write_rows event

这两个event是在binlog_format=row的时候使用，设置binlog_format=row，然后创建一个测试表

  1. CREATE TABLE `trow` (
  2.   `i` int(11) NOT NULL,
  3.   `c` varchar(10) DEFAULT NULL,
  4.   PRIMARY KEY (`i`)
  5. ) ENGINE=InnoDB DEFAULT CHARSET=latin1`

执行语句INSERT INTO trow VALUES(1, NULL), (2, 'a')，这个语句会产生一个query event，一个table_map event、一个write_rows event以及一个xid event。


  2. mysql> show binlog events in 'mysql-bin.000074';
  3. | Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                   |
  4. +------------------+-----+-------------+-----------+-------------+--------------------------------------------------------+
  5. | mysql-bin.000074 |   4 | Format_desc |         4 |         107 | Server ver: 5.5.46-0ubuntu0.14.04.2-log, Binlog ver: 4 |
  6. | mysql-bin.000074 | 107 | Query       |         4 |         175 | BEGIN                                                  |
  7. | mysql-bin.000074 | 175 | Table_map   |         4 |         221 | table_id: 50 (test.trow)                               |
  8. | mysql-bin.000074 | 221 | Write_rows  |         4 |         262 | table_id: 50 flags: STMT_END_F                         |
  9. | mysql-bin.000074 | 262 | Xid         |         4 |         289 | COMMIT /* xid=245 */

对应的mysql-bin.000074数据如下：

  1. ...
  2. #query event (BEGIN)
  3. 0000006b  95 2a 85 56 02 04 00 00  00 44 00 00 00 af 00 00  |.*.V.....D......|
  4. 0000007b  00 08 00 26 00 00 00 00  00 00 00 04 00 00 1a 00  |...&............|
  5. 0000008b  00 00 00 00 00 01 00 00  00 00 00 00 00 00 06 03  |................|
  6. 0000009b  73 74 64 04 21 00 21 00  08 00 74 65 73 74 00 42  |std.!.!...test.B|
  7. 000000ab  45 47 49 4e                                       |EGIN|
  9. #table_map event
  10. 000000af  95 2a 85 56 13 04 00 00  00 2e 00 00 00 dd 00 00  |.*.V............|
  11. 000000bf  00 00 00 32 00 00 00 00  00 01 00 04 74 65 73 74  |...2........test|
  12. 000000cf  00 04 74 72 6f 77 00 02  03 0f 02 0a 00 02        |..trow........|
  14. #write_rows event
  15. 000000dd  95 2a 85 56 17 04 00 00  00 29 00 00 00 06 01 00  |.*.V.....)......|
  16. 000000ed  00 00 00 32 00 00 00 00  00 01 00 02 ff fe 01 00  |...2............|
  17. 000000fd  00 00 fc 02 00 00 00 01  61                       |........a|
  19. #xid event
  20. 00000106  95 2a 85 56 10 04 00 00  00 1b 00 00 00 21 01 00  |.*.V.........!..|
  21. 00000116  00 00 00 f5 00 00 00 00  00 00 00                 |...........|

0x0000006b-0x000000ae为query event，语句是BEGIN,前面已经分析过。

table_map event

0x0000000af开始为table_map event。除去头部19个字节，Fixed data为8个字节，前面6个字节0x32=50为table id，接着2个字节0x0001为flags。

Variable data部分，首先1个字节0x04为数据库名test的长度，然后5个字节是数据库名test+结束符。接着1个字节0x04为表名长度，接着5个字节为表名trow+结束符。接着1个字节0x02为列的数目。而后是2个列的类型定义，分别是0x03和0x0f（列的类型MYSQL_TYPE_LONG为0x03，MYSQL_TYPE_VARCHAR为0x0f)。接着是列的元数据定义，首先0x02表示元数据长度为2，因为MYSQL_TYPE_LONG没有元数据，而MYSQL_TYPE_VARCHAR元数据长度为2。接着的0x000a就是MYSQL_TYPE_VARCHAR的元数据，表示我们在定义表时的varchar字段c长度为10，最后一个字节0x02为掩码，表示第一个字段i不能为NULL。关于列的类型以及元数据等更详细的信息可以参见http://dev.mysql.com/doc/internals/en/table-map-event.html。

write_rows event

从0x000000dd开始为write_rows event，除去头部19个字节，前6个字节0x32也是table id，然后两个字节0x0001为flags。接着的1个字节0x02为表中列的数目。然后1个字节0xff各个bit标识各列是否存在值，这里表示都存在。

接着的就是插入的各行数据了。第1个字节0xfe的各个bit标识该行变化之后各列是否为NULL，为NULL记为1.这里表示第1列不为NULL，因为第一行数据插入的是(1,NULL)。接下来是各列的数据，第一列是MYSQL_TYPE_LONG,长度为4个字节，所以0x00000001就是这个值。第二列是NULL不占字节。接下来是第二行，先是0xfc标识两列都不为NULL，先读取第一列的4个字节0x00000002也就是我们插入的数字2，然后读取第二列，先是一个字节的长度0x01，然后是内容0x61也就是字符'a'。到此，write_rows event也就分析完了。rows相关的event还有update_rows event和delete_rows event等，欲了解更多可以参见官方文档。

最后是xid event，之前已经分析过，不再赘述。

2.6 intvar event

intvar event在binlog_format=statement时使用到，用于自增键类型auto_increment，十分重要。intval event的Fixed data部分为空，而Variable data部分为9个字节，第1个字节用于标识自增事件类型 LAST_INSERT_ID_EVENT = 1 or INSERT_ID_EVENT = 2，余下的8个字节为自增ID。
创建一个测试表 create table tinc (i int auto_increment primary key, c varchar(10)) engine=innodb;，然后执行一个插入语句INSERT INTO tinc(c) values('abc');就可以看到intvar event了，这里的自增事件类型为INSERT_ID_EVENT。而如果用语句INSERT INTO tinc(i, c) VALUES(LAST_INSERT_ID()+1, 'abc')，则可以看到自增事件类型为LAST_INSERT_ID_EVENT的intvar event。

  1. | Log_name         | Pos | Event_type  | Server_id | End_log_pos | Info                                                   |
  2. +------------------+-----+-------------+-----------+-------------
  3. | mysql-bin.000079 |   4 | Format_desc |         4 |         107 | Server ver: 5.5.46-0ubuntu0.14.04.2-log, Binlog ver: 4 |
  4. | mysql-bin.000079 | 107 | Query       |         4 |         175 | BEGIN                                                  |
  5. | mysql-bin.000079 | 175 | Intvar      |         4 |         203 | INSERT_ID=1                                            |
  6. | mysql-bin.000079 | 203 | Query       |         4 |         299 | use `test`; insert into tinc(c) values('abc')          |
  7. | mysql-bin.000079 | 299 | Xid         |         4 |         326 | COMMIT /* xid=263 */

3 简单总结

上面提到，binlog有三种格式，各有优缺点：

  • statement：基于SQL语句的模式，某些语句和函数如UUID, LOAD DATA INFILE等在复制过程可能导致数据不一致甚至出错。
  • row：基于行的模式，记录的是行的变化，很安全。但是binlog会比其他两种模式大很多，在一些大表中清除大量数据时在binlog中会生成很多条语句，可能导致从库延迟变大。
  • mixed：混合模式，根据语句来选用是statement还是row模式。

不同版本的mysql在主从复制要慎重，虽然mysql5.0之后都用的V4版本的binlog了，估计还是会有些坑在里面，特别是高版本为主库，低版本为从库时容易出问题。在主从复制时最好还是主库从库版本一致，至少是大版本一致。mysql复制是个大的话题，希望有时间能单独总结一篇笔记。

4 参考资料

http://dev.mysql.com/doc/internals/en/binary-log.html

MySQL binlog格式解析的更多相关文章

  1. Mysql binlog日志解析

    1. 摘要: Mysql日志抽取与解析正如名字所将的那样,分抽取和解析两个部分.这里Mysql日志主要是指binlog日志.二进制日志由配置文件的log-bin选项负责启用,Mysql服务器将在数据根 ...

  2. my15_ mysql binlog格式从mixed修改为row格式

    由于主库繁忙,就在从库上修改binlog格式 1. 从库切日志mysql> flush logs;Query OK, 0 rows affected (0.00 sec) mysql> f ...

  3. 20180705关于mysql binlog的解析方式

    来自:https://blog.csdn.net/u012985132/article/details/74964366/ 关系型数据库和Hadoop生态的沟通越来越密集,时效要求也越来越高.本篇就来 ...

  4. 阿里云mysql数据库恢复总结，mysql binlog日志解析

    由于意外..阿里云mysql中有一张表被全部删除了,深吸三口气候,开始解决. 首先用凌晨的自动备份的,进行全量恢复,然后找binlog日志(见下文),查找从全量备份到数据删除之间的记录 这导致了一个问 ...

  5. 转载：阿里canal实现mysql binlog日志解析同步redis

    from: http://www.cnblogs.com/duanxz/p/5062833.html 背景 早期,阿里巴巴B2B公司因为存在杭州和美国双机房部署,存在跨机房同步的业务需求.不过早期的数 ...

  6. mysql binlog格式

    Binlog Event 对于一个 Binlog Event 来说,它分为三个部分,header,post-header 以及 payload.MySQL 的 Binlog Event 有很多版本,我 ...

  7. 对MySQL binlog日志解析，统计每张表的DML次数

    想要获取每天数据库每张表的DML的次数,统计热度表,可以使用该脚本 # coding:utf-8 # 解析binlog,统计热度表,表的DML个数 import sys import os # mys ...

  8. MySQL binlog反解析

    反解析delete语句 背景:delete table忘了加条件导致整张表被删除 恢复方式:直接从binlog里反解析delete语句为insert进行恢复 导出删指定表的DELETE语句: # my ...

  9. MySQL Binlog 介绍

    Binlog 简介 MySQL中一般有以下几种日志: 日志类型 写入日志的信息 错误日志 记录在启动,运行或停止mysqld时遇到的问题 通用查询日志 记录建立的客户端连接和执行的语句 二进制日志 记 ...

随机推荐

  1. Python -- Gui编程 -- Win32API的使用

    消息框 messageBox.py import win32api, win32con win32api.MessageBox(0, 'Hello World!', 'Come Here', win3 ...

  2. ActiveMQ消息持久化到Mysql数据库

    1.把连接MySQL数据库的jar文件,放到ActiveMQ的lib目录下 2.修改ActiveMQ的conf目录下的activemq.xml文件,修改数据持久化的方式2.1 修改原来的kahadb的 ...

  3. 机器学习--聚类系列--K-means算法

    一.聚类 聚类分析是非监督学习的很重要的领域.所谓非监督学习,就是数据是没有类别标记的,算法要从对原始数据的探索中提取出一定的规律.而聚类分析就是试图将数据集中的样本划分为若干个不相交的子集,每个子集 ...

  4. Ruby语言学习系列--String 类函数

        函数名称 说明 示例 * 将字符串拷贝N次 “ha”*4    >> “hahahaha” + <<  concat 连接字符串 “yes” + “no”  >& ...

  5. java.sql.SQLException: Access denied for user 'root '@'localhost' (using password: YES) 最蠢

    我犯了七年前的错误,一个空格,昨天就想到的,还对比了一下密码有没有空格 问题原因1:多写空格 在datasource.properties 中的username 的值root后面多写了一个空格, jd ...

  6. RabbitMQ.NET In Window Service

    工作中要求使用RabbitMQ,以Windows Service 模式启动,中间有遇到一些问题,网上大部分博客有误导倾向, 在这里做一个简单的记录,以免后面的人走坑: 1. 自动重新连接,不需要手动处 ...

  7. C#基础笔记(第十四天)

    1.MD5加密 用户在数据库存密码需要进行再加密,这样一个过程叫MD5加密只要涉及到存用户的密码一定要用MD5加密MD5密码一般都是16进制的把一个密码转换成16进制的过程就叫MD5加密把字符串加密成 ...

  8. PHP 错误解决锦集

    Part1:Maximum execution time of 120 seconds exceeded 120秒运行超时的错误 解决办法: 方法一,修改php.ini文件 max_execution ...

  9. AutoFac使用方法总结三：生命周期

         生命周期 AutoFac中的生命周期概念非常重要,AutoFac也提供了强大的生命周期管理的能力.     AutoFac定义了三种生命周期: Per Dependency Single I ...

  10. MQ与Webservice的区别

    Webservice 和MQ(MessageQueue)都是解决跨平台通信的常用手段,两者有哪些区别呢? 个人认为最本质的区别在于 Webservice近乎实时通信,而MQ却通常是延时通信. 什么意思 ...