分析Canal如何支持MySQL主从同步

本文结合MySQL提供的协议，逐步分析Canal从连接到订阅binlog这一过程。

1、Canal连接MySQL

MySQL初始化完成之后，就会监听并准备接收来自外部的连接请求。它将这一逻辑交给handle_connections_methods()函数去完成。该函数主要监听三种连接方式，分别是命名管道（namedpipes）、TCP/IP（sockets）以及共享内存（shared_memory）。一般我们的客户端（例如JDBC驱动和mysqld）都是用TCP/IP的方式连接MySQL服务器，而后两种一般在嵌入式开发用的比较多。

Canal采用TCP/IP的方式模拟MySQL连接协议交互，所以下面我们也会以TCP/IP的维度去分析Canal如何连接上MySQL节点。

1.1、协议数据包

在介绍如何连接前，我们需要知道MySQL数据包的组成。和众多基于TCP开发的应用一样，MySQL为了解决粘包问题，自定义了自己数据包的帧格式。所有的数据包均有header和body两部分组成。

header由data length和sequence_id两部分组成，共4个字节，其中data length表示body数据长度的，占3个字节，这也导致Server发送到Client的最大packet大小为(2^24−1) bytes，也就是16M，超出的大小将会被分到不同的packet中；而sequence_id仅有1个字节，目的是防止串包。机制是每收到一个报文都在其 sequenceId 上加 1，并随着需要返回的信息返回回去。如果 DB 检测到 sequenceId 连续，则表明没有串包。如果不连续，则串包，DB 会直接丢弃这个连接。除此之外，分包的后每个包sequence依次加1。

body表示具体传输的数据，也就是有效负载，不同的协议这部分传递的信息不同。

1.2、连接过程

MySQL的连接阶段主要包含“握手”和“认证”两个步骤，不管是Canal、slave还是其他jdbc服务，都要经过以下步骤，具体参考下图。

在MySQL和客户端建立了TCP连接后，Server端会优先再一次发起一次握手请求，这个过程也是三次握手。该握手过程主要涉及以下任务：

1. Server和Client互相交换能力(capabilities);
2. 根据Client需要选择建立基于SSL的通道；
3. 针对服务器对客户端进行身份验证(authenticate the client against the server)。

下面我们来逐点分析：

1.2.1、Initial Handshake

在MySQL中，Server会在TCP的三次握手后主动发送请求，而第一阶段就是发送Handshake Packet，该packet中主要包含MySQL服务端的一些参数信息，例如服务端的版本号，通信过程中的最大消息长度，编码信息以及用于Client认证选取的方法等等。（注意MySQL3.21.0后的版本都是发送Protocol::HandshakeV10版本，其他版本忽略）

相关字段解析如下：

protocol_version：服务器协议版本号，默认为10。
server_version：服务器的版本号。
thread id：服务器为客户端分配的线程id，可以通过SHOW PROCESSLIST看到。
auth-plugin-data-part-1：服务器生成的用于验证随机字符串（有的地方叫挑战随机数）的前8个字节。
filter：默认0x00的填充值
capability_flags_1：服务端的能力（capabilities）低两个字节
character_set：字符编码号。
status_flags：服务器状态。
capability_flags_2：服务端的能力（capabilities）高两个字节
auth_plugin_data_len： 随机字符串总长度
reserved：默认0x00填充值
auth-plugin-data-part-2：服务器生成的用于验证随机字符串数据的剩余字节。
auth_plugin_name：用户校验插件名

注：相关代码在文件sql/sql_acl.cc的函数send_server_handshake_packet中

Handshake Packet这里需要重点关注和用户认证相关的auth_plugin_name、auth-plugin-data-part-1/2，以及表示服务端能力的capability_flags_1/2。

先来看第一个东西，挑战随机数。MySQL数据库用户认证采用的是挑战/应答的方式，服务器生成该挑战数并发送给客户端，由客户端进行处理并返回相应结果，然后服务器检查是否与预期的结果相同，从而完成用户认证的过程。这里涉及到MySQL的认证过程：

