复制环境搭建：基于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
引擎层已经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
业务层幻读
