flink实时数仓(二):mysql主备以及binglog

mysql主备复制实现

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

MySQL Binary Log

mysql-binlog是MySQL数据库的二进制日志，用于记录用户对数据库操作的SQL语句（( 除了数据查询语句）信息。如果后续我们需要配置主从数据库，如果我们需要从数据库同步主数据库的内容，我们就可以通过binlog来进行同步
简而言之：
mysql的binlog是多文件存储，定位一个LogEvent需要通过binlog filename + binlog position，进行定位。
mysql的binlog数据格式，按照生成的方式，主要分为：statement-based、row-based、mixed(混合)。

binlog的格式也有三种：STATEMENT、ROW、MIXED

STATMENT模式

基于SQL语句的复制(statement-based replication, SBR)，每一条会修改数据的sql语句会记录到binlog中。
优点：

不需要记录每一条SQL语句与每行的数据变化，这样子binlog的日志也会比较少，减少了磁盘IO，提高性能。

缺点：

在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)

基于行的复制(row-based replication, RBR)：

不记录每一条SQL语句的上下文信息，仅需记录哪条数据被修改了，修改成了什么样子了。
优点：

不会出现某些特定情况下的存储过程或function、或trigger的调用和触发无法被正确复制的问题。

缺点：

会产生大量的日志，尤其是alter table的时候会让日志暴涨。

混合模式复制(mixed-based replication, MBR)：

以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog， MySQL会根据执行的SQL语句选择日志保存方式。

注意目前canal支持所有模式的增量订阅(但配合同步时，因为statement只有sql，没有数据，无法获 取原始的变更日志，所以一般建议为ROW模式)