作者：慘綠少年

出處：http://clsn.io

一、主從復制基礎概念

在了解主從復制之前必須要了解的就是數據庫的二進制日志(binlog),主從復制架構大多基于二進制日志進行。

1.1 二進制日志管理說明

二進制日志在哪？如何設置位置和命名？

在my.cnf文件中使用 log-bin = 指定；命名規則為 MySQL-bin.000000 （后為6位數字）

二進制日志位置：

mysql> show variables like '%log_bin%' ;
+---------------------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------------------+-----------------------------------------+
| log_bin | ON |
| log_bin_basename | /Application/mysql/data/mysql-bin |
| log_bin_index | /application/mysql/data/mysql-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+-----------------------------------------+
6 rows in set (0.06 sec)

日志命名：

mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 2979 |
| mysql-bin.000002 | 120 |
+------------------+-----------+
2 rows in set (0.00 sec)

二進制日志記錄什么？二進制日志中記錄的是一個個完成的事件

二進制日志格式是怎樣的？推薦使用row格式

查看當前使用的日志格式：

mysql> show variables like '%format%';
+--------------------------+-------------------+
| Variable_name | Value |
+--------------------------+-------------------+
| binlog_format | ROW |
| date_format | %Y-%m-%d |
| datetime_format | %Y-%m-%d %H:%i:%s |
| default_week_format | 0 |
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| time_format | %H:%i:%s |
+--------------------------+-------------------+
8 rows in set (0.00 sec)

二進制日志如何滾動？每次重啟都會刷新日志，也可以通過命令進行刷新 reset master;

二進制日志用來干嘛？備份恢復，起始點的備份恢復

二進制日志的操作命令？查看都有哪些二進制日志

mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 2979 |
| mysql-bin.000002 | 167 |
| mysql-bin.000003 | 120 |
+------------------+-----------+
3 rows in set (0.00 sec)

查看當前使用的二進制日志文件：

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 | 120 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

binlog相關詳情參照：

http://www.cnblogs.com/clsn/p/8087678.html#_label6

1.2 mysql傳統備份方式和缺陷

二進制日志備份
mysqldump
必須有數據庫服務器完成邏輯工作，需要更多地cpu周期
邏輯備份還原速度慢：需要MySQL加載和解釋語句、轉化存儲格式、重建引擎
xtrabackup
文件大
不總是可以跨平臺、操作系統和MySQL版本

1.3 MySQL主從復制能為我們做什么

高可用
輔助備份
分擔負載

二、MySQL主從復制介紹

2.1 復制技術

作用：

保證數據安全(異機實時備份)
保證服務持續運行（宕機接管）

主從復制實現基本原理

自帶功能，復制是 MySQL 的一項功能，允許服務器將更改從一個實例復制到另一個實例。
主服務器將所有數據和結構更改記錄到二進制日志中。
從屬服務器從主服務器請求該二進制日志并在本地應用其內容。即通過把主庫的binlog傳送到從庫，從新解析應用到從庫。

2.2 復制架構

mysql復制的應用常見場景：

應用場景1：從服務器作為主服務器的實時數據備份

應用場景2：主從服務器實現讀寫分離，從服務器實現負載均衡

應用場景3：把多個從服務器根據業務重要性進行拆分訪問

傳統的 MySQL復制提供了一種簡單的主–從復制方法，有一個主，以及一個或多個從。

主節點執行和提交事務，然后將它們（異步地）發送到從節點，以重新執行（在基于語句的復制中）或應用（在基于行的復制中）。

這是一個 shared-nothing 的系統，默認情況下所有 server 成員都有一個完整的數據副本。

（圖）MySQL 異步復制

還有一個半同步復制，它在協議中添加了一個同步步驟。

這意味著主節點在提交時需要等待從節點確認它已經接收到事務。只有這樣，主節點才能繼續提交操作。

（圖）MySQL 異步復制

在上面的兩個圖片中，可以看到傳統異步 MySQL 復制協議（以及半同步）的圖形展示。

