0、為什麼需要主從複製

• 在業務複雜的系統中，有這麼一個情景，有一句SQL語句需要鎖表，導致暫時不能使用讀的服務，那麼就很影響運作中的業務，使用主從複製，讓主庫負責寫，從庫負責讀，這樣即使主庫出現了鎖表的情景，通過讀從庫也可以保證業務的正常執行。
• 做資料的熱備
• 架構的擴充套件。業務量越來越大，I/O訪問頻率過高，單機無法滿足，此時做多庫的儲存，降低磁碟I/O訪問的頻率，提高單個機器的I/O效能

1、什麼是MySQL的主從複製？

• MySQL主從複製是指資料可以從一個MySQL資料庫伺服器主節點複製到一個或多個從節點。MySQL預設採用非同步複製方式，這樣從節點不用一直訪問主伺服器來更新自己的資料，資料的更新可以在遠端連線上進行，從節點可以複製主資料庫中的所有資料庫或者特定的資料庫，或者特定的表

2、MySQL複製原理

• 原理：
• master伺服器將資料的改變記錄二進位制binlog日誌，當master上的資料發生改變時，則將其改變寫入二進位制日誌中
• slave伺服器會在一定時間間隔內對master二 進位制日誌進行探測其是否發生改變，如果發生改變，則開始一個I/OThread請求master二進位制事件
• 同時主節點為每個I/O執行緒啟動一個dump執行緒，用於向其傳送二進位制事件，並儲存至從節點本地的中繼日誌中，從節點將啟動SQL執行緒從中繼日誌中讀取二進位制日誌，在本地重放，使得其資料和主節點的保持一致，最後I/OThread和SQLThread將進入睡眠狀態，等待下一次被喚醒
• 也就是說：
• 從庫會生成兩個執行緒，一個I/O執行緒，一個沒有MySQL執行緒
• I/O執行緒會去請求主庫的binlog，並將得到的binlog寫到本地的relay-log(中繼日誌)檔案中
• 主庫會生成一個log dump執行緒，用來給從庫I/O執行緒傳binlog
• 從庫的SQL執行緒會讀取relay log檔案中的日誌，並解析成SQL語句主義執行
• 如圖：

• 注意：
• master將操作語句記錄到binlog在日誌中，然後授予slave遠端連線的許可權(master一定要開啟binlog二進位制日誌功能；通常為了資料安全考慮，slave也開啟binlog功能)
• slave開啟兩個執行緒：I/O執行緒和mysql執行緒。其中I/O執行緒負責讀取master的binlog內容到中級日誌(relay log)裡；SQL執行緒負責將relay log日誌裡讀出binlog內容，並更新到slave的資料庫裡，這樣就能保證slave資料和master資料保持一致了
• MySQL複製至少需要兩個mysql的服務，當然MySQL服務也可以分佈在不同的伺服器上，也可以在一臺伺服器上啟動多個服務
• MySQL複製最好確保master和slave伺服器上的MySQL版本相同(如果不能滿足版本一致，那麼要保證master主節點的版本低於slave從節點的版本)
• master和slave兩節點間的時間需同步
• 具體步驟：
• 從庫通過手工執行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 events，並存放到本地的relay-log中，傳送過來的資訊，會記錄到master.info中
• 從庫SQL執行緒應用relay-log，並且把應用過的記錄到relay-log.info中，預設情況下，已經應用過的relay會自動被清理purge

3、MySQL主從形式

• 一主一從

• 主主複製

• 一主多從

• 多主一從

• 聯級複製

4、MySQL主從同步延時分析

• MySQL的主從複製都是單執行緒的操作，主庫對所有DDL和DML產生的日誌寫進binlog，由於binlog是順序寫，所以效率很高；slave的sql thread執行緒將主庫的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是隨機的，不是順序，所以成本要高很多，另一方面，由於sql thread也是單執行緒的，當主庫的併發較高時，產生的DML數量超過slave的SQL thread所能處理的速度，或者當slave中有大型query語句產生了鎖等待，那麼延遲就產生了。
• 解決方法：
• 業務的持久化層的實現採用分庫架構，MySQL服務可平行擴充套件，分散壓力
• 單個庫讀寫分離，一主多從，主寫從讀，分散壓力。這樣從庫壓力比主庫高，保護主庫
• 服務的基礎架構在業務和mysql之間加入memcache或者redis的cache層。降低MySQL的讀壓力
• 不同業務的MySQL物理上存放不同機器，分散壓力
• 使用比主庫更好的硬體裝置作為slave，MySQL壓力小，延遲自然會變小
• 使用更加強勁的硬體裝置

