MySQL DBA MySQL复制技术的变革(九)

复制环境搭建：基于ROW+GTID

statement格式复制不足及解决办法

GTID用于解决什么问题

半同步复制有什么缺点？加强半同步用于解决什么问题？半同步会不会有延迟？

复制的瓶颈点及改进建议

复制建议选择

 

 

statement格式复制不足

理解binlog

记录最小的单位是一个Event。前4个字节是magic number,接下来的19个字节记录Format desc event：FDE

一个事务由多个Event组成

（hexdump mysql-bin.00000x |head -n 3）

now()取到的是set timestamp的值

sysdate()取到的是系统的时间

show binlog events in 'mysql-bin.00000x'

 

row格式，binlog每条语句都带有库名

statement是加use

 

row格式优势

相对statement格式更加安全的复制格式

在某些状况下复制速度更快(sql复杂，表有主键）

系统的特殊函数也能够复制

更少的锁

 

缺点

binary log比较大（支持binlog_row_image）

单条语句更新【删除】表的行数过多，会造成大量的binlog

没法从binlog看见用户执行的sql（Event：binlog_row_query_log_events,记录用户的query)

 

uuid()结果太多离散，insert写入慢

 

 GTID用于解决什么问题

事务是由谁产生的，产生了多少事务，复制架构中求事务个数差集很是简单

gtid_purged  --表示已通过期的日志的位置

监控方便

 

半同步                                         

半同步复制有什么缺点？

加强半同步用于解决什么问题？

半同步会不会有延迟？

rpl_semi_sync_master_wait_point=after_commit

redo(xid)->binlog->redo commit（同时redo中写入binlog filename，pos）

Xid同一个binlog是顺序增加的

redo->Xid

业务层幻读

引擎层已经commit，可是dump线程还未dump binlog时master crash，那么主库的数据就会比从库多

 

 

 

 

加强半同步                                                                            

半同步复制有什么缺点？

rpl_semi_sync_master_wait_point=after_sync

若是在dump线程还未dump binlog时master crash，那么主库重启后的数据会比从库多

幽灵事务--掉电状况会发生

rpl_semi_sync_master_timeout

没有从库会hang住

https://bugs.mysql.com/bug.php?id=83158