mysql主从关键特性

binlog 的三种格式:一种是 statement，一种是 row。可能你在其他资料上还会看到有第三种格式，叫作 mixed，其实它就是前两种格式的混合。

进入mysql的bin目录，用mysqlbinlog工具查看binlog。
例如mysqlbinlog ../data/mysql-bin.000011 --base64-output=decode-rows -v | more 
其中的： --base64-output=decode-rows –v 选项解析中，
base64-output，可以控制输出语句输出base64编码的BINLOG语句;
decode-rows：选项将把基于行的事件解码成一个SQL语句。

XID是用来联系bin log和redo log的。比如redo log里面有一个事务是prepare状态，但是不知道是不是commit状态，那就可以用XID去bin log里面查询该事务到底有没有提交。有提交则是commit状态，若没有提交则回滚该事务。
redo log 和 binlog 是怎么关联起来的?
回答：它们有一个共同的数据字段，叫 XID。崩溃恢复的时候，会按顺序扫描 redo log：如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。






– 查看bin_log格式
show variables like ‘binlog_format’;
– 查看是否开启了bin_log
show variables like ‘log_bin’;
– 查看master上日志
show master logs;
– 查看正在写入的binlog文件
show master status ;


说到循环复制问题的时候，我们说 MySQL 通过判断 server id 的方式，断掉死循环。但是，这个机制其实并不完备，在某些场景下，还是有可能出现死循环?
一种场景是，在一个主库更新事务后，用命令 set global server_id=x 修改了 server_id。等日志再传回来的时候，发现 server_id 跟自己的 server_id 不同，就只能执行了。另一种场景是，有三个节点的时候，如图 7 所示，trx1 是在节点 B 执行的，因此 binlog 上的 server_id 就是 B，binlog 传给节点 A，然后 A 和 A’搭建了双 M 结构，就会出现循环复制。