5、MySQL主從複製安裝配置

• 基礎設定準備

# 作業系統
centos7
# mysql版本
5.7
# 兩臺伺服器
node1:47.94.132.145(主)
node2:39.100.120.203(從)

• 安裝MySQL資料庫
• centos安裝mysql

1、安裝wget命令
    yum install wget -y

2、給Centos新增rpm源，並且選擇較新的源
    wget dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm

3、安裝下載好的rpm檔案
    yum install -y mysql-community-release-el7-5.noarch.rpm

4、安裝成功之後，會在/etc/yum.repos.d/資料夾下增加兩個檔案
    mysql-community-source.repo
    mysql-community.repo

5、vi mysql-community.repo
    [mysql56-community]
    enabled=0

    [mysql57-community-dmr]
    enabled=1

6、使用yum安裝mysql
    yum install mysql-community-server -y

    如果報錯，報錯詳情：Error:Unable to find a match: mysql-community-server
    解決方案：先禁用本地的 MySQL 模組在安裝即可 
        yum module disable mysql -y    //禁用
        再執行 yum install mysql-community-server -y

7、啟動mysql服務並設定開機啟動
    # 啟動mysql伺服器
    service mysqld start
    # 設定mysql開機啟動
    chkconfig mysqld on

    如果報錯，報錯詳情為：service: command not found
    解決方案：
        yum list | grep initscripts # 會出現initscripts.x86_64
        yum install initscripts -y


8、獲取mysql的臨時密碼
    grep "password" /var/log/mysqld.log

9、使用臨時密碼登入
    mysql -uroot -p

10、修改密碼
    set global validate_password_polict=0;
    set global validate_password_length=1;
    ALTER USER 'root'@'localhost' IDENTIFIED BY '123456';

13、修改遠端訪問許可權
    grant all privileges on *.* to 'root'@'%' identifyed by '123456' with grant option;
    flush privileges;

• docker安裝mysql

1、首先拉取docker映象,我們這裡使用5.7版本的mysql
    docker pull mysql:5.7

2、啟動主從資料庫伺服器
    docker run -p 3339:3306 --name node1 -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7 # 主節點
    docker run -p 3339:3306 --name node2 -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7 # 從節點

3、進入到主節點伺服器下
    cd /etc/mysql切換到/etc/mysql目錄下; 然後vi my.cnf對my.cnf進行編輯。此時會報出bash: vi: command not found，需要我們在docker容器內部自行安裝vim。使用apt-get install vim命令安裝vim, 會報錯，錯誤詳情為Unable to locate package vim
    執行apt-get update，然後再次執行apt-get install vim即可成功安裝vim

• 在兩臺資料庫中分別建立資料庫

# 注意：兩臺必須全部執行
create database msb;

• 在主(node1)伺服器進行如下配置：

# 修改配置檔案，執行以下命令開啟mysql配置檔案
vi /etc/my.cnf
# 在mysqld模組下新增如下配置資訊
log-bin=master-bin # 二進位制檔名稱
binlog-format=ROW # 二進位制日誌格式，有row、statement、mixed三種格式;row指的是把改變的內容複製過去，而不是把命令在從伺服器上執行一遍;statement指的是在主伺服器上執行的SQL語句，在從伺服器上執行同樣的語句。MySQL預設採用基於語句的複製,效率比較高。mixed指的是預設採用基於語句的複製，一旦發現基於語句的無法精確的複製時，就會採用基於行的複製。
server-id=1 # 要求各個伺服器的id必須不一致
binlog-do-db=msb # 同步的資料庫名稱

# 重啟mysql[centos]
service mysqld restart
# 重啟mysql[docker]
service mysql restart

• 配置從伺服器登入主伺服器的賬號授權

# 調整MySQL密碼驗證規則, 避免密碼過於簡單，不符合MySQL密碼規範
set global validate_password_policy=0;
set global validate_password_length=1;
# 授權操作
grant replication slave on *.* to 'root'@'%' identified by '123456';
# 重新整理許可權
flush privileges;

