高性能MySQL-筆記6-關於MySQL複製的東東

文章目錄
高性能MySQL-筆記6-關於MySQL複製的東東
@[toc]
簡單說明
複製原理
具體的配置
主庫配置
備庫的配置
其他的Binlog配置
啓動主備複製
業務情景下的主備複製
主備的拓撲結構
基本的原則
常見的各種拓撲結構
一主庫多備庫
雙主複製
奇奇怪怪的結構
一些重要的問題[重點]
InnoDB加鎖讀引起的鎖徵用
關於半同步複製
關於多線程複製-組複製
其他的複製技術
最總要的工具

簡單說明

MySQL的複製，主要的用途：數據分佈，負載均衡，備份，高性能可用與故障切換。

關於複製：可以基於行復制和基於語句複製。【語句複製有操作語句限制的】

方式：都是通過主庫上記錄二進制日誌，然後在備庫重放日誌的方式來完成的。【不保證同一時間主備數據一致】

複製原理

三個步驟：

主庫上吧數據的更改記錄到二進制日誌（BinLog）中，；【關於BinLog等的配置，後續細說】
備庫把主庫的日誌，複製到自己的中繼日誌（Relay Log）中.
備庫讀取中繼日誌的時間，重放到備庫的數據上。【相當於重做一遍的意思】

注意一下，由於主庫BinLog到備庫RelayLog中，屬於串行化的了。備庫的重做也就只能單線程處理了╮(╯_╰)╭

然而，新的版本已經有了多線程複製的了這書呀的版本太舊了

具體的配置

配置均爲調整my.cnf 配置文件！

查看狀態：show master status;和show slave status ；

主庫配置

log_bin=mysql-bin
server_id=10    # 這個爲必填配置，唯一的服務ID

主庫可以創建備份使用的獨立賬戶：

GRANT REPLICATION SLAVE,RELOAD,SUPER ON *.* TO backup@’192.168.1.102’ IDENTIFIED BY ‘123456’;
FLUSH PRIVILEGES;  生效創建的用戶
建立一個帳戶backup，並且只能允許從192.168.1.102這個地址上來登陸，密碼是123456。

備庫的配置

log_bin=mysql-bin
server_id=2    # 這個爲必填配置，唯一的服務ID
relay_log=/var/lib/mysql/mysql-relay-bin    # 非必配置
log_slave_updates=1  # 表示是否將重放事件記錄到自身的二進制日誌中
read_only=1 # 配置爲只讀

其他的Binlog配置

# 以下爲配置介紹，非最優配置！！！  查看狀態：show variables like 'log_%'; 
#設置日誌格式 MIXED：混合模式；STATEMENT：邏輯模式【默認】；ROW：行模式【建議使用】；
binlog_format = mixed
#設置日誌路徑，注意路經需要mysql用戶有權限寫
log-bin = /data/mysql/logs/mysql-bin.log
#設置binlog清理時間
expire_logs_days = 7
#binlog每個日誌文件大小
max_binlog_size = 100m
#binlog緩存大小
binlog_cache_size = 4m
#最大binlog緩存大小
max_binlog_cache_size = 512m

啓動主備複製

mysql> CHANGE MASTER TO MASTER_HOST='mastrt服務器地址',
    -> MASTER_USER='master服務器用戶，使用剛纔創建的backup',
    -> MASTER_PASSWORD='密碼',
    -> MASTER_LOG_FILE='master的show master status的file，實際填寫mysql-bin.000009',
	-> MASTER_LOG_POS=0;   master的show master status的Position

使用 SHOW SLAVE STATUS\G語句查看slave的設置是否正確

mysql> START SLAVE;

可以使用 SHOW PROCESSLIST 來查看主備庫的線程。

至此，簡單的主備複製就可了，主備都是新數據庫的情況。應該就醬紫了 o(￣︶￣)o

業務情景下的主備複製

業務場景下，在進行創建備庫的時候，主庫不可能是已經新的數據庫，而是已經有大量的數據的了。這個情況下再進行，備庫的搭建，是爲最常見項目場景的了。

