MySql數據庫中實現主從復制的原理是什么

本篇文章為大家展示了MySql數據庫中實現主從復制的原理是什么，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

數據庫讀寫分離對于大型系統或者訪問量很高的互聯網應用來說，是必不可少的一個重要功能。對于MySQL來說，標準的讀寫分離是主從模式，一個寫節點Master后面跟著多個讀節點，讀節點的數量取決于系統的壓力，通常是1-3個讀節點的配置。而一般的讀寫分離中間件，例如Mycat的讀寫分離和自動切換機制，需要mysql的主從復制機制配合。

主從配置需要注意的地方

1、主DB server和從DB server數據庫的版本一致

2、主DB server和從DB server數據庫數據名稱一致

3、主DB server開啟二進制日志,主DB server和從DB server的server_id都必須唯一MySQL主服務器配置

第一步：修改my.conf文件：

在[mysqld]段下添加：

binlog-ignore-db=mysql

#啟用二進制日志
log-bin=mysql-bin
//二進制日志的格式，有三種：statement/row/mixed
binlog_format=row
#主服務器唯一ID，一般取IP最后一段
server-id=82

第二步：重啟mysql服務

service mysql restart

第三步：建立帳戶并授權slave

mysql>GRANT FILE ON *.* TO 'slave'@'%' IDENTIFIED BY 'slavepw';
mysql>GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* to 'slave'@'%' identified by 'slavepw';

一般不用root帳號，“%”表示所有客戶端都可能連，只要帳號，密碼正確，此處可用具體客戶端IP代替，如192.168.145.226，加強安全。

刷新權限

mysql> FLUSH PRIVILEGES;

第四步：查詢master的狀態

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

MySQL從服務器配置

第一步：修改my.conf文件

[mysqld]#從服務器唯一ID，一般取IP最后一段server-id=83

第二步：配置從服務器

mysql>change master to master_host='192.168.11.82',master_port=3306,master_user='slave',master_password='slavepw',master_log_file='mysql-bin.000001',master_log_pos=881;

注意語句中間不要斷開，master_port為mysql服務器端口號(無引號)，master_user為執行同步操作的數據庫賬戶，“881”無單引號(此處的881就是show master status 中看到的position的值，這里的mysql-bin.000001就是file對應的值)。

第三步：啟動從服務器復制功能

mysql>start slave;

第四步：檢查從服務器復制功能狀態：

mysql> show slave status;

Slave_IO_Running: Yes //此狀態必須YES

Slave_SQL_Running: Yes //此狀態必須YES

注：Slave_IO及Slave_SQL進程必須正常運行，即YES狀態，否則都是錯誤的狀態(如：其中一個NO均屬錯誤)。

進行驗證

在主節點上創建表、插入數據，發現從節點也創建表并插入數據。

MySQL 主從復制原理的是啥？

主庫將變更寫入 binlog 日志，然后從庫連接到主庫之后，從庫有一個 IO 線程，將主庫的 binlog 日志拷貝到自己本地，寫入一個 relay 中繼日志中。接著從庫中有一個 SQL 線程會從中繼日志讀取 binlog，然后執行 binlog 日志中的內容，也就是在自己本地再次執行一遍 SQL，這樣就可以保證自己跟主庫的數據是一樣的。

這里有一個非常重要的一點，就是從庫同步主庫數據的過程是串行化的，也就是說主庫上并行的操作，在從庫上會串行執行。所以這就是一個非常重要的點了，由于從庫從主庫拷貝日志以及串行執行 SQL 的特點，在高并發場景下，從庫的數據一定會比主庫慢一些，是有延時的。所以經常出現，剛寫入主庫的數據可能是讀不到的，要過幾十毫秒，甚至幾百毫秒才能讀取到。

而且這里還有另外一個問題，就是如果主庫突然宕機，然后恰好數據還沒同步到從庫，那么有些數據可能在從庫上是沒有的，有些數據可能就丟失了。

所以 MySQL 實際上在這一塊有兩個機制，一個是半同步復制，用來解決主庫數據丟失問題；一個是并行復制，用來解決主從同步延時問題。

這個所謂半同步復制，也叫semi-sync復制，指的就是主庫寫入 binlog 日志之后，就會將強制此時立即將數據同步到從庫，從庫將日志寫入自己本地的 relay log 之后，接著會返回一個 ack 給主庫，主庫接收到至少一個從庫的 ack 之后才會認為寫操作完成了。

所謂并行復制，指的是從庫開啟多個線程，并行讀取 relay log 中不同庫的日志，然后并行重放不同庫的日志，這是庫級別的并行。

MySQL 主從同步延時問題

以前線上確實處理過因為主從同步延時問題而導致的線上的 bug，屬于小型的生產事故。

是這個么場景。有個同學是這樣寫代碼邏輯的。先插入一條數據，再把它查出來，然后更新這條數據。在生產環境高峰期，寫并發達到了 2000/s，這個時候，主從復制延時大概是在小幾十毫秒。線上會發現，每天總有那么一些數據，我們期望更新一些重要的數據狀態，但在高峰期時候卻沒更新。用戶跟客服反饋，而客服就會反饋給我們。

我們通過 MySQL 命令：

show status

查看Seconds_Behind_Master，可以看到從庫復制主庫的數據落后了幾 ms。

一般來說，如果主從延遲較為嚴重，有以下解決方案：

分庫，將一個主庫拆分為多個主庫，每個主庫的寫并發就減少了幾倍，此時主從延遲可以忽略不計。打開 MySQL 支持的并行復制，多個庫并行復制。如果說某個庫的寫入并發就是特別高，單庫寫并發達到了 2000/s，并行復制還是沒意義。重寫代碼，寫代碼的同學，要慎重，插入數據時立馬查詢可能查不到。如果確實是存在必須先插入，立馬要求就查詢到，然后立馬就要反過來執行一些操作，對這個查詢設置直連主庫。不推薦這種方法，你要是這么搞，讀寫分離的意義就喪失了。開啟并行復制

開啟多線程復制，默認關鍵的參數有兩個：

mysql> show variables like 'slave_parallel_%';
+------------------------+----------+
| Variable_name     | Value  |
+------------------------+----------+
| slave_parallel_type  | DATABASE |
| slave_parallel_workers | 0    |
+------------------------+----------+
2 rows in set (0.00 sec)

slave-parallel-type 默認值為database

slave-parallel-workers 默認值為0

開啟：

mysql> stop slave sql_thread;

Query OK, 0 rows affected (0.05 sec)

mysql> set global slave_parallel_type='LOGICAL_CLOCK';

Query OK, 0 rows affected (0.00 sec)

mysql> set global slave_parallel_workers=4;

Query OK, 0 rows affected (0.00 sec)

mysql> start slave sql_thread;

Query OK, 0 rows affected (0.07 sec)

上述內容就是MySql數據庫中實現主從復制的原理是什么，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。