a、MySQL将用户的密码已密文的形式存储在mysql.user表的password字段中，密文的加密方式是通过对明文密码的进行两次SHA1计算出来的哈希值，代码中称这计算出来的哈希值为stage2hash。也就是说stage2hash的计算方式为：

                                               stage2hash = SHA1(SHA1(明文密码)）

这里猜测MySQL的设计者故意进行两次SHA1的理由是怕用户的密码设置比较简单，通过暴力方式还是可以解出比较简单的密码，第二次SHA1的参数会是一个复杂无规则的160位字符串。所以即使这个哈希值被盗取了，依然无法解析出原本的明文密码。

b、客户端将MySQL发送过来的挑战随机数（代码中称为scramble），同样进行SHA1的加密生成密钥key，计算方式是：

                                                 key = SHA1(scramble|stage2hash)

客户端将收到的scramble和本地计算的stage2hash一起SHA1后，生成密钥，并将密钥和stage1hash进行加密，加密的方式是对key和stage1hash进行一次XOR操作，而stage1hash是对明文密码进行一次SHA1后的结果，也就是

                                    发送给服务端的密码密文 = XOR(key，SHA1(明文密码))

c、服务端分析密文是否正确也很简单，将key和客户端发送的密文进行一次XOR，得到stage1hash，然后再对stage1hash进行一次SHA1，将得到的结果和数据库存的进行比较就行。

其次第二个东西是表示服务端能力的capability_flags_1/2，MySQL版本比较多，客户端和服务端的版本不一定匹配，客户端需要的功能，或者服务端支持的功能之间需要有一个协商，握手中会传递这一部分。协商时主要依赖capabilities flag，其中包括是否支持压缩功能、长密码和SSL等等

1.2.2、HandShake Response

Client在收到来自Server的Handshake Packet之后，可以根据需要选择基于SSL的通信，还是普通文本。这里我们介绍下基于SSL的连接，注意支持SSL的前提是需要前面服务端给的capabilities有提供CLIENT_SSL 能力。

当服务端发送完Protocol::Handshake数据包后，客户端可以发送Protocol::SSLRequest建立SSL连接，其中的SSLRequest packet payload如下：

 需要注意一点是，当请求SSL连接时，需要把CLIENT_SSL capabitities塞入到请求中。

1.3.3、认证成功

假如认证成功后, 服务端会向客户端返回 OK_Packet，认证失败, 会向客户端返回 ERR_Packet。

• OK_Packet：表示Client发送的命令执行成功，第1个字节值等于 00
• ERR_Packet：表示发生异常，第1个字节值等于 FF，对应10进制为-1

所以需要判断认证成功还是失败，只需要判断接收到的包第一个字节值是否为10进制的-1 还是0

1.3.4、Canal和MySQL连接分析

这里分析的是Canal和MySQL建立了TCP之后的，Handshake Packet和SSLRequest Packet的交互，实现放在了MysqlConnector.negotiate方法中。

    // MysqlConnector.java
    private void negotiate(SocketChannel channel) throws IOException {
        // Mysql发出的包，header大小都为4个字节
        HeaderPacket header = PacketManager.readHeader(channel, 4, timeout);
        // 获取到header之后，取前面3个字节组成的数字即为接下来packet body也就是payload大小
        byte[] body = PacketManager.readBytes(channel, header.getPacketBodyLength(), timeout);
        if (body[0] < 0) {// check field_count
            if (body[0] == -1) {
                ErrorPacket error = new ErrorPacket();
                error.fromBytes(body);
                throw new IOException("handshake exception:\n" + error.toString());
            } else if (body[0] == -2) {
                throw new IOException("Unexpected EOF packet at handshake phase.");
            } else {
                throw new IOException("unpexpected packet with field_count=" + body[0]);
            }
        }
        HandshakeInitializationPacket handshakePacket = new HandshakeInitializationPacket();
        // 将获取过来的body解析为HandshakeInitializationPacket包
        handshakePacket.fromBytes(body);
        connectionId = handshakePacket.threadId; // 记录一下connection

        logger.info("handshake initialization packet received, prepare the client authentication packet to send");

        // 这里canal用的是SSL连接，返回的是SSLRequest
        ClientAuthenticationPacket clientAuth = new ClientAuthenticationPacket();
        clientAuth.setCharsetNumber(charsetNumber);

        clientAuth.setUsername(username);
        clientAuth.setPassword(password);
        // 注意这里canal把server发送过来的全部capabilities发送获取
        clientAuth.setServerCapabilities(handshakePacket.serverCapabilities);
        clientAuth.setDatabaseName(defaultSchema);
        // 拼接随机挑战数的高低位
        clientAuth.setScrumbleBuff(joinAndCreateScrumbleBuff(handshakePacket));

        byte[] clientAuthPkgBody = clientAuth.toBytes();
        HeaderPacket h = new HeaderPacket();
        h.setPacketBodyLength(clientAuthPkgBody.length);
        // sequence + 1
        h.setPacketSequenceNumber((byte) (header.getPacketSequenceNumber() + 1));

        // 将SSL Request写到和mysql连接的channel中
        PacketManager.writePkg(channel, h.toBytes(), clientAuthPkgBody);
        logger.info("client authentication packet is sent out.");

        // 再次获取server发送过来的packet，检查验证是否成功
        header = null;
        header = PacketManager.readHeader(channel, 4);
        body = null;
        body = PacketManager.readBytes(channel, header.getPacketBodyLength(), timeout);
        assert body != null;
        // 不为0则表示认证失败
        if (body[0] < 0) {
            // -1表示Err_packet
            if (body[0] == -1) {
                ErrorPacket err = new ErrorPacket();
                err.fromBytes(body);
                throw new IOException("Error When doing Client Authentication:" + err.toString());
            } else if (body[0] == -2) {
                auth323(channel, header.getPacketSequenceNumber(), handshakePacket.seed);
                // throw new
                // IOException("Unexpected EOF packet at Client Authentication.");
            } else {
                throw new IOException("unpexpected packet with field_count=" + body[0]);
            }
        }
    }

2、Register

成功连接到Mysql后，任何slave节点在获取binlog前，都需要向master发送COM_REGISTER_SLAVE命令进行注册。该命令的payload如下（左边数字表示长度，下同）：

1              [15] COM_REGISTER_SLAVE，第一个字节值恒定为16进制的15，如果划算成10进制就是21
4              server-id，slave的server id，不同的slave必须有不同的slaveId
1              slaves hostname length，slave的host信息长度
string[$len]   slaves hostname，slave的host信息
1              slaves user len，slave用于连接master的账号名长度
string[$len]   slaves user，slave用于连接master的账号名，需要有replication slave和replication client 权限
1              slaves password len，slave用于连接master的密码长度
string[$len]   slaves password，slave用于连接master的密码
2              slaves mysql-port，slave的端口
4              replication rank，这个估计没用的字段，忽略即可
4              master-id，通常为0

在MySQL Replication中，都需要使用一个唯一server id来区别不同的server实例。

canal在 RegisterSlaveCommandPacket 类中实现了关于COM_BINLOG_DUMP命令的封装

public class RegisterSlaveCommandPacket extends CommandPacket {

    // implement by parent
    private byte command;

    public String reportHost;
    public int    reportPort;
    public String reportUser;
    public String reportPasswd;
    public long   serverId;

    public RegisterSlaveCommandPacket(){
        setCommand((byte) 0x15);
    }

    // implement by parent
    public byte getCommand() {
        return command;
    }

    public byte[] toBytes() throws IOException {
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        out.write(getCommand());
        ByteHelper.writeUnsignedIntLittleEndian(serverId, out);
        out.write((byte) reportHost.getBytes().length);
        ByteHelper.writeFixedLengthBytesFromStart(reportHost.getBytes(), reportHost.getBytes().length, out);
        out.write((byte) reportUser.getBytes().length);
        ByteHelper.writeFixedLengthBytesFromStart(reportUser.getBytes(), reportUser.getBytes().length, out);
        out.write((byte) reportPasswd.getBytes().length);
        ByteHelper.writeFixedLengthBytesFromStart(reportPasswd.getBytes(), reportPasswd.getBytes().length, out);
        ByteHelper.writeUnsignedShortLittleEndian(reportPort, out);
        ByteHelper.writeUnsignedIntLittleEndian(0, out);// Fake
                                                        // rpl_recovery_rank
        ByteHelper.writeUnsignedIntLittleEndian(0, out);// master id
        return out.toByteArray();
    }
    
    ...
}

注意，在toBytes()方法里面拼装数据时，用了小端模式。MySQL的报文采用的是小端模式（而PostgreSQL采用的则是大端模式）

3、Binlog Dump

MySQL支持两种binlog dump的命令，分别是指定binlog filename + position的COM_BINLOG_DUMP，以及通过指定GTID的 COM_BINLOG_DUMP_GTID。

3.1、COM_BINLOG_DUMP

该命令用于根据指定的binlog文件位置，从Master中获取binlog文件流。

1              [12] COM_BINLOG_DUMP 16进制的12，表示该命令为获取binlog流
4              binlog-pos 指定binlog文件的位置
2              flags 目前只有一个值，也就是BINLOG_DUMP_NON_BLOCK（0X01）
4              server-id slave的server_id
string[EOF]    binlog-filename binlog文件名

注意点1：并非需要指定binlog filename，没有指定时将默认从Master的第一个binlog文件开始消费起；（可以通过SHOW BINARY LOGS知道当前第一个binlog的文件和大小）

注意点2：关于payload的第三个参数flags，目前仅有一个值就是0x01，表示BINLOG_DUMP_NON_BLOCK，该值的意思是当没有更多的binlog event时，就返回一个EOF Packet给Slave，而不是阻塞当前连接；

注意点3：Master接收到该指令后，并非会返回binlog event或者时EOF Package，有可能也会返回一个Error Packet，例如找不到指定的binlog文件或者是没有复制权限。

canal在 BinlogDumpCommandPacket 实现发送请求binlog 命令：

    public byte[] toBytes() throws IOException {
        ByteArrayOutputStream out = new ByteArrayOutputStream();
        // 0. write command number
        out.write(getCommand());
        // 1. write 4 bytes bin-log position to start at
        ByteHelper.writeUnsignedIntLittleEndian(binlogPosition, out);
        // 2. write 2 bytes bin-log flags
        int binlog_flags = 0;
        binlog_flags |= BINLOG_SEND_ANNOTATE_ROWS_EVENT;
        out.write(binlog_flags);
        // 补0x00 是因为flags长度不够2个字节
        out.write(0x00);
        // 3. write 4 bytes server id of the slave
        ByteHelper.writeUnsignedIntLittleEndian(this.slaveServerId, out);
        // 4. write bin-log file name if necessary
        if (StringUtils.isNotEmpty(this.binlogFileName)) {
            out.write(this.binlogFileName.getBytes());
        }
        return out.toByteArray();
    }

这里canal为兼容MariaDB，指定binlog flags值为BINLOG_SEND_ANNOTATE_ROWS_EVENT，该值对应0x10，在MySQL中是无效的，所以MySQL当没有binlog event时，不会发送EOF给canal，而是阻塞当前线程。

但是当源是MariaDB时，该参数的值0x10表示允许发送AnnotateRowsEvent，否则以空的QueryLogEvent来代替。

3.2、COM_BINLOG_DUMP_GTID

跳过(●'◡'●)

4、Binlog Event

当canal发送完Binlog Dump的命令之后，Mysql就会开始推送将一个个binlog event推送给canal。需要注意的是，每次Mysql都只会推送一个event给下游的slave，我们先来看下binlog event packet结构。

4.1、binlog event packet

每个event包括Binlog event header，Post-Header和Body三部分，注意区分这里的EventHeader和MySQL发送过来的packet的header，后者是MySQL网络层发送时自动加上的，非binlog字节管理的部分。

对于所有event而言，Binlog Eventheader的长度与格式是相同的，Post-Header对于同类型的event是长度相同的，部分类型的event并没有Post-Header。而Body则为event中的最终的部分，表示具体信息，同样也不是所有的event都会有body，FORMAT_DESCRIPTION_EVENT就没有。

EventHeader表示通用的事件头，其结构如下：

4              timestamp
1              event type
4              server-id
4              event-size
   if binlog-version > 1:
4              log pos
2              flags

• timestamp (4) -- Unix事件戳，表示event产生的事件

• event_type (1) -- binlog 事件类型

• server_id (4) --  产生事件的mysql serverId

• event_size (4) -- 事件大小，这里的大小=EventHader自身 + EventBody

• log_pos (4) -- 下一个事件的位点，也就是binlog文件的position

• flags (2) --  binlog事件标识

canal将获取binlog event的实现放在类DirectLogFetcher.fetch方法中。

EventBody就不介绍了，不同的事件其结构有不同，详情可以查看binlog event 列表

4.2、Canal获取binlog event stream

canal获取binlog event流的实现逻辑是在DirectLogFetcher.fetch方法中

    // DirectLogFetcher
    public boolean fetch() throws IOException {
        try {
            // Fetching packet header from input.
            // 从MySQL的连接中（默认是Socket）获取消息头，由上面的介绍可知header大小为4个字节
            // 所以这里的NET_HEADER_SIZE值是4
            if (!fetch0(0, NET_HEADER_SIZE)) {
                logger.warn("Reached end of input stream while fetching header");
                return false;
            }

            // Fetching the first packet(may a multi-packet).
            // header的前3个字节表示body的长度
            int netlen = getUint24(PACKET_LEN_OFFSET);
            // header的最后一个字节表示sequenceId
            int netnum = getUint8(PACKET_SEQ_OFFSET);
            // 根据header给出的body大小，获取payload
            if (!fetch0(NET_HEADER_SIZE, netlen)) {
                logger.warn("Reached end of input stream: packet #" + netnum + ", len = " + netlen);
                return false;
            }

            // mark是4个字节的整形数字，表示当前同步是否异常
            final int mark = getUint8(NET_HEADER_SIZE);
            if (mark != 0) {
                if (mark == 255) // error from master
                {
                    // Indicates an error, for example trying to fetch from
                    // wrong
                    // binlog position.
                    position = NET_HEADER_SIZE + 1;
                    final int errno = getInt16();
                    String sqlstate = forward(1).getFixString(SQLSTATE_LENGTH);
                    String errmsg = getFixString(limit - position);
                    throw new IOException("Received error packet:" + " errno = " + errno + ", sqlstate = " + sqlstate
                                          + " errmsg = " + errmsg);
                } else if (mark == 254) {
                    // Indicates end of stream. It's not clear when this would
                    // be sent.
                    logger.warn("Received EOF packet from server, apparent"
                                + " master disconnected. It's may be duplicate slaveId , check instance config");
                    return false;
                } else {
                    // Should not happen.
                    throw new IOException("Unexpected response " + mark + " while fetching binlog: packet #" + netnum
                                          + ", len = " + netlen);
                }
            }

            // 当前mysql是否处于半同步状态
            if (issemi) {
                // parse semi mark
                int semimark = getUint8(NET_HEADER_SIZE + 1);
                int semival = getUint8(NET_HEADER_SIZE + 2);
                this.semival = semival;
            }

            // 就前面知道MySQL一个packet的payload最大是16M，这里通过判断payload是否
            // 为16M进行组包，当payload大小为16M时，则需要从socket中获取下一个packet,
            // 组装成一个完整的event再返回给调用方，知道payload的大小不再是16M。
            // 那么如果event的大小刚好是16M的整数倍会怎样，此时MySQL会在发送完完整的event
            // 之后，再发送一个body长都为0的packet表示结束。
            while (netlen == MAX_PACKET_LENGTH) {
                if (!fetch0(0, NET_HEADER_SIZE)) {
                    logger.warn("Reached end of input stream while fetching header");
                    return false;
                }

                netlen = getUint24(PACKET_LEN_OFFSET);
                netnum = getUint8(PACKET_SEQ_OFFSET);
                if (!fetch0(limit, netlen)) {
                    logger.warn("Reached end of input stream: packet #" + netnum + ", len = " + netlen);
                    return false;
                }
            }

            // Preparing buffer variables to decoding.
            if (issemi) {
                origin = NET_HEADER_SIZE + 3;
            } else {
                origin = NET_HEADER_SIZE + 1;
            }
            position = origin;
            limit -= origin;
            return true;
        } catch (SocketTimeoutException e) {
            close(); /* Do cleanup */
            logger.error("Socket timeout expired, closing connection", e);
            throw e;
        } catch (InterruptedIOException e) {
            close(); /* Do cleanup */
            logger.info("I/O interrupted while reading from client socket", e);
            throw e;
        } catch (ClosedByInterruptException e) {
            close(); /* Do cleanup */
            logger.info("I/O interrupted while reading from client socket", e);
            throw e;
        } catch (IOException e) {
            close(); /* Do cleanup */
            logger.error("I/O error while reading from client socket", e);
            throw e;
        }
    }

MysqlConnection.seek负责调用DirectLogFetcher.fetch方法，在循环中不断获取binlog event

    public void seek(String binlogfilename, Long binlogPosition, SinkFunction func) throws IOException {
        updateSettings();

        // 设置binlog位点
        sendBinlogDump(binlogfilename, binlogPosition);
        DirectLogFetcher fetcher = new DirectLogFetcher(connector.getReceiveBufferSize());
        fetcher.start(connector.getChannel());
        LogDecoder decoder = new LogDecoder();
        // 指定需要获取的binlog事件
        decoder.handle(LogEvent.ROTATE_EVENT);
        decoder.handle(LogEvent.FORMAT_DESCRIPTION_EVENT);
        decoder.handle(LogEvent.QUERY_EVENT);
        decoder.handle(LogEvent.XID_EVENT);
        LogContext context = new LogContext();
        while (fetcher.fetch()) {
            accumulateReceivedBytes(fetcher.limit());
            LogEvent event = null;
            // 将socket中拿到的二进制流解析成对应的binlog事件
            event = decoder.decode(fetcher, context);

            if (event == null) {
                throw new CanalParseException("parse failed");
            }

            // 调用sink方法将event暂时存储到EventTransactionBuffer中
            if (!func.sink(event)) {
                break;
            }
        }
    }

（将从socket获取到二进制流解析成对应的event步骤跳过，T_T event 类型太多文章写不下来，就知道有这个步骤就行）

canal从socket中获取到完整的event并解析完成后，在sink方法就会调用EventTransactionBuffer.add方法放入到buffer中。

    // EventTransactionBuffer.java
    public void add(CanalEntry.Entry entry) throws InterruptedException {
        switch (entry.getEntryType()) {
            case TRANSACTIONBEGIN:
                flush();// 刷新上一次的数据
                put(entry);
                break;
            case TRANSACTIONEND:
                put(entry);
                flush();
                break;
            case ROWDATA:
                put(entry);
                // 针对非DML的数据，直接输出，不进行buffer控制
                EventType eventType = entry.getHeader().getEventType();
                if (eventType != null && !isDml(eventType)) {
                    flush();
                }
                break;
            case HEARTBEAT:
                // master过来的heartbeat，说明binlog已经读完了，是idle状态
                put(entry);
                flush();
                break;
            default:
                break;
        }
    }

    private void put(CanalEntry.Entry data) throws InterruptedException {
        // 首先检查是否有空位
        if (checkFreeSlotAt(putSequence.get() + 1)) {
            long current = putSequence.get();
            long next = current + 1;

            // 先写数据，再更新对应的cursor,并发度高的情况，putSequence会被get请求可见，拿出了ringbuffer中的老的Entry值
            entries[getIndex(next)] = data;
            putSequence.set(next);
        } else {
            flush();// buffer区满了，刷新一下
            put(data);// 继续加一下新数据
        }
    }

canal会在检测到事件类型为事件头，事件尾，非DML语句（例如DDL），心跳事件或者buffer满了之后，会立即调用sink模块判断是否需要过滤该事件，随后再调用store模块写入目标存储。

关于buffer，其本质是一个内存数组，大小由配置参数canal.instance.transaction.size决定，默认是1024，这个参数主要控制parser解析后，提交到event store时，能够保证的事务一致性的数量。例如当你提交一个大事务时，其中的event数量超出了1024，此时buffer只能保证以1024为单位的event能够被一次性刷入到event store。按作者的说法，目前get数据获取时，暂时没有考虑事务完整读取的机制，主要还是考虑业务需求，对于事务完整性不敏感. 要保证完整读取其实也不难。

这里简单介绍下Canal如何获取binlog二进制流，和暂存的buffer，至于详细的parse模块、sink和store模块，甚至Canal的具体架构，可以看下田工的博客 田守枝canal源码分析

5、参考文档 

1、田守枝canal源码分析

2、MySQL官方主从同步协议介绍