藍色箭頭表示在不同 server 之間或者 server 與 client 應用之間的信息交互。

2.3 MySQL主從復制原理介紹

復制過程：

開啟binlog日志，通過把主庫的binlog傳送到從庫，從新解析應用到從庫。
復制需要3個線程（dump、io、sql）完成，5.6從庫多個sql。
復制是異步的過程。主從復制是異步的邏輯的SQL語句級的復制。

復制前提：

主服務期一定要打開二進制日志
必須兩臺服務器（或者是多個實例）
從服務器需要一次數據初始化
如果主從服務器都是新搭建的話，可以不做初始化
如果主服務器已經運行了很長時間，可以通過備份將主庫數據恢復到從庫
主庫必須要有對從庫復制請求的用戶。
從庫需要有relay-log設置，存放從主庫傳送過來的二進制日志：
show variables like '%relay%';
在第一次的時候，從庫需要change master to 去連接主庫。
change master信息需要存放到master.info中：
show variables like '%master_info%';
從庫怎么知道，主庫發生了新的變化?通過relay-log.info記錄的已經應用過的relay-log信息。
在復制過程中涉及到的線程
從庫會開啟一個IO thread(線程)，負責連接主庫，請求binlog，接收binlog并寫入relay-log。
從庫會開啟一個SQL thread(線程)，負責執行relay-log中的事件。
主庫會開啟一個dump thrad(線程)，負責響應從IO thread的請求。

主從怎么實現的？

通過二進制日志
至少兩臺（主、從）
主服務器的二進制日志“拿”到從服務器上再運行一遍。
通過網絡連接兩臺機器，一般都會出現延遲的狀態。也可以說是異步的。

2.4 執行原理--第一次開啟主從過程

從庫通過手工執行change master to 語句連接主庫，提供了連接的用戶一切條件：
（user、password、port、ip）
并且讓從庫知道，二進制日志的起點位置（file名 position號）
start slave
從庫的IO和主庫的dump線程建立連接
從庫根據change master to 語句提供的file名和position號，IO線程向主庫發起binlog的請求
主庫dump線程根據從庫的請求，將本地binlog以events的方式發給從庫IO線程
從庫IO線程接收binlog evnets，并存放到本地relay-log中，傳送過來的信息，會記錄到master.info中。
從庫SQL線程應用relay-log，并且把應用過的記錄到relay-log.info,默認情況下，已經應用過的relay會自動被清理purge。

到此為止，一次主從復制就完成

一旦主從運行起來：就不需要手工執行change master to，因為信息都會被存放到master.info（user、password、port、ip，上次獲取過的binlog信息file和position）中。

詳細的mysql replication 過程

三、主從搭建配置

本次主從搭建使用mysql多實例進行實驗。多實例配置參考文檔進行配置：

http://www.cnblogs.com/clsn/p/8038964.html#_label8

3.1 多實例數據庫slave配置

系統環境說明：

[root@db02 ~]# cat /etc/redhat-release
centos release 6.9 (Final)
[root@db02 ~]# uname -r
2.6.32-696.el6.x86_64
[root@db02 ~]# /etc/init.d/iptables status
iptables: Firewall is not running. # 注意：務必關閉防火墻（iptables selinux）
[root@db02 ~]# getenforce
Disabled
[root@db02 ~]# mysql --version
mysql Ver 14.14 Distrib 5.6.36, for Linux (x86_64) using EditLine wrapper

1、啟動多實例數據庫

[root@db02 ~]# /data/3306/mysql start
Starting MySQL...
[root@db02 ~]# /data/3307/mysql start
Starting MySQL...

2、配置文件說明：

master 配置文件說明：

[root@db02 ~]# cat /data/3306/my.cnf
[client]
port = 3306
socket = /data/3306/mysql.sock
[mysqld]
user = mysql
port = 3306
socket = /data/3306/mysql.sock
basedir = /application/mysql
datadir = /data/3306/data
log-bin = /data/3306/mysql-bin
server-id = 6 # server id 不能相同
skip_name_resolve = 0 # 跳過域名解析參數
[mysqld_safe]
log-error=/data/3306/mysql_3306.err
pid-file=/data/3306/mysqld.pid