需要的三個關鍵信息：

某一個時間點的主庫的數據快照。
主庫當前的二進制日誌文件，以及獲得數據快照時在該二進制日誌文件中的偏移量。【使用 show master status 進行獲取】
從快照時間到當前現在的二進制日誌。

可行的方法：

使用冷備份：需要停機複製主庫，不推薦。
使用mysqldump轉儲主庫的數據並加載到備庫。【僅支持InnoDB】
使用快照或備份進行創建。【推薦】
使用Percona Xtrabackup 工具進行熱備份。推薦】

具體的方法，並不在同一章節，在之後的專門的備份恢復章節。

主備的拓撲結構

一些情況下，數據庫的拓撲結構不僅僅只是兩臺的主備數據庫，而是一主多備，雙主，環形樹形複製等。

基本的原則

一個MySQL備庫實例只能有一個主庫。【MySQL 不支持多主庫的複製】
備庫必須有唯一的服務器ID
一個主庫可以有多個備庫。
如果打開了備庫的log_slave_updates選項，備庫可以作爲主庫再傳播數據到其他備庫。

常見的各種拓撲結構

一主庫多備庫

主要用於少量寫大量讀的情景，遠程備份防災。

雙主複製

雙主複製中，雙主動複製的情況，會出現很多的問題，因爲兩個庫存在同時寫入相同行數據的情況，會造成數據衝突等等。

而，一主動一被動的雙主複製，設置被動主庫爲只讀的情況。用於在故障的時候方便切換數據庫。

奇奇怪怪的結構

作用的話：

作爲數據歸檔
備庫作爲全文檢索進行查詢
作爲只讀備庫，分流查詢壓力
作爲數據分析使用
差不多就這些理由了 ╮(╯_╰)╭

一些重要的問題[重點]

這一些纔是重要的東西，書裏面研究的版本已經比較舊了【最多到5.5】。對於新的一些特性與優化，需要去查一下了。【目前使用的版本是5.7的，雖然官方有8的版本了。】

ε=(´ο｀*)))唉感覺越學，要學習的東西就變得更多了。╮(╯_╰)╭ 。。。

InnoDB加鎖讀引起的鎖徵用

正常InnoDB的讀操作都是非阻塞的，但是在 insert。。。select。。。這個操作的時候會鎖定源表上的所有行。

以避免操作在主備庫上的不一致╮(╯_╰)╭ ？？加鎖，使主庫的語句串行化，以保證主備執行一致。

select 的表示InnoDB類型的情況，會對select的表的記錄進行鎖定。

可以使用遊標循環插入避免此鎖定問題

關於半同步複製

從MySQL5.5開始，MySQL以插件的形式支持半同步複製。【495】

異步複製（Asynchronous replication）【默認】
- MySQL默認的複製即是異步的，主庫在執行完客戶端提交的事務後會立即將結果返給給客戶端，並不關心從庫是否已經接收並處理，這樣就會有一個問題，主如果crash掉了，此時主上已經提交的事務可能並沒有傳到從上，如果此時，強行將從提升爲主，可能導致新主上的數據不完整。
全同步複製（Fully synchronous replication）
- 指當主庫執行完一個事務，所有的從庫都執行了該事務才返回給客戶端。因爲需要等待所有從庫執行完該事務才能返回，所以全同步複製的性能必然會收到嚴重的影響。
半同步複製（Semisynchronous replication）
- 介於異步複製和全同步複製之間，主庫在執行完客戶端提交的事務後不是立刻返回給客戶端，而是等待至少一個從庫接收到並寫到relay log中才返回給客戶端。相對於異步複製，半同步複製提高了數據的安全性，同時它也造成了一定程度的延遲，這個延遲最少是一個TCP/IP往返的時間。所以，半同步複製最好在低延時的網絡中使用。

關於半同步複製存在的數據丟失的潛在問題，MySQL 5.7引入了一種新的半同步方案：Loss-Less半同步複製。

