前言

基于日志文件和位置的 传统复制，是根据binlog文件和master_log_position确定复制的。

传统复制的原理

在master上，线程：dump_thread ；日志：binlog。

在slave上，线程：IO_thread 和 SQL_thread；日志：relay log。

1、在主库master中，记录二进制日志

在事务准备提交前，主库将更新的事件记录到binlog中，然后事务提交。注意，在binlog文件记录的事务均是按照事务提交顺序来记录的。

2、从库将主库的binlog复制到自己的relay log中

从库中的IO_thread 与主库建立一个连接，在主库，每当有新事件时，dump_thread会读取该事件，并发送给IO_thread，IO_thread 将接收到的事件记录在从库的relay log中。

3、SQL_thread 执行复制过来的事件

从库中的SQL_thread会执行relay log中记录的事件，以此更新从库的数据。但是，SQL_thread是否会将执行的事件记录到本地的binlog中，由参数log_slave_updates控制。

传统复制的搭建

机器环境：

• 以 一主一从为例。
• Master IP: 172.16.100.100
• Slave IP: 172.16.100.101 
• 两机器均已安装MySQL。

配置步骤：

# 主库（master）

• 在 my.cnf 中添加 or 修改：
  • server-id=1003306      #  IP最后一个字段+端口号
  • log-bin=/data/mysql/mysql3306/mysql-bin
  • binlog_format = row
• 在mysql中创建复制使用的账户：
  • mysql> create user 'repl'@'172.16.100.101' identified by '123123';
  • mysql> grant replication slave on *.* to 'repl'@'172.16.100.101' ;  
  • mysql> show master status\G

# 从库（slave）

• 在 my.cnf 中添加 or 修改：
  • server-id=1013306       #  IP最后一个字段+端口号
  • log-bin=/data/mysql/mysql3306/mysql-bin
  • binlog_format = row
  • log_slave_updates        # 使从库产生binlog，若不配置，即使开启log-bin参数，也不会产生binlog，若不需要binlog，则不用配置该参数
• 使 从库 指向 从库（保证该操作之前复制线程已停止！）
  • mysql>change master to master_host='172.16.100.100',master_user='repl',master_password='123123',master_log_file='mysql-bin.000001',master_log_pos=330;

# 开启和关闭复制（在从库操作）

• start slave;       # 开启复制
• show slave status\G              # 查看复制情况

解读 show slave status 的主要字段

• Master_Log_File：IO thread 当前在读的主库binlog文件
• Read_Master_Log_Pos：IO thread 已读到的主库binlog的位置
• Relay_Log_File：SQL thread 正在读取的relay log文件
• Relay_Log_Pos：SQL thread 已读取的relay log中的位置
• Relay_Master_Log_File：SQL thread最近执行的事件 所在主库的binlog文件
• Slave_IO_Running：IO thread 是否在运行（必须为Yes，否则有问题）
• Slave_SQL_Running：SQL thread 是否在运行（必须为Yes，否则有问题）
• Replicate_Do(Ignore)_DB：在复制时，复制或忽略复制的库
• Last_Errno/Last_Error：错误码/错误说明；通常主从报错时在这里显示错误的原因
• Exec_Master_Log_Pos：705904595     # SQL thread已执行事件的主库binlog的位置，也标志 将要处理下一个事件或事务的开始；通常这个位置在主库对应binlog文件中是这样的：

……  #170713 15:52:16 server id 1003306  end_log_pos 705904595 CRC32 0xaee2b643    Xid = 5191672348 COMMIT/*!*/; # at 705904595 #170713 16:02:10 server id 1003306  end_log_pos 705904674 CRC32 0x97e59f40    Query   thread_id=1442126       exec_time=0     error_code=0 SET TIMESTAMP=1499932930/*!*/; BEGIN      /*!*/;  ……

• Seconds_Behind_Master：从库正在处理事件时，此时从库的时间戳 与 正被处理的事件在主库上记录的时间戳的差值（单位为秒）。实际上，该值测量的是SQL 线程和IO线程之差，在主从的网络很好的情况下，从库的IO线程和主库很接近，SQL线程和IO线程之差 也就近似 SQL线程和主库之差（即是第一句的意思），因此，只有在网络很好的情况下，这个值才有参考性；而在网络不好的情况下，即使值为0，也不能说明没有延迟。
• Last_IO_Error/Last_SQL_Error：IO thread出错的原因 / SQL thread出错的原因
• SQL_Delay：从库必须滞后主库的秒数；因为有时会特意设置一个延迟的从库，用作误操作恢复
• Retrieved_Gtid_Set：IO线程从主库所复制事务对应的GITD集合；但若没有开启GTID，则为空
• Executed_Gtid_Set：在从库中已写入binlog的GTID集合，也是 在从库show master status的Executed_Gtid_Set值；但若没有开启GTID，则为空