mysql 复制

三种复制技术

二进制日志文件 Binlog有三种格式：

Statement:基于 SQL语句级别的 Binlog,每条修改数据的 SQL都会保存到 Binlog里。

Row:基于行级别,记录每一行数据的变化,也就是将每行数据的变化都记录到 Binlog 里面, 记录得很是详细, 可是并不记录原始 SQL; 在复制的时候, 并不会由于存储过程或触发器形成主从库数据不一致的问通, 可是记录的日志量较 Statement格式要大得多 。

Mixed:混合Statement和Row模式,默认状况下采用 Statement模式记录,某些状况下会切换到 Row模式

同时也对应了 MysQL复制的3种技术。

在 binlog_format设置为 Row格式时, MySQL实际上在 Binlog中逐行记录数据的变动, Row格式比 Statement格式更能保证从库数据的一致性(复制的是记录,而不是单纯操做 SQL)。固然, Row格式下的 Binlog的日志量极可能会增大很是多,在设置时须要考虑到磁盘空间间题。

参数 binlog_format能够在全局设置或者在当前 session动态设置: 在全局设置会影响全部session,而在当前 session设置则仅仅影响当前 Session。能够经过 SET命令来实时修改二进日志文件(Binlog)的格式。

相关命令

查看当前复制方式

show variables like '%binlog%format%';

更改复制方式

#set global binlog_format = 'ROW';

SET SESSION binlog_format = 'ROW';

#set global binlog_format = 'STATEMENT';

SET SESSION binlog_format = 'STATEMENT';

 

在 MySQL5.5以前, MySQL的复制是异步操做,主库和从库的数据之间存在必定的延迟,这样存在一个隐患:当在主库上写人一个事务并提交成功,而从库还没有获得主库推送的 Binlog日志时,主库宕机了,例如主库可能因磁盘损坏、内存故障等形成主库上该事务 Binlog丢失,此时从库就可能损失这个事务,从而形成主从不一致。

而半同步复制，是等待其中一个从库也接收到Binlog事务并成功写入Relay Log以后，才返回Commit操做成功给客户端；如此半同步就保证了事务成功提交后至少有两份日志记录，一份在主库Binlog上，另外一份在从库的Relay Log上，从而进一步保证数据完整性；半同步复制很大程度取决于主从网络RTT（往返时延），以插件 semisync_master/semisync_slave 形式存在。