• 從伺服器的配置

# 修改配置檔案，執行以下命令開啟mysql配置檔案
vi /etc/my.cnf

# 在mysqld模組中新增如下配置資訊
log-bin=master-bin # 二進位制檔名稱
binlog-format=ROW # 二進位制日誌格式，有row、statement、mixed三種格式;row指的是把改變的內容複製過去，而不是把命令在從伺服器上執行一遍;statement指的是在主伺服器上執行的SQL語句，在從伺服器上執行同樣的語句。MySQL預設採用基於語句的複製,效率比較高。mixed指的是預設採用基於語句的複製，一旦發現基於語句的無法精確的複製時，就會採用基於行的複製。
server-id=2 # 要求各個伺服器的id必須不一致

• 重啟從伺服器並進行相關配置

# 重啟mysql[centos]
service mysqld restart
# 重啟mysql[docker]
service mysql restart

# 連線主伺服器
change master to master_host='47.94.132.145', master_user='root', master_password='root', master_port=8091, master_log_file='master-bin.000001', master_log_pos=310;

# 用於檢視主從同步狀態
show slave status\G

• 連線主伺服器語句解釋：
• master_host: Master 的IP地址
• master_user: 在 Master 中授權的用於資料同步的使用者
• master_password: 同步資料的使用者的密碼
• master_port: Master 的資料庫的埠號
• master_log_file: 指定 Slave 從哪個日誌檔案開始複製資料，即上文中提到的 File 欄位的值
• master_log_pos: 從哪個 Position 開始讀，即上文中提到的 Position 欄位的值
• master_connect_retry: 當重新建立主從連線時，如果連線失敗，重試的時間間隔，單位是秒，預設是60秒。
• 正常情況下，SlaveIORunning 和 SlaveSQLRunning 都是No，因為我們還沒有開啟主從複製過程。
• 開啟主從複製過程：

start slave # 開啟主從複製過程
# 再次查詢主從同步狀態
show slave status \G;
# SlaveIORunning 和 SlaveSQLRunning 都是Yes，說明主從複製已經開啟

• 主從複製排錯：
• 使用start slave開啟主從複製過程後，如果SlaveIORunning一直是Connecting，則說明主從複製一直處於連線狀態，這種情況一般是下面幾種原因造成的，我們可以根據Last_IO_Error提示進行排除：
• 網路不通(檢查ip、埠)
• 密碼不對(檢查是否建立用於同步的使用者和使用者密碼是否正確)
• pos不對(檢查Master的Position)

6、測試主從複製

# 主庫操作

# 建立表
create table user(id int, age int);
# 新增資料
insert into user values(1, 1);
# 檢視資料
select * from user;

# 從庫操作

# 查看錶
show tables;
# 檢視資料
select * from user;

# 在從庫插入資料，在主庫不會同步的

7、遇到問題

• 問題描述：
• ERROR 3021 (HY000): This operation cannot be performed with a running slave io thread
• 解決方案：

# 停止已經繫結的從庫
stop slave
# 重新連線主伺服器
change master to master_host='47.94.132.145', master_user='root', master_password='root', master_port=8091, master_log_file='master-bin.000001', master_log_pos=310;
# 然後重啟
start slave

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

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

• 落後太遠的原因：
• 硬體條件有關的，機器磁碟IO效能不足。主要還是網路問題，網路傳輸的效能。主庫存放二進位制日誌的儲存效能太低，建議binlog日誌存在SSD中。主庫dump執行緒太繁忙，主要發生在一主多從的環境下。從庫IO執行緒太忙。人為控制(delay節點、延時節點)
• 主庫update，從庫遲遲的沒有更新
• 特殊情況：日誌已經傳過來，資料並沒有同步
• 一般情況：
• 沒開啟SQL執行緒
• 傳的東西有問題(比如你要做的事情，已經提前做了，不想重複做了，然後他就死了)
• SQL執行緒忙
• 人為控制了[delay(從庫)節點、延時節點，一般生產設定為3-6小時之間，可以保證過去3-6小時之間的誤操作，可以避免]
• 主從複製延時配置(從庫配置)
• 操作步驟：
• 停止從庫複製

mysql>stop slave;

• 修改延時引數，master_delay，單位為s(秒)

mysql>CHANGE MASTER TO MASTER_DELAY = 30;