slave 配置文件說明：

[root@db02 ~]# cat /data/3307/my.cnf
[client]
port = 3307
socket = /data/3307/mysql.sock
[mysqld]
user = mysql
port = 3307
socket = /data/3307/mysql.sock
basedir = /application/mysql
datadir = /data/3307/data
log-bin = /data/3307/mysql-bin
server-id = 7 # server id 不能相同
skip_name_resolve = 0 # 跳過域名解析參數
read_only = 1 # 從庫只讀 （非root用戶 ）
[mysqld_safe]
log-error=/data/3307/mysql_3307.err
pid-file=/data/3307/mysqld.pid

3、在主庫創建復制用戶

登陸到主數據庫中：

mysql -uroot -p123 -S /data/3306/mysql.sock

創建授權用戶，注意是slave用戶。

grant replication slave on *.* to repl@'10.0.0.%' identified by '123';

4、初始化從庫數據

備份主庫當前數據

mysqldump -uroot -p123 -A -B -F --master-data=2 -S /data/3306/mysql.sock >/tmp/full.sql

部分參數說明：

-F 刷新二進制日志
--master-data [=＃]這會導致二進制日志的位置和文件名被追加到輸出中。如果等于1，則將其打印為CHANGE MASTER命令; 如果等于2，那么該命令將以注釋符號為前綴。

到從庫進行恢復

mysql -uroot -p123 -S /data/3307/mysql.sock

恢復備份的數據

set sql_log_bin=0;
source /tmp/full.sql

5、開啟從庫復制

查看備份的當前使用的文件及POS號

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000012 | 120 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

登入數據庫，進行slave配置。

mysql -uroot -p123 -S /data/3307/mysql.sock
CHANGE MASTER TO
MASTER_HOST='10.0.0.52',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3306,
MASTER_LOG_FILE='mysql-bin.000012',
MASTER_LOG_POS=120;
start slave; # 啟動從庫復制

該配置想關說明可以通過 help 獲得。

mysql> help CHANGE MASTER TO
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;

3.2 測試主從同步

查看slave庫的狀態，主要查看：

Slave_IO_Running與Slave_SQL_Running是否都為Yes

主庫進行操作，在從庫驗證

[root@db02 ~]# mysql -uroot -p123 -S /data/3306/mysql.sock
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
4 rows in set (0.00 sec)
mysql> create database clsn;
Query OK, 1 row affected (0.00 sec)

在從庫上可以看到該數據庫已創建

[root@db02 ~]# mysql -uroot -p123 -S /data/3307/mysql.sock
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| clsn |
| mysql |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.00 sec)

至此mysql主從復制就搭建完成

3.3 忘記數據庫密碼？

shell> /application/mysql/bin/mysqld_safe --defaults-file=/data/3306/my.cnf --skip-grant-tables --skip-networking &
mysql> update user set password=password('123') where user='root' and host='localhost';
mysql> flush privileges;

3.4 主從復制狀態失敗的原因？

Last_IO_Error: error reconnecting to master 'repl@10.0.0.52:3306' - retry-time: 60 retries: 1

原因：

主機沒啟動，或者宕機，檢查主庫的狀態。
網絡通信問題，使用ping命令進行檢查；或使用mysql命令進行shell端登陸測試
防火墻，selinux（務必檢查）
復制用戶和密碼、端口號、地址有問題，使用mysql命令進行shell端登陸測試。
mysql自動解析，會將連接的IP解析成主機名（skip-name-resolve = 0）寫入my.cnf文件即可。
從庫IO異常關閉，通過show slave status G 進行查看。

四、MySQL主從復制常見問題

4.1 從庫binlog落后主庫binlog？

從庫記錄的已經主庫已經給我傳送的binlog事件的坐標，一般在繁忙的生產環境下會落后于主庫

