Mysql主從復制搭建過程

154次閱讀

共計 3742 個字符，預計需要花費 10 分鐘才能閱讀完成。

這篇文章主要講解了“Mysql 主從復制搭建過程”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“Mysql 主從復制搭建過程”吧！

一、相關概念

mysql 主從復制的官方概念可自行百度，在這里談一下個人理解以及它和 DataGuard 的區別（理解有誤請指正）。
主庫通過 mysql 引擎將 master 庫中執行的所有 sql 語句轉儲到一個二進制 log 文件中（binlog），然后將這個 binlog 通過網絡傳輸到 slave 端，然后解析 binlog 中的語句成 sql 語句，再在備庫中執行，由此可見，mysql 的主從復制功能是基于 sql 語句邏輯的傳輸方法，所以在配置 mysql 主從復制的過程中，參數一定要優化得當，否則就會出現由于參數限制的問題出現各種各樣的報錯。。。
- 和 DataGuard 的比較
DataGuard（太懶，下面簡稱 DG）中文名稱叫做數據衛士，是 oracle 提供的一種容災解決方案。DG 一般稱主庫為 primary（對應 mysql 中的 master），備庫叫 standby（對應 mysql 中的 slave），它有三種模式，分別是物理 standby、邏輯 standby 和快照 standby，我們一般采用物理 standby 的配置方法，優點是配置簡單，不易出錯，對參數方面優化較少，是通過將歸檔日志通過網絡傳輸到備庫，再通過 block-to-block（塊對塊的復制）的方式在備庫端進行應用（注意：這里區別于 mysql 的是，并不涉及 sql 語句，采用數據塊復制的方法呈現的），優點是維護簡單，不涉及 sql 語句的邏輯，適用于絕大多數生產環境。（mysql 這方面和 DG 相比還是略遜一籌，好了廢話不多說，下面開始配置）

二、試驗環境（其實這是個真實的生產環境，已脫敏）

平臺：Hyper-V

OS:CentOS 6.5

DB: Mysql 5.6

三、開始搭建
前提條件

- 操作系統以及數據庫安裝完畢
- 版本一致
- 關閉 iptables、selinux

修改 master 配置文件

- 主庫
vi /etc/my.cnf

[mysqld]

log-bin=mysql-bin // 開啟 binlog 功能

server-id=1 //service-id 主從要區別開
- 從庫
vi /etc/my.cnf

[mysqld]

log-bin=mysql-bin // 開啟 binlog 功能

server-id=2 //service-id 主從要區別開

建立同步賬號并授權 slave

mysql GRANT REPLICATION SLAVE ON *.* to
mysync @ % identified by mysync

鎖定主庫

mysql flush tables with read lock;

確定 master 庫狀態值

mysql show master status;

+——————+———-+————–+——————+

+——————+———-+————–+——————+

| mysql-bin.000039 | 308 | | |

+——————+———-+————–+——————+

1 row in set (0.00 sec)

注：執行完此步驟后不要再操作主服務器 MYSQL，防止主服務器狀態值變化

配置從庫 slave

mysql change master to
master_host= xx.xx.xx.xx ,master_user= mysync ,master_password= mysync ,master_log_file= mysql-bin.000089 ,master_log_pos=592700228;
Mysql start slave; // 啟動從服務器復制功能

解鎖主庫

mysql unlock
tables;

檢查主從復制狀態

mysql show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.9.40.70
Master_User: mysync
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000089
Read_Master_Log_Pos: 182083231
Relay_Log_File: mysqld-relay-bin.000100
Relay_Log_Pos: 182083394
Relay_Master_Log_File: mysql-bin.000089
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
……………………………………………………
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)
注：標紅的 IO 和 SQL 狀態均為 yes，主從配置完成！

四、Troubleshooting

在實際環境過程中，可能會出現各種各樣的異常，在這里就不模擬異常了（實在無法模擬），主要討論處理方法。

一般主從出現異常之后通過 show slave status\G 可以看到是 IO 的問題還是 SQL 執行的問題，如果 IO 為 NO, 請檢查主從之間的網絡是否存在異常或者防火墻是否開啟。
如果是 SQL 選項為 NO，那就要具體問題具體分析了，在 Last_SQL_Error 中會提示哪個 sql 語句卡主，注意。。。這里的坑比較多，如果是參數問題導致卡 sql，那么優化指定參數文件之后重啟 mysql 服務應該就沒有問題了，如果從庫有寫入導致不一致的情況只能跳過錯誤了。曾經在某項目遇到過執行一個表的 update 一直被卡，無論怎么跳過也不行，參數也沒有問題，被坑了好久之后發現原來這個庫連著一個備用的應急環境，里面的 job 會每隔一段時間進行更新，由于環境不同導致初始值不同所以 update 必然失敗，但如果是 block-to-block 的復制方式就會屏蔽這個錯誤。解決方法：將這個庫的應用服務停掉就 ok 了。
- 處理主從報錯的通用方法：
start slave;

set global
sql_slave_skip_counter=1;
start slave;

下面給大家貼一下主從復制報錯然后自動發郵件提醒的腳本

#!/bin/bash

array=($(mysql -u root -pxxxx -e show slave status\G |grep Running |awk {print $2} ))
if [${array[0]} == Yes ] || [${array[1]} == Yes ]
then
echo slave is OK /var/lib/mysql/backup/script/sync_log.tmp
else
echo mysql 主從復制出錯 /var/lib/mysql/backup/script/sync_log.tmp
mailx -s mysql_sync_check tsl-baijin0829@tasly.com /var/lib/mysql/backup/script/sync_log.tmp
fi

感謝各位的閱讀，以上就是“Mysql 主從復制搭建過程”的內容了，經過本文的學習后，相信大家對 Mysql 主從復制搭建過程這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！

正文完