这是最常见的主从同步架构
binlog
文件dump
请求binlog
至从库relay log
文件(与binlog
格式一样)relay log
并重新串行执行一遍,得到与主库相同的数据主库每提交一次事务,都会把数据变更,记录到一个二进制文件中,这个二进制文件就叫binlog
。需注意:只有写操作才会记录至binlog
,只读操作是不会的(如select
、show
语句)。
statement格式:binlog
记录的是实际执行的sql语句
row格式:binlog
记录的是变化前后的数据(涉及所有列),形如update table_a set col1=value1
, col2=value2 ... where col1=condition1 and col2=condition2 ...
mixed格式:默认选择
statement
格式,只在需要时改用row
格式
binlog
文件小,缺点是主库的慢sql也会在从库上再出现一次,一些依赖环境或上下文的函数可能会产生不一致的数据canal
建议使用row
级别commit
与主从同步流程无关,也不感知。mysql
版本支持,需要至少1个从库(默认1,具体数量可指定)对写入relay log
进行ack,主库才会commit
并把结果返回client
。commit
事务前会阻塞等待至少一个从库写入relay log
的ack
,直至超时高可用备份:半同步复制,可确保从库与主库的一致性,当主库发生故障时,切换到从库不会丢失数据。为了保证稳定性(不因半同步慢而拖累主库),一般不承担业务流量、尽可能快地ack
,只用于同步备份。
普通场景:线上从库异步同步,高可用备份半同步
对一致性要求较高的大数据取数需求
大数据取数可能导致从库cpu使用率飙升、ack变慢,可设置半同步所需ack数量为1,正常情况下高可用备份能很快ack
,于是主库会commit
并返回,而大数据取数复制慢一些也无所谓。这样就不会因为大数据取数ack
慢而影响主库和业务了。