MySQL主從復制原理、半同步操作步驟及原理

1.1 企業Linux運維場景數據同步方案

1.1.1 文件級別的異機同步方案

1、scp/sftp/nc 命令可以實現遠程數據同步。

2、搭建ftp/http/svn/nfs 服務器，然后在客戶端上也可以把數據同步到服務器。

3、搭建samba文件共享服務，然后在客戶端上也可以把數據同步到服務器。

http://taokey.blog.51cto.com/4633273/1203553

4、利用rsync/csync2/union等均可以實現數據同步

提示：union可實現雙同步，csync2可實現多機同步。

以上文件同步方式如果結合定時任何或者inotify，sersync等功能，可以實現定時以及定時的數據同步。

5、文件級別也可以利用mysql，mongodb等軟件作為容器實現。

6、程序向兩個服務器同時寫入數據，雙寫就是一個同步機制

特點：簡單、方便、效率和文件系統級別要差一點，但是同步的節點可以提供訪問。

軟件的自身同步機制（mysql，oracle，mongdb，ttserver，redis….）文件放到數據庫，同步到從庫，再把文件拿出來。

7、DRBD文件系統級別（基于塊設備復制，直接復制block）

1.1.2 文件系統級別的異機同步方案

1、drbd基于文件系統同步，相當于網絡RAID1，可以同步幾乎任何業務數據。

mysql數據庫的官方推薦drbd同步數據，所有單點服務例如：NFS、MFS（DRBD）MySQL等都可以用drbd做復制，效率很高，缺點：備機服務不可用

2、數據庫同步方案：

a.自身同步機制：

? mysql replication，mysql主從復制（邏輯的SQL重寫）物理復制方法<===drbd（從庫不提供讀寫）

? oracle dataguard（物理的磁盤塊，邏輯的SQL語句重寫）9i從庫不提供腹瀉的，11g的從庫實現了readonly

b.第三方drbd，參考URL

Heartbeat+DRBD+MySQL高可用架構方案與實施過程細節?

http://oldboy.blog.51cto.com/2561410/1240412

? ? ? ? ? ? ? ??

1.2 MySQL主從復制

? MySQL的主從復制方案，和上述文件及文件系統級別同步是類似的，都輸數據的傳輸。只不過MySQL無需借助第三方工具，而是其自帶的同步復制功能，另外一點，MySQL的主從復制并不是從硬盤給上文件直接同步，而是邏輯的binlog日志同步到本地的應用執行的過程

提示：官方說主從不要超過9臺，推薦不超過5臺。

1、單向主從復制邏輯圖

2、雙向主主同步邏輯圖，此架構可以在Master1端或Master2端進行數據寫入

3、線性級聯單向雙主同步邏輯圖，此架構只能在Master1端進行數據寫入

4、環狀級聯單向多主同步邏輯圖，任何一個點都可以寫入數據

5、環狀級聯單向多主多從同步邏輯圖，此架構只能在任意一個Master端進行數據寫入

MySQL官方的同步架構圖

工作中第一種方案和第二種方案最常用。

1.3 MySQL主從復制原理介紹

? MySQL的主從復制是一個異步的復制過程（雖然一般情況下感覺是實時的），數據將從一個Mysql數據庫（我們稱之為Master）復制到另一個Mysql數據庫（我們稱之為Slave），在Master與Slave之間實現整個主從復制的過程是由三個線程參與完成的。其中有兩個線程（SQL線程和IO線程）在Slave端，另一個線程（I/O線程）在Master端。

? 要實現MySQL的主從復制，首先必須打開Master端的binlog記錄功能，否則就無法實現。因為整個復制過程實際上就是Slave從aster端獲取binlog日志，然后再在Slave上以相同順序執行獲取的binlog日志中的記錄的各種SQL操作

畫圖：

1）在Slave?服務器上執行sart slave命令開啟主從復制開關，開始進行主從復制。

2）此時，Slave服務器的IO線程會通過在master上已經授權的復制用戶權限請求連接master服務器，并請求從執行binlog日志文件的指定位置（日志文件名和位置就是在配置主從復制服務時執行change
master命令指定的）之后開始發送binlog日志內容

