Linux 第73天 mariadb主從複製

時間: 20181015

        個人小站: www.winthcloud.top 歡迎大家訪問留言        

目錄

MySQL複製作用

讀寫分離應用軟體

主從複製原理和步驟

MySQL垂直分割槽

MySQL水平分片（Sharding)

MySQL複製執行緒和檔案

主從複製特點

主從配置過程

複製架構中應該注意的問題

半同步複製以及實現步驟semi_sync

複製過濾器(複製黑白名單)

從變主的步驟

MySQL複製加密

複製的監控和維護

總結

MySQL複製

是一種用來實現將主伺服器的binlog日誌檔案同步傳送至指定的從伺服器上讓其在本地執行所

傳送過來的語句，這樣可以實現備份作用，並且還能做負載均衡。即從伺服器也接受使用者訪問

其資料庫，一般只讓其支援讀不支援寫

MySQL的擴充套件

讀寫分離

複製：每個節點都有相同的資料集

向外擴充套件

二進位制日誌

單向

複製的功用

資料分佈

負載均衡讀

備份

高可用和故障切換

MySQL升級測試

讀寫分離應用:

可以將前端所發來的sql請求按照規劃規則來發送至後端的mysql伺服器，即將寫請求傳送

至指定的伺服器，讀請求傳送至另外的伺服器

mysql-proxy：Oracle

https://downloads.mysql.com/archives/proxy/

Atlas：Qihoo

https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md

dbproxy：美團

https://github.com/Meituan-Dianping/DBProxy

Cetus：網易樂得

https://github.com/Lede-Inc/cetus

Amoeba：

https://sourceforge.net/projects/amoeba/

主從複製原理和步驟

1. 前端傳送過來的資料請求本地伺服器完成資料庫更新後寫入二進位制日誌binlog中

2. 主伺服器會開啟slave服務執行緒(數量多少取決於從伺服器的數量,如果太多會影響效率)

將二進位制日誌同步至從伺服器

3. 從伺服器有兩個執行緒io thread和sql Thread,io Thread用來接收主伺服器所傳送的

bin-log日誌並將其同步至relay log檔案中，sql thread來讀取relay log檔案並

將裡邊的sql語句執行由此便可以使本地的資料庫同步

MySQL垂直分割槽

即將一個庫裡的多張表分別放在多個數據庫中，用來緩解伺服器壓力，不過這些表格之間無法

使用JOIN

MySQL水平分片（Sharding）

即如果幾張表有JOIN則使用橫向的分片即將多個表格連線起來然後分成兩個庫，一個庫儲存

前半部分資料，另一個庫儲存後半部分資料 此兩種方式用來緩解資料庫讀寫操作太大的問題

一般的資料庫不需要，除非碰到超大型網站環境

MySQL複製執行緒和檔案

主從複製執行緒：

主節點：

dump Thread：為每個Slave的I/O Thread啟動一個dump執行緒，

用於向其傳送binary log events

從節點：

I/O Thread：向Master請求二進位制日誌事件，並保存於中繼日誌中

SQL Thread：從中繼日誌中讀取日誌事件，在本地完成重放

跟複製功能相關的檔案：

master.info：用於儲存slave連線至master時的相關資訊，

例如賬號、密碼、伺服器地址等

relay-log.info：儲存在當前slave節點上已經複製的當前二進位制

日誌和本地replay log日誌的對應關係

主從複製特點：

非同步複製

主從資料不一致比較常見

複製架構：

Master/Slave, Master/Master, 環狀複製

一主多從

從伺服器還可以再有從伺服器

一從多主:適用於多個不同資料庫

複製需要考慮二進位制日誌事件記錄格式

STATEMENT（5.0之前）

ROW（5.1之後，推薦）

MIXED

主從配置過程：參看官網

https://mariadb.com/kb/en/library/setting-up-replication/

https://dev.mysql.com/doc/refman/5.5/en/replication-configuration.html

主節點配置：

(1) 啟用二進位制日誌

[mysqld]

log_bin

(2) 為當前節點設定一個全域性惟一的ID號

[mysqld]

server_id=#

log-basename=master 可選項，設定datadir中日誌名稱，確保不依賴主機名

