前言
基於日誌文件和位置的 傳統複製，是根據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，則爲空