MySQL 5.7.2引入了一個新的參數進行控制-rpl_semi_sync_master_wait_point

AFTER_SYNC：這個即新的半同步方案，Waiting Slave dump在Storage Commit之前。

AFTER_COMMIT：老的半同步方案

要想使用半同步複製，必須滿足以下幾個條件：

MySQL 5.5及以上版本
變量have_dynamic_loading爲YES ：show variables like '%have_dynamic_loading%'
異步複製已經存在

然後使用半同步，是以組件的形式支持的。

組件名：rpl_semi_sync_master

查看方式：【默認是沒有這個組件的】

mysql> show plugins;

mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE ‘%semi%’;

具體的操作，請在需要使用的時候查看官方組件的文檔，或其他的教學文檔。這裏略過了。

可以查看的參考文章：
https://www.cnblogs.com/ivictor/p/5735580.html
https://www.actionsky.com/2486.html

官方半同步複製組件文檔：
https://dev.mysql.com/doc/refman/5.7/en/replication-semisync-installation.html

關於多線程複製-組複製

支持的話，在MySQL5.6的版本之後就支持了，5.7.2 進行了優化，增加了參數slave_parallel_type；

對於多線程複製的一些說明：

MySQL5.5 及以前的複製：

一般主從複製有三個線程且都是單線程：
Binlog Dump（主） ‐‐> IO Thread（從） ‐‐> SQL Thread（從）。

而master 這邊是通過併發線程提交，事務通過LSN 寫入binlog；但是Slave 只有一個IO 線程和SQL 線程，是單線程，所以在業務大的情況下就很容易造成主從延時.

如果在MySQL 5.6 版本開啓並行複製功能（slave_parallel_workers > 0），那麼SQL 線程就變爲了coordinator 線程，coordinator 線程主要負責以下兩部分內容：

Coordinator+worker（多個）

問題在與這個時的併發是基於庫的，但是通常情況用戶止只有一個庫，就無法進行併發了。

5.7.2版本之後的：slave_parallel_type，參數給處理優化：

slave‐parallel‐type，其可以配置的值有：

DATABASE：默認值，基於庫的並行複製方式

LOGICAL_CLOCK：基於組提交的並行複製方式【需要的就是這個】

以上是大概的說明了。

關於多線程複製的具體點的配置操作：

這裏只是整理了一些資料而已，沒有實際操作過**。如需要進行配置，請認真查看官方說明。**

首先，主庫上，好像不需要什麼操作的樣子。

然後，從庫上的操作：【查看線程show processlist;】

停止同步狀態：stop slave;
設置併發同步類型爲邏輯時鐘方式:
1. show variables like ‘slave_parallel_type’;
2. set global slave_parallel_type=‘logical_clock’;
設置複製線程的數量:
1. show variables like ‘slave_parallel_workers’;
2. set global slave_parallel_workers=4;
還需要調整的配置:
1. 設置 master_info_repository=TABLE 和 relay_log_info_repository=TABLE。
2. slave_preserve_commit_order=1
3. 具體要求查看官方文檔：https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements.html
啓動複製 :start slave;

參看文章：

https://www.jianshu.com/p/d97a5643d090
https://blog.51cto.com/11899934/1832201
mysql主從之多線程複製【有完整推薦的配置文件信息，很詳細的】

官方配置：https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html
官方要求文檔：<https://dev.mysql.com/doc/refman/5.7/en/group-replication-requirements.html

其他的複製技術

Percona XtraDB Cluster 的同步複製
Continuent 的 Tungsten Replicator ；
- java編寫的開源的中間件複製產品
- 提供：數據複製，自動數據分片，多線程複製等等；
- 【496~497】

最總要的工具

Percona Toolkit
PerconaXtraBackup

2020-05-07 小杭

ε=(´ο｀*)))唉這算是白看了啊！很多東西在5.7版本已經優化調整了啊。。。。。

高性能MySQL-筆記6-關於MySQL複製的東東