(3) 建立有複製許可權的使用者賬號

GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'HOST' 

IDENTIFIED BY 'replpass';

從節點配置：

(1) 啟動中繼日誌

[mysqld]

server_id=# 為當前節點設定一個全域性惟的ID號

relay_log=relay-log relay log的檔案路徑，預設值hostname-relay-bin

relay_log_index=relay-log.index 預設值hostname-relay-bin.index

(2) 使用有複製許可權的使用者賬號連線至主伺服器，並啟動複製執行緒

mysql> CHANGE MASTER TO MASTER_HOST='master-ip', 

MASTER_USER='repluser', 

MASTER_PASSWORD='replpass',

MASTER_LOG_FILE='mysql-bin.xxxxx', 

MASTER_LOG_POS=#;

mysql> START SLAVE [IO_THREAD|SQL_THREAD];

如果主節點已經運行了一段時間，且有大量資料時，如何配置並啟動slave節點

通過備份恢復資料至從伺服器複製起始位置為備份時，二進位制日誌檔案及其POS

如果要啟用級聯複製,需要在從伺服器啟用以下配置

[mysqld]

log_bin

log_slave_updates

複製架構中應該注意的問題：

1、限制從伺服器為只讀

在從伺服器上設定read_only=ON

注意：此限制對擁有SUPER許可權的使用者均無效

阻止所有使用者, 包括主伺服器複製的更新

mysql> FLUSH TABLES WITH READ LOCK;

2、RESET SLAVE

在從伺服器清除master.info ，relay-log.info, relay log

開始新的relay log ,注意：需要先STOP SLAVE

RESET SLAVE ALL 清除所有從伺服器上設定的主伺服器同步資訊如：

PORT, HOST, USER和 PASSWORD 等

3、sql_slave_skip_counter = N 從伺服器忽略幾個主伺服器的複製事件，global變數

4、如何保證主從複製的事務安全

參看https://mariadb.com/kb/en/library/server-system-variables/

在master節點啟用引數：

sync_binlog=1 每次寫後立即同步二進位制日誌到磁碟，效能差

如果用到的為InnoDB儲存引擎：

innodb_flush_log_at_trx_commit=1 每次事務提交立即同步日誌寫磁碟

innodb_support_xa=ON 預設值，分散式事務MariaDB10.3.0廢除

sync_master_info=# #次事件後master.info同步到磁碟

在slave節點啟用伺服器選項：

skip_slave_start=ON 不自動啟動slave

在slave節點啟用引數：

sync_relay_log=# #次寫後同步relay log到磁碟

sync_relay_log_info=# #次事務後同步relay-log.info到磁碟

半同步複製

預設情況下，MySQL的複製功能是非同步的，非同步複製可以提供最佳的效能，主庫把binlog

日誌傳送給從庫即結束，並不驗證從庫是否接收完畢。這意味著當主伺服器或從伺服器端發

生故障時，有可能從伺服器沒有接收到主伺服器傳送過來的binlog日誌，這就會造成主服

務器和從伺服器的資料不一致，甚至在恢復時造成資料的丟失

半同步複製實現: (！注意這裡的設定是臨時的，如果要成為永久的需要放置於配置檔案哦！)

主伺服器配置:

mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

mysql>SET GLOBAL rpl_semi_sync_master_enabled=1;

mysql>SET GLOBAL rpl_semi_sync_master_timeout = 1000;超時長為1s

mysql>SHOW GLOBAL VARIABLES LIKE '%semi%';

mysql>SHOW GLOBAL STATUS LIKE '%semi%';

從伺服器配置:(!注意從服務配置完成後需要重開啟關閉一下slave,永久儲存記得寫配置檔案)

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

mysql> SET GLOBAL rpl_semi_sync_slave_enabled=1;

mysql> STOP SLAVE;

mysql> START SLAVE;

複製過濾器(複製黑白名單)

讓從節點僅複製指定的資料庫，或指定資料庫的指定表

兩種實現方式：

(1) 伺服器選項：主伺服器僅向二進位制日誌中記錄與特定資料庫相關的事件

注意：此項和binlog_format相關