3）Master服務器接收到來自Slave服務器的IO線程的請求后，其上負責復制的IO線程會根據Slave服務器的IO線程請求的信息分批讀取指定binlog日志文件指定位置之后的binlog日志信息，然后返回給Slave端的IO線程。返回的信息中除了binlog日志內容外，還有在Master服務器端記錄的IO線程。返回的信息中除了binlog中的下一個指定更新位置。

4）當Slave服務器的IO線程獲取到Master服務器上IO線程發送的日志內容、日志文件及位置點后，會將binlog日志內容依次寫到Slave端自身的Relay Log（即中繼日志）文件（Mysql-relay-bin.xxx）的最末端，并將新的binlog文件名和位置記錄到master-info文件中，以便下一次讀取master端新binlog日志時能告訴Master服務器從新binlog日志的指定文件及位置開始讀取新的binlog日志內容

5）Slave服務器端的SQL線程會實時檢測本地Relay Log?中IO線程新增的日志內容，然后及時把Relay LOG?文件中的內容解析成sql語句，并在自身Slave服務器上按解析SQL語句的位置順序執行應用這樣sql語句，并在relay-log.info中記錄當前應用中繼日志的文件名和位置點

主從復制條件

1、開啟Binlog功能

2、主庫要建立賬號

3、從庫要配置master.info（CHANGE MASTER to…相當于配置密碼文件和Master的相關信息）

4、start slave 開啟復制功能

知識點

1.3個線程，主庫IO，從庫IO和SQL及作用

2.master.info（從庫）作用

3.relay-log 作用

4.異步復制

5.binlog作用（如果需要級聯需要開啟Binlog）

小結：

主從復制是異步的邏輯的SQL語句級的復制

復制時，主庫有一個O/O線程，從庫有兩個線程，I/O和SQL線程

實現主從復制的必要條件是主庫要開啟記錄binlog功能

作為復制的所有Mysql節點的server-id都不能相同

binlog文件只記錄對數據庫有更改的SQL語句（來自主庫內容的變更），不記錄任何查詢（select，show）語句

1.4 環境搭建

我們準備的是多實例，一臺服務器開啟3個服務端口不同

環境準備：

[root@db02 3307]# netstat -lntup|grep 330

tcp??????? 0????? 0 0.0.0.0:3306??????????????? 0.0.0.0:*?????????????????? LISTEN????? 3074/mysqld????????

tcp??????? 0????? 0 0.0.0.0:3307??????????????? 0.0.0.0:*?????????????????? LISTEN????? 33364/mysqld???????

tcp??????? 0????? 0 0.0.0.0:3308????? ??????????0.0.0.0:*?????????????????? LISTEN????? 34084/mysqld

主庫開啟Binlog功能

[root@db02 3307]# grep log-bin /data/3306/my.cnf

log-bin = /data/3306/mysql-bin

設置server-id，此處ID不可以相同否則最后出現IO錯誤

[root@db02 3307]# grep server-id /data/3306/my.cnf

server-id = 1

[root@db02 3307]# grep server-id /data/3307/my.cnf

server-id = 3

[root@db02 3307]# grep server-id /data/3308/my.cnf

server-id = 2

================================================

[root@db02 3307]# grep server-id /data/{3306,3307,3308}/my.cnf

/data/3306/my.cnf:server-id = 1

/data/3307/my.cnf:server-id = 3

/data/3308/my.cnf:server-id = 2

主庫需要授權slave訪問的用戶

mysql>grant replication slave on *.* to 'rep'@'10.0.0.%' identified by '123456';

mysql> flush privileges;

mysql>show grants for rep@'172.16.1.%';

mysql>select user,host from mysql.user

#replication slave 為mysql同步的必須權限，此處不要授權all權限

因為從庫現在還沒有數據，或者數據不統一我們需要導入數據

鎖表、查看binlog文件及位置點，主庫導出全備，需要鎖表（-x –master-date=2）? ??

