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）--表示日志是完整的，commit阶段完成

Xid同一个binlog是顺序增长的

redo->Xid

-- 写完binlog后，binlog会持久化到磁盘，在此阶段，如果server crash，重启mysqld时候，他会扫描redo中处于prepare状态xid，同时扫描last binary log，看看xid有没有在binlog里面，如果在，则commit，如果没有则rollback

业务层幻读

https://cloud.tencent.com/developer/news/299922

https://win-man.github.io/2018/08/10/MySQL%E5%A2%9E%E5%BC%BA%EF%BC%88Loss-less%EF%BC%89%E5%8D%8A%E5%90%8C%E6%AD%A5%E5%A4%8D%E5%88%B6/#Dump%E7%BA%BF%E7%A8%8B%E7%9A%84%E4%BC%98%E5%8C%96

引擎层已经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

业务层幻读