參看：mariadb.com/kb/en/library/mysqld-options/#-binlog-ignore-db

binlog_do_db = 資料庫白名單列表，多個數據庫需多行實現

binlog_ignore_db = 資料庫黑名單列表

問題：基於二進位制還原將無法實現；不建議使用

(2) 從伺服器SQL_THREAD在replay中繼日誌中的事件時，僅讀取與特定資料庫(特定表)

相關的事件並應用於本地

問題：會造成網路及磁碟IO浪費

從伺服器上的複製過濾器相關變數：(注意要放在配置檔案中，不然重啟服務失效)

replicate_do_db= 指定複製庫的白名單

replicate_ignore_db= 指定複製庫黑名單

replicate_do_table= 指定複製表的白名單

replicate_ignore_table= 指定複製表的黑名單

replicate_wild_do_table= foo%.bar% 支援萬用字元

replicate_wild_ignore_table=

從變主步驟

如果主伺服器裝置故障想要使一個從變為主所需要的步驟，如果從有多個要注意檢視哪個從

所同步的二進位制日誌最接近主，就使用哪個來變為主(Second_Behind_Master)

1.STOP SLAVE

2.開啟二進位制日誌，關閉read-only

3.如果主伺服器的二進位制日誌可以複製出來的話，將二進位制日誌複製到從伺服器上，並找到

想對應的位置在從伺服器上執行

4.重啟mariadb服務，最後將其它的從指向剛剛設定好的機器為主

MySQL複製加密

基於SSL複製：

在預設的主從複製過程或遠端連線到MySQL/MariaDB所有的連結通訊中的資料都是明文

的，外網裡訪問資料或者複製，存在安全隱患。通過SSL/TLS加密的方式進行復制的方法，

可以進一步提高資料的安全性

配置實現：

參看：mariadb.com/kb/en/library/replication-with-secure-connections/

主伺服器開啟SSL：[mysqld] 加一行ssl

主伺服器配置證書和私鑰；並且建立一個要求必須使用SSL連線的複製賬號

從伺服器使用CHANGER MASTER TO 命令時指明ssl相關選項

Master伺服器配置

[mysqld]

log-bin

server_id=1

ssl

ssl-ca=/etc/my.cnf.d/ssl/cacert.pem

ssl-cert=/etc/my.cnf.d/ssl/master.crt

ssl-key=/etc/my.cnf.d/ssl/master.key

新增一個授權賬戶

GRANT REPLICATION SLAVE ON *.* 

TO 'userssl'@'192.168.48.%' 

IDENTIFIED BY 'userssl' REQUIRE ssl;

Slave伺服器配置

mysql>

CHANGE MASTER TO

MASTER_HOST='MASTERIP',

MASTER_USER='rep',

MASTER_PASSWORD='centos',

MASTER_LOG_FILE='mariadb-bin.000001',

MASTER_LOG_POS=245,

MASTER_SSL=1,

MASTER_SSL_CA = '/etc/my.cnf.d/ssl/cacert.pem',

MASTER_SSL_CERT = '/etc/my.cnf.d/ssl/slave.crt',

MASTER_SSL_KEY = '/etc/my.cnf.d/ssl/slave.key';

複製的監控和維護

(1) 清理日誌

PURGE { BINARY | MASTER } LOGS {TO 'log_name' | BEFORE datetime_expr}

RESET MASTER

RESET SLAVE

(2) 複製監控

SHOW MASTER STATUS

SHOW BINLOG EVENTS

SHOW BINARY LOGS

SHOW SLAVE STATUS

SHOW PROCESSLIST

(3) 從伺服器是否落後於主服務

Seconds_Behind_Master: 0

(4) 如何確定主從節點資料是否一致

percona-tools

(5) 資料不一致如何修復

刪除從資料庫，重新複製

總結:

1. 主從複製建議開啟半同步複製，即客戶端請求寫資料時，主伺服器同步至任一臺從並有響應

可用來防止資料丟失

2. 雖然現在可以使用主從結構來分離讀寫，但是如果主節點出故障時，恢復還是需要人工參與

這樣也會導致在修復的時間中線上業務無法正常使用

3. 這便是下一章節，高可用可以解決的問題哈哈