flush table with read lock;?? 鎖表，窗口不能退出，退出失效

root@oldboy 05:16:22->show master status;? 臨界點，將來恢復就從0025開始

+------------------+----------+--------------+------------------+

| File???????????? | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000025 |???? 9155 |????????????? |??????????? ??????|

+------------------+----------+--------------+------------------+

1 row in set (0.00 sec)

備份

mysqldump -uroot -p123456 -S /data/3306/mysql.sock -A -B --events|gzip >/server/backup/rep_bak$(date +%F).sql.gz

?

[root@db02 oldboy]# ls -lrt /server/backup/

total 308

-rw-r--r-- 1 root root???? 20 Dec 23? 2015 bak_2015-12-23.sql.gz

-rw-r--r-- 1 root root 152214 Dec 23? 2015 bak.sql.gz

-rw-r--r-- 1 root root 152238 Jun 29 17:20 rep_bak2016-06-29.sql.gz

解鎖：unlock table;

root@oldboy 05:22:00->show master status;

+------------------+----------+--------------+------------------+

| File???????????? | Position | Binlog_Do_DB | Binlog_Ignore_DB |

+------------------+----------+--------------+------------------+

| mysql-bin.000025 |???? 9155 |?????????? ???|????????????????? |

+------------------+----------+--------------+------------------+

#如果解鎖之后還是mysql-bin.000025?說明是正確的，如果動了說明沒有鎖住表

#如果mysqldump?加了-F?他就會更改刷新binlog

從庫操作

1.確保server-id不同

2.把主庫的備份導入到從庫

[root@db02 backup]# gzip -d rep_bak2016-06-29.sql.gz

[root@db02 backup]# mysql -uroot -p123456 -S /data/3307/mysql.sock <rep_bak2016-06-29.sql

3.查找位置點，配置master.info

mysql-bin.000025 |? ???9155
|? ?主庫的位置點

Mysql從庫連接主庫的配置信息如下：

CHANGE?MASTER?TO?

MASTER_HOST='172.16.1.52',? #這是主庫的IP（域名也可以需要做解析）

MASTER_PORT=3306,????????????? #主庫的端口，從庫端口和主庫不可以相同

MASTER_USER='rep',??????????? #這是主庫上創建用來復制的用戶rep

MASTER_PASSWORD='123456'??? #rep的密碼

MASTER_LOG_FILE='mysql-bin.000025', #這里是show master status時看到的查詢二進制日志文件名稱，這里不能多空格

MASTER_LOG_POS=9155;??????#這里是show master status時看到的二進制日志偏移量，不能多空格

提示：3307操作此步：會在/data/3307/data下面產生master.info文件

開啟從庫復制開關

root@oldboy 07:47:44->show slave status\G

*************************** 1. row ***************************

?????????????? Slave_IO_State: Waiting for master to send event

????????????????? Master_Host: www.etiantian.org

????????????????? Master_User: rep

????????????????? Master_Port: 3306

??????????????? Connect_Retry: 60

????????? ????Master_Log_File: mysql-bin.000025

????????? Read_Master_Log_Pos: 9706

?????????????? Relay_Log_File: relay-bin.000002

??????????????? Relay_Log_Pos: 453

??????? Relay_Master_Log_File: mysql-bin.000025

???????????? Slave_IO_Running: Yes?????? IO線程代表IO正常

??????????? Slave_SQL_Running: Yes??????????????? SQL線程

????????????? Replicate_Do_DB:

????????? Replicate_Ignore_DB: mysql

?????????? Replicate_Do_Table:

?????? Replicate_Ignore_Table:

????? Replicate_Wild_Do_Table:

? Replicate_Wild_Ignore_Table:

?????????????????? Last_Errno: 0

?????????????????? Last_Error:

???????????????? Skip_Counter: 0

????????? Exec_Master_Log_Pos: 9706

????????????? Relay_Log_Space: 603

????????????? Until_Condition: None

?????????????? Until_Log_File:

??????????????? Until_Log_Pos: 0

?????????? Master_SSL_Allowed: No

?????????? Master_SSL_CA_File:

