binlog以及Canel

一、NDB存储引擎

在介绍binlog之前，需要先了解一下NDB
NDB 存储引擎也叫NDB Cluster 存储引擎，主要用于MySQL Cluster 分布式集群环境。

NDB特点：
• 分布式：分布式存储引擎，可以由多个NDBCluster存储引擎组成集群分别存放整体数据的一部分
• 支持事务：和Innodb一样，支持事务
• 可与mysqld不在一台主机：可以和mysqld分开存在于独立的主机上，然后通过网络和mysqld通信交互
• 内存需求量巨大：新版本索引以及被索引的数据必须存放在内存中，老版本所有数据和索引必须存在与内存中

二、Mysql集群

mysql主从备份实现:

• master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events，可以通过show binlog events进行查看）；
• slave将master的binary log events拷贝到它的中继日志(relay log)；
• slave重做中继日志中的事件，将改变反映它自己的数据。
  

如果你能将自己伪装为一个mysql slave，就可以欺骗mysql master给自己推送中继日志，从而实现增量获取事件的功能。阿里开源的canel就是这样做的。

三、Binlog

简单点说：

• binlog是一个二进制格式的文件，用于记录用户对数据库更新的SQL语句信息，例如更改数据库表和更改内容的SQL语句都会记录到binlog里，但是对库表等内容的查询不会记录。
• mysql的binlog数据格式，按照生成的方式，主要分为：statement-based、row-based、mixed。

• 使用mysqlbinlog解析查看

  一般来说开启二进制日志大概会有1%的性能损耗(参见MySQL官方中文手册 5.1.24版)。二进制有两个最重要的使用场景:
  其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。 （数据库的主从复制）
  其二：自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。

一、开启binlog日志：
vi编辑打开mysql配置文件

 # vi /usr/local/mysql/etc/my.cnf

在[mysqld] 区块
设置/添加 log-bin=mysql-bin 确认是打开状态(值 mysql-bin 是日志的基本名或前缀名)；
重启mysqld服务使配置生效

# pkill mysqld
# /usr/local/mysql/bin/mysqld_safe --user=mysql &

二、也可登录mysql服务器，通过mysql的变量配置表，查看二进制日志是否已开启 单词：variable[ˈvɛriəbəl] 变量
登录服务器

# /usr/local/mysql/bin/mysql -uroot -p123456
mysql> show variables like 'log_%'; 

三、常用binlog日志操作命令

1.查看所有binlog日志列表

    mysql> show master logs;

2.查看master状态，即最后(最新)一个binlog日志的编号名称，及其最后一个操作事件pos结束点(Position)值

    mysql> show master status;

3.刷新log日志，自此刻开始产生一个新编号的binlog日志文件

     mysql> flush logs;

注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志；在mysqldump备份数据时加 -F 选项也会刷新binlog日志；
4.重置(清空)所有binlog日志

     mysql> reset master;

四、查看某个binlog日志内容
这里介绍一种方便的查询命令：

mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

选项解析：
IN ‘log_name’ 指定要查询的binlog文件名(不指定就是第一个binlog文件)
FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
LIMIT [offset,] 偏移量(不指定就是0)
row_count 查询总条数(不指定就是所有行)

四、Canel

canal是阿里巴巴旗下的一款开源项目，纯Java开发。基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了MySQL（也支持mariaDB）。

起源：早期，阿里巴巴B2B公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需求。不过早期的数据库同步业务，主要是基于trigger的方式获取增量变更，不过从2010年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅&消费的业务，从此开启了一段新纪元。

基于日志增量订阅&消费支持的业务：

数据库镜像
数据库实时备份
多级索引 (卖家和买家各自分库索引)
search build
业务cache刷新
价格变化等重要业务消息

原理相对比较简单：

1、canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
2、mysql master收到dump请求，开始推送binary log给slave(也就是canal)
3、canal解析binary log对象(原始为byte流)

架构设计
个人理解，数据增量订阅与消费应当有如下几个点：

1、增量订阅和消费模块应当包括binlog日志抓取，binlog日志解析，事件分发过滤（EventSink），存储（EventStore）等主要模块。
2、如果需要确保HA可以采用Zookeeper保存各个子模块的状态，让整个增量订阅和消费模块实现无状态化，当然作为consumer(客户端)的状态也可以保存在zk之中。
3、整体上通过一个Manager System进行集中管理，分配资源。

源码以及项目介绍： https://github.com/alibaba/canal
canal消费端项目开源:Otter(分布式数据库同步系统)，地址：https://github.com/alibaba/otter