• 啟動從庫複製

mysql>start slave;

• 檢視配置是否生效

mysql> show slave status \G
……
SQL_Delay: 30

• 從庫安全配置(其他使用者只讀)
• 修改my.cnf配置檔案，新增只讀引數

read_only = 1 # 控制普通使用者
innodb_read_only = 1 # 控制root使用者，正常情況不要加

• 新增完成後重啟資料庫

# centos方式
service mysqld restart

# docker方式
service mysql restart

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)

• 主從複製故障及解決(跳過錯誤)
• 命令列設定：

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

• 在配置檔案修改，設定要跳過的pos

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

• 在mysql中可以跳過某些錯誤，但是最好的解決辦法，重新搭建主從複製
• 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 的值遠遠落後於主伺服器上的那些值，這表示主伺服器與從屬伺服器之間事件的網路傳輸可能存在延遲。
• 中繼日誌座標：
• 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 執行緒）中存在延遲。即，它表示複製日誌事件快於執行這些事件
• 單一主從需要改變的地方
• 從庫的作用：
• 相當於實時備份
• 使用從庫備份
• 一主多從應對讀多的業務需求
• 如果，從庫只做備份伺服器用，那麼主庫的壓力會不減反增。因為，所有的業務都在主庫實現，讀和寫、dump執行緒讀取並投遞binlog
• 解決方案：
• 可不可以挪走一部分讀業務到從庫，讀寫分離
• 一主多從應對讀多的業務需求，一旦發展成這個架構，dump執行緒投遞binlog的壓力更大
• 多級主從採用中間庫緩解主庫dump的壓力，會出現中間庫緩解主庫dump的壓力，會出現中間庫瓶頸的問題，選擇blackhole引擎，看效能與安全的權衡
• 難保證
• 雙主模型：緩解，資料一致性
• 環狀複製

8、同步主庫已有資料到從庫

• 如果在設定主從同步前，主伺服器上已有大量資料，可以使用mysqldump進行資料備份並還原到從伺服器以實現資料的複製：
• 主庫倉庫
• 停止主庫的資料更新操作

mysql>flush tables with read lock;

• 新開終端，生成主資料庫的備份(匯出資料庫)

mysqldump -uroot -ptest123 cmdb > cmdb.sql

• 將備份檔案傳到從庫

scp cmdb.sql [email protected]:/root/

• 主庫解鎖

mysql>unlock tables;

• 從庫操作：
• 停止從庫slave

mysql>slave stop;

• 新建資料庫cmdb

mysql> create database cmdb default charset utf8;

• 匯入資料

mysql -uroot -ptest123 cmdb<cmdb.sql 

• 此時主從庫的資料完全一致，如果對主庫進行增刪改操作，從庫會自動同步進行操作。

9、mysql正確清理binlog日誌的兩種方法

• MySQL中binlog日誌記錄了資料庫中資料的變動，便於對資料的基於時間點和基於位置的恢復，但是binlog也會日漸增大，佔用很大的磁碟空間，因此，要對binlog使用正確安全的方法清理掉一部分沒用的日誌
• 方法一：手動清理binlog
• 檢視主庫和從庫正在使用的binlog是哪個檔案

show master status \G
show slave status \G

• 在刪除binlog日誌之前，首先對binlog日誌備份，以防萬一
• 開始刪除binlog

purge master logs before'2016-09-01 17:20:00'; # 刪除指定日期以前的日誌索引中binlog日誌檔案
purge master logs to 'mysql-bin.000022'; # 刪除指定日誌檔案的日誌索引中binlog日誌檔案

• 注意：
• 時間和檔名一定不可以寫錯，尤其是時間中的年和檔名中的序號，以防不小心將正在使用的binlog刪除。切勿刪除正在使用的binlog。
• 方法二：通過設定binlog過期的時間，使系統自動刪除binlog檔案

mysql> show variables like 'expire_logs_days'; 
+------------------+-------+ 
| Variable_name  | Value | 
+------------------+-------+ 
| expire_logs_days |   0  | 
+------------------+-------+ 
mysql> set global expire_logs_days = 30;    # 設定binlog多少天過期

• 注意：過期時間設定的要適當，對主從複製，要看從庫的延遲決定過期時間，避免主庫binlog還未傳到從庫便因過期而刪除，導致主從不一致