?????????? Master_SSL_CA_Path:

????????????? Master_SSL_Cert:

??????????? Master_SSL_Cipher:

?????????????? Master_SSL_Key:

??????? Seconds_Behind_Master: 0??? 延遲

Master_SSL_Verify_Server_Cert: No

??????????????? Last_IO_Errno: 0

??????????????? Last_IO_Error:

?????????????? Last_SQL_Errno: 0

?????????????? Last_SQL_Error:

? Replicate_Ignore_Server_Ids:

???????????? Master_Server_Id: 1

1 row in set (0.00 sec)

查看檢查結果：在主庫創建目錄查看從庫是否存在即可

提示：如果出現show master status里面沒有東西說明bin-log日志沒有開啟

Slave_IO_Running:Yes，這是I/O線程狀態，I/O線程負載從從庫去主庫讀取binlog日志，并寫入從庫的中繼日志中，狀態為Yes表示I/O線程工作正常。

Slave_SQL_Running:Yes?這個是SQL線程狀態，SQL線程負載讀取中繼日志（relay-log）中的數據并轉換為SQL語句應用到從庫數據庫中，狀態為Yes表示I/O線程工作正常

Seconds_Behind_Master:0?這個是在復制過程中，從庫比主庫延遲的描述，這個參數很重要，但企業里更準確地判斷主從延遲的方法為：在主庫寫時間戳，然后從庫讀取時間戳進行比較，從而認定是否延遲。

從庫提升主庫步驟

• mysql主從復制中，需要將備庫（從庫）提升為主庫，需要取消其從庫角色，可以通過執行以下命令：

• stop slave;

• reset slave all;

• RESET SLAVE ALL是清除從庫的同步復制信息，包括連接信息和二進制文件名、位置

• 從庫上執行這個命令后，使用show slave status將不會有輸出

1.5 生產場景下輕松部署MySQL主從復制

快速步驟MySQL主從復制

1）安裝好配置從庫的數據庫，配置好log-bin和server-id參數

2）無需配置主庫my.cnf，主庫的log-bin和server-id參數默認就是配置好的。

3）登錄主庫，增加從庫連接同步的賬戶，例如：rep，并授權replication同步的權限

4）使用mysqldump命令帶-x和–master-data=2的命令及參數全備數據，把它恢復到從庫

5）從庫執行CHANGE MASTER TO….語句，需要binlog文件及對應點（因為–master-data=2已經帶了）

6）從庫開啟同步開關，start slave

7）從庫show slave status\G，檢查同步狀態，并在主庫更新測試

步驟：

主庫：

shell>mysqldump -uroot -p123456 -S /data/3306/mysql.sock -B -F -R -x --master-data=1 -A --events|gzip >/server/backup/rep3307_(date +%F).sql.gz

因為添加了master-data=1 已經為我們寫好了位置點

從庫：

shell>mysql -uroot -p123456 -S /data/3307/mysql.sock <./repo3307_2016-07-03.sql

mysql>CHANGE MASTER TO

MASTER_HOST='www.etiantian.org',

MASTER_PORT=3306,

MASTER_USER='rep',

MASTER_PASSWORD='123456',

MASTER_LOG_FILE='mysql-bin.000025',

MASTER_LOG_POS=9815;

mysql>start slave

mysql>show slave status\G

錯誤提示：

Slave_SQL_Running：NO 下面會有提示，如果提示這個庫已經創建無法創建等是可以跳過的

解決辦法

stop slave;

set global sql_slave_skip_counter =1; #將同步指針向下移動，如果多次不同步，可以添加移動的數量

start slave;

查看連接的線程，每一個線程代表一個從庫

root@oldboy 08:51:37->show processlist;

+----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+

| Id | User | Host ? ? ? ? ? ? ?| db ? | Command ? ? | Time | State ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Info ? ? ? ? ? ? |

+----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+

| ?2 | rep ?| 172.16.1.52:51317 | NULL | Binlog Dump | ? 68 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL ? ? ? ? ? ? |

