信息,获取主库信息连接主库
文件,获取到上次执行到的 relay-log 的位置,作为起点,回放 relay-log
信息,获取主库信息连接主库
文件,获取到上次执行到的 relay-log 的位置,作为起点,回放 relay-log
控制 binlog 从内存写入磁盘的控制开关
每次事务提交都立即刷新 binlog 到磁盘(双一标准中的其一)
每次事务提交不立即写入磁盘,靠操作系统判断什么时候写入
2 dump 线程多导致的,系统资源压力大,由于传送日志是串行的。
由于超大事务存在,由于是串行工作,会阻塞后续其他事务的传送。
事务量大(主库压力大)
从库 默认只有一个 SQL 线程,串行回放事务。在主库有并发事务量大,或者有超大事务时,都会导
致 SQL 延时较严重。
5.6 版本,加入了 GTID 特性,所以支持了并发 SQL 特性,基于不同库实现并行回放事务
5.7 版本,GTID 功能进行了升级,可以通过 Logical_clock 模式,实现事务级别的多 SQL 线程的回
放。我们把这种复制模式叫做 MTS。
每一条会修改数据的 sql 语句会记录到 binlog 中。优点是并不需要记录每一条 sql 语句和每一行的数
据变化,减少了 binlog 日志量,节约 IO,提高性能。缺点是在某些情况下会导致 master-slave 中的
不记录每条 sql 语句的上下文信息,仅需记录哪条数据被修改了,修改成什么样了。而且不会出现
某些特定情况下的存储过程、或 function、或 trigger 的调用和触发无法被正确复制的问题。缺点是
会产生大量的日志,尤其是 alter table 的时候会让日志暴涨。
无法复制的操作使用 ROW 模式保存 binlog,MySQL 会根据执行的 SQL 语句选择日志保存方式。
--databases, -B: 用于备份多个数据库,如果没有该选项,mysqldump 把第一个名字参数作为数据库
名,后面的作为表名。使用该选项,mysqldum 把每个名字都当作为数据库名。
-d: 只导出数据库的表结构
-t: 只导出数据库的数据
条数据被修改了,修改成了什么样子了。
binlog,MySQL 会根据执行的 SQL 语句选择日志保存方式。
双向的主从复制,也就是互为对方的从服务器,每台服务器即是对方的主服务器,又是对方的从服
1:主服务器凡运行语句,都产生一个二进制日志 binlog