show master statusG --- 主
show slave status G --- 從
Master_Log_File: mysql-bin.000007
Read_Master_Log_Pos: 729

落后太遠的原因：

硬件條件有關的，機器磁盤IO性能不足。
主要還是網絡問題，網絡傳輸的性能。
主庫存放二進制日志的存儲性能太低，建議binlog日志存咋SSD中。
主庫DUMP線程太繁忙，主要發生在一主多從的環境下。
從庫IO線程太忙
人為控制（delay節點、延時節點）

4.2 主庫update，從庫遲遲的沒有更新

特殊情況：日志已經傳過來了，數據并沒有同步

一般情況：

沒開啟SQL線程
傳的東西有問題（你要做的事情，我提前已經做了，不想重復做了，然后他就死了）
SQL線程忙
人為控制了【delay(從庫)節點、延時節點，一般生產設置為3-6小時之間，可以保證過去3-6小時之間的誤操作，可以避免】

4.3 主從復制延時配置(從庫配置)

停止從庫復制

mysql>stop slave;
Query OK, 0 rows affected (0.01 sec)

修改延時參數，MASTER_DELAY，單位位S （秒）。

mysql>CHANGE MASTER TO MASTER_DELAY = 30;
Query OK, 0 rows affected (0.07 sec)

啟動從庫復制

mysql>start slave;
Query OK, 0 rows affected (0.07 sec)

查看配置是否生效

mysql> show slave status G
……
 SQL_Delay: 30

4.4 從庫安全配置（其他用戶只讀）

修改my.cnf配置文件，添加只讀參數

read_only = 1 ====> 控制普通用戶
innodb_read_only = 1 ====> 控制root用戶，正常情況不要加

添加完成后重啟數據庫

mysql> show variables like '%read_only%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| innodb_read_only | OFF |
| read_only | ON |
| tx_read_only | OFF |
+------------------+-------+
3 rows in set (0.00 sec)

延時從庫: delay節點、延時節點

4.5 主從復制故障及解決（跳過錯誤）

命令行設置

stop slave; #<==臨時停止同步開關。
set global sql_slave_skip_counter = 1 ; #<==將同步指針向下移動一個，如果多次不同步，可以重復操作。
start slave;

在配置文件修改，設置要跳過的pos

/etc/my.cnf
slave-skip-errors = 1032,1062,1007

在mysql中可以跳過某些錯誤,但是最好的解決辦法，重新搭建主從復制。

4.6 延時節點概念 --> SQL線程延時？

Last_SQL_Errno: 0
Last_SQL_Error:

原因:

主庫做操作的對象，在從庫不存在
主庫做操作的對象屬性不一致
主庫做操作的對象，從庫已經存在

……

4.7 Slave_*_Running：？

Slave_IO_Running I/O 線程正在運行、未運行還是正在運行但尚未連接到主服務器。可能值分別為Yes、No 或 Connecting。
Slave_SQL_Running SQL線程當前正在運行、未運行,可能值分別為Yes、No
主服務器日志坐標：Master_Log_File 和 Read_Master_Log_Pos 標識主服務器二進制日志中 I/O 線程已經傳輸的最近事件的坐標。
如果Master_Log_File和Read_Master_Log_Pos 的值遠遠落后于主服務器上的那些值，這表示主服務器與從屬服務器之間事件的網絡傳輸可能存在延遲。

4.8 中繼日志坐標

Relay_Log_File 和 Relay_Log_Pos 列標識從屬服務器中繼日志中 SQL 線程已經執行的最近事件的坐標。

這些坐標對應于 Relay_Master_Log_File 和 Exec_Master_Log_Pos 列標識的主服務器二進制日志中的坐標。

如果 Relay_Master_Log_File 和 Exec_Master_Log_Pos 列的輸出遠遠落后于 Master_Log_File 和Read_Master_Log_Pos 列（表示 I/O 線程的坐標）

這表示 SQL 線程（而不是 I/O 線程）中存在延遲。即，它表示復制日志事件快于執行這些事件。

4.9 單一主從需要改變的地方

從庫的作用