| ?3 | root | localhost ? ? ? ? | NULL | Query ? ? ? | ? ?0 | NULL ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| show processlist |

+----+------+-------------------+------+-------------+------+-----------------------------------------------------------------------+------------------+

2 rows in set (0.00 sec)

主庫I/O工作狀態上方×××

主庫I/O 線程工作狀態	解釋說明
Sending binlog event to slave	線程已經從二進制binlog日志讀取了一個事件并且正將它發送到從服務器
Finished reading one binlog；switching to next binlog	線程已經讀完二進制binlog日志文件，并且整打開下一個要發送到從服務器的binlog日志文件
Has sent all binlog to slave；waiting for binlog to be updated	線程已經從binlog日志讀取所有更新并已經發送到了從數據庫服務器。線程現在為空閑狀態，等待由主服務器上二進制binlog日志中的新事件更新。
Waiting to finalize termination	線程停止時發送的一個很簡單的狀態

從庫I/O線程工作狀態show processlist;

從庫I/O線程工作狀態	解釋說明
Connecting to master	線程正試圖連接主服務器
Checking master version	同步主服務器之間建立后臨時出現的狀態
Registering slave to master
Requesting binlog dump	建庫同主服務器之間的連接后立即臨時出現的狀態，線程向主服務器發送一條請求，索取從請求的二進制binlog日志文件名和位置開始的二進制binlog日志的內容
Waiting to reconnect after a failed binlog dump request	如果二進制binlog日志轉存儲請求失敗，線程進行睡眠狀態，嘗試重新連接
Reading event from the relay log	線程已經從中繼日志讀取了一個事件，可以對事件進行處理了。
Has read all relay log；waiting for the slave I/O thread to update it	線程已經處理了中繼日志文件中的所有事件，現在等待I.O線程將新事件寫入中繼日志
Waiting for slave mutex on exit	線程停止時發生了一個很簡單的狀態

1.6 MySQL主從復制更多應用技巧實踐

1. 工作中MySQL從庫停止復制的故障案例

? 模擬重現故障的鞥能力是運維人員最重要的能力。下面就進行模擬操作。先在從庫創建一個庫，然后去主庫創建同名的庫來模擬數據沖突

mysql>show slave status;報錯：且show slave status\G;

? ? ? ? ? ? Slave_IO_Running: Yes

? ? ? ? ? ? Slave_SQL_Running: No

? ? ? ? ? ? ? Replicate_Do_DB:?

? ? ? ? ? Replicate_Ignore_DB: mysql

? ? ? ? ? ?Replicate_Do_Table:?

? ? ? ?Replicate_Ignore_Table:?

? ? ? Replicate_Wild_Do_Table:?

? Replicate_Wild_Ignore_Table:?

? ? ? ? ? ? ? ? ? ?Last_Errno: 1007

? ? ? ? ? ? ? ? ? ?Last_Error: Error ‘Can’t create database ‘cyh’; database exists’ on query. Default database: ‘cyh’. Query: ‘create database cyh’

對于該沖突，解決方法為：

stop slave； ?#臨時停止同步開關

set global sql_slave_skip_counter =1； #將同步指針向下移動一個

start slave；

或可以根據錯誤號事先在配置文件中配置，跳過指定的不影響業務的數據的錯誤，例如：

[root@db02 oldboy]# grep slave-skip /data/3306/my.cnf

slave-skip-errors = 1032,1062

提示：類似由于入庫重復導致的失敗可以忽略，其他情況是不可以忽略需要根據公司不同業務來評估。

錯誤2

MYSQL ERROR 139 (HY000)錯誤的解決辦法

標簽：mysql error 1396 it

創建用戶的時候報這個錯誤，原因是MYSQL中已經有了這個用戶，可以用mysql.user中直接刪除，然后刷新權限，在創建用戶就不會有這個問題了。如果是drop user先，那么mysql內部應該會自動刷新一下，那么在創建就不會這個問題看

其他可能引起復制故障的問題：

• MySQL自身的原因以及人為重復插入數據

• 不同的數據版本會引起不同步，低版本到高版本可以，但是高版本不能往低版本同步

