mysql的ace上市公司_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

业务层幻读

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

业务层幻读