mysql mask from v2_深入解析MySQL replication协议

Why

最开始的时候，go-mysql只是简单的抽象mixer的代码，提供一个基本的mysql driver以及proxy framework，但做到后面，笔者突然觉得，既然研究了这么久mysql client/server protocol，干脆顺带把replication protocol也给弄明白算了。现在想想，幸好当初决定实现了replication的支持，不然后续go-mysql-elasticsearch这个自动同步MySQL到Elasticsearch的工具就不可能在短时间完成。

其实MySQL replication protocol很简单，client向server发送一个MySQL binlog dump的命令，server就会源源不断的给client发送一个接一个的binlog event了。

Register

首先，我们需要伪造一个slave，向master注册，这样master才会发送binlog event。注册很简单，就是向master发送COM_REGISTER_SLAVE命令，带上slave相关信息。这里需要注意，因为在MySQL的replication topology中，都需要使用一个唯一的server id来区别标示不同的server实例，所以这里我们伪造的slave也需要一个唯一的server id。

Binlog dump

最开始的时候，MySQL只支持一种binlog dump方式，也就是指定binlog filename + position，向master发送COM_BINLOG_DUMP命令。在发送dump命令的时候，我们可以指定flag为BINLOG_DUMP_NON_BLOCK，这样master在没有可发送的binlog event之后，就会返回一个EOF package。不过通常对于slave来说，一直把连接挂着可能更好，这样能更及时收到新产生的binlog event。

在MySQL 5.6之后，支持了另一种dump方式，也就是GTID dump，通过发送COM_BINLOG_DUMP_GTID命令实现，需要带上的是相应的GTID信息，不过笔者觉得，如果只是单纯的实现一个能同步binlog的工具，使用最原始的binlog filename + position就够了，毕竟我们不是MySQL，解析GTID还是稍显麻烦的。这里，顺带吐槽一下MySQL internal文档，里面关于GTID encode的格式说明竟然是错误的，文档格式如下:

4 n_sids

for n_sids {

string[16] SID

8 n_intervals

for n_intervals {

8 start (signed)

8 end (signed)

}

但实际坑爹的是n_sids的长度是8个字节。这个错误可以算是血的教训，