• MySQL的運行錯誤或者程序BUG

• binlog記錄模式，例如：row level模式就比默認的語句要好

1.7 讓MySQL從庫記錄binlog日志方法

??從庫需要記錄binlog的場景為：當前從庫還要作為其他從庫的主庫，例如：級聯復制或者雙主互為主從場景的情況下。

在從庫的my.cnf中加入如下參數，然后重啟服務生效

log-slave-updates ?#必須要有這個參數

log-bin = /data/3307/mysql-bin

expire_logs_days = 7 #相當于刪除7天之后的日志

1.7 Mysql主從復制延遲問題原因及解決方法

問題一：一個主庫的從庫太多，導致復制延遲。

建議從庫數量3-5 為宜，要復制的從節點數量過多，會導致復制延遲

問題二：從庫硬件比主庫差，導致復制延遲

??查看master和slave的系統配置，可能會因為機器配置的問題，包括磁盤IO、CPU、內存等各方面因素造成復制的延遲，一般發生在高并發大數據量寫入場景。

問題三：慢SQL語句過多

??假如一條SQL語句，執行時間是20秒，那么從庫執行完畢，到從庫上能查到數據也至少是20秒，這樣就延遲20秒了

??SQL語句的優化一般要作為常規工作不斷的監控和優化，如果是單個SQL的寫入時間長，可以修改后分多次寫入，通過查看慢查詢日志或show full processlist 命令找出執行時間長的查詢語句或者打的事務。

問題四：主從復制的設計問題

?例如，主從復制單線程，因為主庫寫并發太大，來不及傳送到從庫就會導致延遲。

更高版本的MySQL可以支持多線程復制，門戶網站會開發自己多線程同步功能。

問題五：主從庫之間的網絡延遲。

??主庫的網卡、網線、連接的交換機等網絡設備都可能成為復制的瓶頸，導致復制延遲，另外，跨公網主從復制很容易導致主庫復制延遲

問題六：主庫讀寫壓力大，導致復制延遲

主庫硬件要搞好一點，架構的前端要加buffer以及緩存層。

通過read-only參數讓從庫只讀訪問

? read-only參數選項可以讓從服務器只允許來自服務器線程或具有SUPER權限的數據庫用戶進行更新，可以確保從服務器不接受來自用戶端的非法用戶更新。

? read-only參數具有允許數據庫更新的條件為：

• 具有SUPER權限的用戶可以更新，不受read-only參數影響，例如：管理員root。

• 來自從服務器線程可以更新，不受read-only參數影響，例如：rep用戶

? 在生產環境中，可以在從庫Slave中使用read-only參數，確保從庫數據不被非法更新。

read-only參數的配置如下：

方法一：啟動數據庫時直接帶–read-only參數啟動或重啟，使用

mysqladmin -uroot -p123456 -S /data/3307/mysql.sock shutdown

mysql_safe --defaults-file=/data/3307/my.cnf --read-only &

方法二：在my.cnf里[mysqld]模塊下加read-only參數，然后重啟數據庫

[mysqld]

read-only

1.8 Web用戶專業設置方案：MySQL主從復制讀寫分離集群

? 專業的運維人員提供給開發人員的讀寫分離的賬戶設置如下：

1）訪問主庫和從庫時使用一套用戶密碼，例如，用戶名：web，密碼：123456

2）即使訪問IP不同，端口也盡量相同（3306）。例如:寫庫VIP為10.0.0.1 ，讀庫VIP為10.0.0.2

? 除了IP沒辦法修改之外，要盡量為開發人員提供方便，如果數據庫前端有DAL層（DBPROXY代理）還可以只給開發人員一套用戶、密碼、IP、端口，這樣就更專業了，剩下的都是由運維搞定。

如果給開發授權權限

方法1：主庫和從庫使用不同的用戶，授權不同的權限。

主庫上對web_w用戶授權如下：

用戶：web_w 密碼：123456 端口3306 ?主庫VIP：10.0.0.1

權限：SELECT,INSERT,UPDATE,DELETE

命令：GRANT SELECT,INSERT,UPDATE,DELETE ON wen.* to 'web_w'@10.0.0.% identified by '123456';

從庫對web_r用戶授權如下：

用戶：web_r 密碼:123456 端口：3306 從庫VIP：10.0.0.2

權限：SELECT

命令：GRANT SELECT ON web.* TO web@10.0.0.% identfied by '123456';

提示：此方法顯得不夠專業，但是可以滿發開發需求。

方法2：主庫和從庫使用相同的用戶，但授予不同的權限。（由于主從同步 有一些可能無法同步）

主庫上對web用戶授權如下：

用戶：web 密碼：123456 端口：3306 主庫VIP：10.0.0.1

權限：SELECT,INSERT,UPDATE,DELETE

命令：GRANT SELECT,INSERT,UPDATE,DELETE ON web.* TO web@10.0.0.% identified by '123456';

從庫上對web用戶授權如下：

用戶：web ?密碼：123456 端口：3306 ?從庫VIP：10.0.0.2

權限：SELECT

#由于主庫和從庫是同步復制的，所以從庫上的Web用戶會自動和主庫一直，既無法實現只讀select的權限。

方法3：在從庫上設置read-only參數，讓從庫只讀

主庫和從庫：主庫和從庫使用相同的用戶，授予相同的權限（非ALL權限）

用戶：web 密碼：123546 端口：3306 主庫VIP:10.0.0.8

權限：SELECT,INSERT,UPDATE,DELETE

命令：GRANT SELECT,INSERT,UPDATE,DELETE ON web.* to web_w@10.0.0.% identified by '123546';

由于從庫設置了read-only，非super權限是無法寫入的，因為通過read-only參數就可以

忽略授權庫Mysql同步，主庫配置參數如下：

binlog-ignore-db = mysql

replicate-ignore-db = mysql

1.9 MySQL主從復制集群架構的數據備份策略

? 有了主從復制，還需要做定時全量備份

因為，如果主庫有語句誤操作（例如：drop database oldboy;）從庫也會執行drop，這樣MySQL從庫就都刪除了該數據。

把從庫作為數據備份服務器時，備份策略如下：

高并發業務場景備份時，可以選擇在一臺從庫上備份（Slave）把從庫作為數據備份服務器時需要在從庫binlog功能。

1）選擇一個不對外提供服務的從庫，這樣可以確保和主庫更新最接近，專門做數據備份用

2）開啟從庫的binlog功能。

? 備份時可以選擇只停止SQL線程，停止應用SQL語句到數據庫，I/O線程保留工作狀態，執行命令為stop slave sql_thread；備份方式可以采取mysqldump邏輯備份或者直接物理備份，例如使用cp、tar（針對目錄）工具，或xtrabackup（第三方的物理備份軟件）進行備份，邏輯備份和物理備份的選擇，一般是根據總的備份數據量的多少進行選擇，數據庫低于20G，建議選擇mysqldump邏輯備份方法，安全穩定，最后把全量和binlog數據發送到備份服務器上留存

1.9 MySQL半同步

M –S1

? –S2

? –S3

? –S4

是否事先選擇好從庫，從庫如何選擇

1）半同步從庫（谷歌半同步插件 5.5自帶）

—S1作為備庫

第一:主庫插入數據后，同時寫入到S1，成功返回。

優點:兩臺庫會同時寫入數據。

缺點：寫入會慢，網絡不穩定，主庫持續等待。

解決措施：

1.連不上S1的時候會自動轉為異步

2.設置10秒超時，超時10秒轉為異步

3.S1網絡，硬件要好，不提供服務，只能接管。

總結：

半同步就是就是用戶向mysql寫入數據，先寫入到主庫，然后生成binlog日志。主庫等待從庫來取binlog日志，如果從庫超過10秒沒有來獲取binlog日志。主庫自動轉換為異步，以后用戶寫入數據生成binlog日志，等待用戶自己來取，沒有取到主庫也不在管理。

查看的位置在數據里的安裝目錄下可以找到

[root@db02 oldboy]# ll /application/mysql-5.5.49/lib/plugin/

-rwxr-xr-x 1 root root 173428 Jun 16 12:57 semisync_master.so

-rwxr-xr-x 1 root root ?94098 Jun 16 12:57 semisync_slave.so

2） 從庫什么也不操作，只同步主庫

優點：可以立即接管主庫

缺點：浪費資源 不推薦使用

3）臨時選擇從庫

當主庫宕機后，mysql 臨時選擇一個最接近主庫的slave

確定主之后，角色切換S1提升為新主M1

主庫宕機有兩種情況

1、如果主庫可以SSH連接，bin-log數據沒丟，要把主庫的bin-log補全到所有庫

a.提升S1為M1的操作

? 1）調配置read-only，授權用戶select，變成增刪改查，開啟binlog

? 2）rm -rf master.info relay-log*

? 3）登錄數據庫reset master

? 4）重啟數據庫，提升S1為M1完畢

b.所有從庫:CHANGE MASTER TO,MASTER_LOG_FILE=’mysql-bin.000001′,MASTER_LOG_POS=107

2、如果數據庫連接不上

??a.半同步從庫提升主庫，半同步數據，補全到所有從庫

半同步從庫提升主庫的操作1-a，所有從庫執行同1-b

? b.S1 只當做備庫的方法

提升S1為主庫，操作見1-a步驟，所有從庫CHANGE MASTER 同1-b

? c.主庫宕機實現沒有指定從庫為主庫

選主的過程:

1.登錄國有從庫show processlist;里面有2個線程，查看2個線程狀態

登錄所有從庫，分別查看master.info

[root@db02 data]# cat master.info

18

mysql-bin.000028

188

www.etiantian.org

rep

123456

3306

60

0

確保更新完畢，查看4個從庫那個更快，經過測試沒有延遲的情況POS差距很小，甚至一直的

選擇文件及位置點最大的為主庫，補全所有其他從庫，和當前準備為主的數據一直。

從庫提升主庫的操作步驟（簡單說明）

提升的主庫操作

1.確保所有relay log全部更新完畢

在每個庫執行seop slave in_thread(sql線程)；show processlit

直到看到Has read all relay log；表示從庫更新都執行完畢；

2.登錄從庫提升為主庫

登錄：mysql -uroot -p123456 -S /data/3306/mysql.sock

stop slave;

retset master;

quit;

3.進到數據庫數據目錄，刪除master.info relay-log.info

cd /data/3306/data

rm -rf master.info relay-log.info

檢查mysql授權表（web用戶權限以及從庫同步的權限）是不是正確的

read-only等參數

確認bin-log是否開啟

4.開啟binlog

vim /data/3306/my.cnf

log-bin = /data/3306/mysql-bin

//如果存在log-slave-updates read-only等一定要注釋掉它。

/data/3306/mysql restart

到此為止，提升主庫完畢

其他從庫操作

登錄從庫

stop slave；

CHANGE MASTER TO MASTER_HOST ='192.168.1.1'; #如果不同步，就指定位置點。

start slave；

show slave status\G

==========================主庫宕機切換成功

修改程序配置文件從主數據庫32指定32

平時訪問數據庫用域名，則直接可以修改hosts解析。

HMA高可用根據就是利用以上原理實現的。

以上是mysql主庫意外宕機。

假如：我們有計劃切換，如何從操作？

1.主庫鎖表

2.登錄所有的庫查看同步狀態，是否完成

步驟和前面相同

2.1 MySQL常用高可用方案

mysql+HA+DRBD高可用場景

mysql+MMM

mysql+MHA（日本人開發）

實現原理：把所有服務器之間做了一個SSH免密鑰登錄，控制臺登錄到主庫分發binlog到所有從庫，在上從庫比對哪一個更快更全

PXC

mysql+cluster （企業很少使用）

很多企業常用M-S

? ? ? ?

轉載于:https://blog.51cto.com/xiaocao13140/2119899

總結

以上是生活随笔為你收集整理的MySQL主从复制原理、半同步操作步骤及原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。