小編給大家分享一下MySQL主從復(fù)制是什么，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！

十載的白水網(wǎng)站建設(shè)經(jīng)驗，針對設(shè)計、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時及時工作處理。營銷型網(wǎng)站的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整白水建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“白水網(wǎng)站設(shè)計”,“白水網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

一、什么是Mysql主從復(fù)制

MySQL主從復(fù)制是其最重要的功能之一。主從復(fù)制是指一臺服務(wù)器充當(dāng)主數(shù)據(jù)庫服務(wù)器，另一臺或多臺服務(wù)器充當(dāng)從數(shù)據(jù)庫服務(wù)器，主服務(wù)器中的數(shù)據(jù)自動復(fù)制到從服務(wù)器之中。對于多級復(fù)制，數(shù)據(jù)庫服務(wù)器即可充當(dāng)主機，也可充當(dāng)從機。MySQL主從復(fù)制的基礎(chǔ)是主服務(wù)器對數(shù)據(jù)庫修改記錄二進制日志，從服務(wù)器通過主服務(wù)器的二進制日志自動執(zhí)行更新。

二、Mysq主從復(fù)制的類型

1、基于語句的復(fù)制：

主服務(wù)器上面執(zhí)行的語句在從服務(wù)器上面再執(zhí)行一遍，在MySQL-3.23版本以后支持。

存在的問題：時間上可能不完全同步造成偏差，執(zhí)行語句的用戶也可能是不同一個用戶。

2、基于行的復(fù)制：

把主服務(wù)器上面改編后的內(nèi)容直接復(fù)制過去，而不關(guān)心到底改變該內(nèi)容是由哪條語句引發(fā)的，在MySQL-5.0版本以后引入。

存在的問題：比如一個工資表中有一萬個用戶，我們把每個用戶的工資+1000，那么基于行的復(fù)制則要復(fù)制一萬行的內(nèi)容，由此造成的開銷比較大，而基于語句的復(fù)制僅僅一條語句就可以了。

3、混合類型的復(fù)制：

MySQL默認使用基于語句的復(fù)制，當(dāng)基于語句的復(fù)制會引發(fā)問題的時候就會使用基于行的復(fù)制，MySQL會自動進行選擇。

在MySQL主從復(fù)制架構(gòu)中，讀操作可以在所有的服務(wù)器上面進行，而寫操作只能在主服務(wù)器上面進行。主從復(fù)制架構(gòu)雖然給讀操作提供了擴展，可如果寫操作也比較多的話（多臺從服務(wù)器還要從主服務(wù)器上面同步數(shù)據(jù)），單主模型的復(fù)制中主服務(wù)器勢必會成為性能瓶頸。

三、Mysql主從復(fù)制的工作原理

1、基于語句的復(fù)制：主服務(wù)器上面執(zhí)行的語句在從服務(wù)器上面再執(zhí)行一遍，在MySQL-3.23版本以后支持。

存在的問題：時間上可能不完全同步造成偏差，執(zhí)行語句的用戶也可能是不同一個用戶。

2、基于行的復(fù)制：把主服務(wù)器上面改編后的內(nèi)容直接復(fù)制過去，而不關(guān)心到底改變該內(nèi)容是由哪條語句引發(fā)的，在MySQL-5.0版本以后引入。

存在的問題：比如一個工資表中有一萬個用戶，我們把每個用戶的工資+1000，那么基于行的復(fù)制則要復(fù)制一萬行的內(nèi)容，由此造成的開銷比較大，而基于語句的復(fù)制僅僅一條語句就可以了。

3、混合類型的復(fù)制：MySQL默認使用基于語句的復(fù)制，當(dāng)基于語句的復(fù)制會引發(fā)問題的時候就會使用基于行的復(fù)制，MySQL會自動進行選擇。

在MySQL主從復(fù)制架構(gòu)中，讀操作可以在所有的服務(wù)器上面進行，而寫操作只能在主服務(wù)器上面進行。主從復(fù)制架構(gòu)雖然給讀操作提供了擴展，可如果寫操作也比較多的話（多臺從服務(wù)器還要從主服務(wù)器上面同步數(shù)據(jù)），單主模型的復(fù)制中主服務(wù)器勢必會成為性能瓶頸。

三 MySQL主從復(fù)制工作原理

如下圖所示：

主服務(wù)器上面的任何修改都會保存在二進制日志Binary log里面，從服務(wù)器上面啟動一個I/O thread（實際上就是一個主服務(wù)器的客戶端進程），連接到主服務(wù)器上面請求讀取二進制日志，然后把讀取到的二進制日志寫到本地的一個Realy log里面。從服務(wù)器上面開啟一個SQL thread定時檢查Realy log，如果發(fā)現(xiàn)有更改立即把更改的內(nèi)容在本機上面執(zhí)行一遍。

如果一主多從的話，這時主庫既要負責(zé)寫又要負責(zé)為幾個從庫提供二進制日志。此時可以稍做調(diào)整，將二進制日志只給某一從，這一從再開啟二進制日志并將自己的二進制日志再發(fā)給其它從?；蛘呤歉纱噙@個從不記錄只負責(zé)將二進制日志轉(zhuǎn)發(fā)給其它從，這樣架構(gòu)起來性能可能要好得多，而且數(shù)據(jù)之間的延時應(yīng)該也稍微要好一些。工作原理圖如下：

實際上在老版本的MySQL主從復(fù)制中Slave端并不是兩個進程完成的，而是由一個進程完成。但是后來發(fā)現(xiàn)這樣做存在較大的風(fēng)險和性能問題，主要如下：

首先，一個進程會使復(fù)制bin-log日志和解析日志并在自身執(zhí)行的過程成為一個串行的過程，性能受到了一定的限制，異步復(fù)制的延遲也會比較長。

另外，Slave端從Master端獲取bin-log過來之后，需要接著解析日志內(nèi)容，然后在自身執(zhí)行。在這個過程中，Master端可能又產(chǎn)生了大量變化并新增了大量的日志。如果在這個階段Master端的存儲出現(xiàn)了無法修復(fù)的錯誤，那么在這個階段所產(chǎn)生的所有變更都將永遠無法找回。如果在Slave端的壓力比較大的時候，這個過程的時間可能會比較長。

為了提高復(fù)制的性能并解決存在的風(fēng)險，后面版本的MySQL將Slave端的復(fù)制動作交由兩個進程來完成。提出這個改進方案的人是Yahoo!的一位工程師“Jeremy Zawodny”。這樣既解決了性能問題，又縮短了異步的延時時間，同時也減少了可能存在的數(shù)據(jù)丟失量。

當(dāng)然，即使是換成了現(xiàn)在這樣兩個線程處理以后，同樣也還是存在slave數(shù)據(jù)延時以及數(shù)據(jù)丟失的可能性的，畢竟這個復(fù)制是異步的。只要數(shù)據(jù)的更改不是在一個事物中，這些問題都是會存在的。如果要完全避免這些問題，就只能用MySQL的cluster來解決了。不過MySQL的cluster是內(nèi)存數(shù)據(jù)庫的解決方案，需要將所有數(shù)據(jù)都load到內(nèi)存中，這樣就對內(nèi)存的要求就非常大了，對于一般的應(yīng)用來說可實施性不是太大。

還有一點要提的是MySQL的復(fù)制過濾(Replication Filters)，復(fù)制過濾可以讓你只復(fù)制服務(wù)器中的一部分數(shù)據(jù)。有兩種復(fù)制過濾：在Master上過濾二進制日志中的事件；在Slave上過濾中繼日志中的事件。如下：

配置Master的my.cnf文件(關(guān)鍵性的配置)/etc/my.cnf

log-bin=mysql-bin

server-id   = 1

binlog-do-db=icinga

binlog-do-db=DB2     //如果備份多個數(shù)據(jù)庫，重復(fù)設(shè)置這個選項即可

binlog-do-db=DB3   //需要同步的數(shù)據(jù)庫，如果沒有本行，即表示同步所有的數(shù)據(jù)庫

binlog-ignore-db=mysql  //被忽略的數(shù)據(jù)庫

配置Slave的my.cnf文件(關(guān)鍵性的配置)/etc/my.cnf

log-bin=mysql-bin

server-id=2

master-host=10.1.68.110

master-user=backup

master-password=1234qwer

master-port=3306

replicate-do-db=icinga

replicate-do-db=DB2

replicate-do-db=DB3   //需要同步的數(shù)據(jù)庫，如果沒有本行，即表示同步所有的數(shù)據(jù)庫

replicate-ignore-db=mysql   //被忽略的數(shù)據(jù)庫

網(wǎng)友說replicate-do-db的使用中可能會出些問題（http://blog.knowsky.com/19696...），自己沒有親自去測試。猜想binlog-do-db參數(shù)用于主服務(wù)器中，通過過濾Binary Log來過濾掉配置文件中不允許復(fù)制的數(shù)據(jù)庫，也就是不向Binary Log中寫入不允許復(fù)制數(shù)據(jù)的操作日志；而replicate-do-db用于從服務(wù)器中，通過過濾Relay Log來過濾掉不允許復(fù)制的數(shù)據(jù)庫或表，也就是執(zhí)行Relay Log中的動作時不執(zhí)行那些不被允許的修改動作。這樣的話，多個從數(shù)據(jù)庫服務(wù)器的情況：有的從服務(wù)器既從主服務(wù)器中復(fù)制數(shù)據(jù)，又做為主服務(wù)器向另外的從服務(wù)器復(fù)制數(shù)據(jù)，那它的配置文件中應(yīng)該可以同時存在binlog-do-db、replicate-do-db這兩個參數(shù)才對。一切都是自己的預(yù)測，關(guān)于binlog-do-db、replicate-do-db的具體使用方法還得在實際開發(fā)中一點點摸索才可以。

網(wǎng)上有說，復(fù)制時忽略某些數(shù)據(jù)庫或者表的操作最好不要在主服務(wù)器上面進行，因為主服務(wù)器忽略之后就不會再往二進制文件中寫了，但是在從服務(wù)器上面雖然忽略了某些數(shù)據(jù)庫但是主服務(wù)器上面的這些操作信息依然會被復(fù)制到從服務(wù)器上面的relay log里面，只是不會在從服務(wù)器上面執(zhí)行而已。我想這個意思應(yīng)該是建議在從服務(wù)器中設(shè)置replicate-do-db，而不要在主服務(wù)器上設(shè)置binlog-do-db。

另外，不管是黑名單（binlog-ignore-db、replicate-ignore-db）還是白名單（binlog-do-db、replicate-do-db）只寫一個就行了，如果同時使用那么只有白名單生效。

四、Mysql主從復(fù)制的過程

MySQL主從復(fù)制的兩種情況：同步復(fù)制和異步復(fù)制，實際復(fù)制架構(gòu)中大部分為異步復(fù)制。

復(fù)制的基本過程如下：

1. Slave上面的IO進程連接上Master，并請求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內(nèi)容。

2. Master接收到來自Slave的IO進程的請求后，負責(zé)復(fù)制的IO進程會根據(jù)請求信息讀取日志指定位置之后的日志信息，返回給Slave的IO進程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息已經(jīng)到Master端的bin-log文件的名稱以及bin-log的位置。

3. Slave的IO進程接收到信息后，將接收到的日志內(nèi)容依次添加到Slave端的relay-log文件的最末端，并將讀取到的Master端的 bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個bin-log的哪個位置開始往后的日志內(nèi)容，請發(fā)給我”。

4. Slave的Sql進程檢測到relay-log中新增加了內(nèi)容后，會馬上解析relay-log的內(nèi)容成為在Master端真實執(zhí)行時候的那些可執(zhí)行的內(nèi)容，并在自身執(zhí)行。

五、Mysql主從復(fù)制的具體配置

復(fù)制通常用來創(chuàng)建主節(jié)點的副本，通過添加冗余節(jié)點來保證高可用性，當(dāng)然復(fù)制也可以用于其他用途，例如在從節(jié)點上進行數(shù)據(jù)讀、分析等等。在橫向擴展的業(yè)務(wù)中，復(fù)制很容易實施，主要表現(xiàn)在在利用主節(jié)點進行寫操作，多個從節(jié)點進行讀操作，MySQL復(fù)制的異步性是指：事物首先在主節(jié)點上提交，然后復(fù)制給從節(jié)點并在從節(jié)點上應(yīng)用，這樣意味著在同一個時間點主從上的數(shù)據(jù)可能不一致。異步復(fù)制的好處在于它比同步復(fù)制要快，如果對數(shù)據(jù)的一致性要求很高，還是采用同步復(fù)制較好。

最簡單的復(fù)制模式就是一主一從的復(fù)制模式了，這樣一個簡單的架構(gòu)只需要三個步驟即可完成：

（1）建立一個主節(jié)點，開啟binlog，設(shè)置服務(wù)器id；

（2）建立一個從節(jié)點，設(shè)置服務(wù)器id；

（3）將從節(jié)點連接到主節(jié)點上。

下面我們開始操作，以MySQL 5.5為例，操作系統(tǒng)Ubuntu12.10，Master 10.1.6.159 Slave 10.1.6.191。

apt-get install mysql-server

Master機器

Master上面開啟binlog日志，并且設(shè)置一個唯一的服務(wù)器id，在局域網(wǎng)內(nèi)這個id必須唯一。二進制的binlog日志記錄master上的所有數(shù)據(jù)庫改變，這個日志會被復(fù)制到從節(jié)點上，并且在從節(jié)點上回放。修改my.cnf文件，在mysqld模塊下修改如下內(nèi)容：

[mysqld]
server-id   = 1
log_bin     = /var/log/mysql/mysql-bin.log

log_bin設(shè)置二進制日志所產(chǎn)生文件的基本名稱，二進制日志由一系列文件組成，log_bin的值是可選項，如果沒有為log_bin設(shè)置值，則默認值是：主機名-bin。如果隨便修改主機名，則binlog日志的名稱也會被改變的。server-id是用來唯一標(biāo)識一個服務(wù)器的，每個服務(wù)器的server-id都不一樣。這樣slave連接到master后，會請求master將所有的binlog傳遞給它，然后將這些binlog在slave上回放。為了防止權(quán)限混亂，一般都是建立一個單獨用于復(fù)制的賬戶。

binlog是復(fù)制過程的關(guān)鍵，它記錄了數(shù)據(jù)庫的所有改變，通常即將執(zhí)行完畢的語句會在binlog日志的末尾寫入一條記錄，binlog只記錄改變數(shù)據(jù)庫的語句，對于不改變數(shù)據(jù)庫的語句則不進行記錄。這種情況叫做基于語句的復(fù)制，前面提到過還有一種情況是基于行的復(fù)制，兩種模式各有各的優(yōu)缺點。

Slave機器

slave機器和master一樣，需要一個唯一的server-id。

[mysqld]
server-id = 2

連接Slave到Master

在Master和Slave都配置好后，只需要把slave只想master即可

change master to master_host='10.1.6.159',master_port=3306,master_user='rep',
master_password='123456';
start slave;

接下來在master上做一些針對改變數(shù)據(jù)庫的操作，來觀察slave的變化情況。在修改完my.cnf配置重啟數(shù)據(jù)庫后，就開始記錄binlog了?？梢栽?var/log/mysql目錄下看到一個mysql-bin.000001文件，而且還有一個mysql-bin.index文件，這個mysql-bin.index文件是什么？這個文件保存了所有的binlog文件列表，但是我們在配置文件中并沒有設(shè)置改值，這個可以通過log_bin_index進行設(shè)置，如果沒有設(shè)置改值，則默認值和log_bin一樣。在master上執(zhí)行show binlog events命令，可以看到第一個binlog文件的內(nèi)容。

注意：上面的sql語句是從頭開始復(fù)制第一個binlog，如果想從某個位置開始復(fù)制binlog，就需要在change master to時指定要開始的binlog文件名和語句在文件中的起點位置，參數(shù)如下：master_log_file和master_log_pos。

mysql> show binlog events\G
*************************** 1. row ***************************
   Log_name: mysql-bin.000001
        Pos: 4
 Event_type: Format_desc
  Server_id: 1
End_log_pos: 107
       Info: Server ver: 5.5.28-0ubuntu0.12.10.2-log, Binlog ver: 4
*************************** 2. row ***************************
   Log_name: mysql-bin.000001
        Pos: 107
 Event_type: Query
  Server_id: 1
End_log_pos: 181
       Info: create user rep
*************************** 3. row ***************************
   Log_name: mysql-bin.000001
        Pos: 181
 Event_type: Query
  Server_id: 1
End_log_pos: 316
       Info: grant replication slave on *.* to rep identified by '123456'
3 rows in set (0.00 sec)

• Log_name 是二進制日志文件的名稱，一個事件不能橫跨兩個文件

• Pos 這是該事件在文件中的開始位置

• Event_type 事件的類型，事件類型是給slave傳遞信息的基本方法，每個新的binlog都已Format_desc類型開始，以Rotate類型結(jié)束

• Server_id 創(chuàng)建該事件的服務(wù)器id

• End_log_pos 該事件的結(jié)束位置，也是下一個事件的開始位置，因此事件范圍為Pos~End_log_pos-1

• Info 事件信息的可讀文本，不同的事件有不同的信息

示例

在master的test庫中創(chuàng)建一個rep表，并插入一條記錄。

create table rep(name var);
insert into rep values ("guol");
flush logs;

flush logs命令強制輪轉(zhuǎn)日志，生成一個新的二進制日志，可以通過show binlog events in 'xxx'來查看該二進制日志。可以通過show master status查看當(dāng)前正在寫入的binlog文件。這樣就會在slave上執(zhí)行相應(yīng)的改變操作。

上面就是最簡單的主從復(fù)制模式，不過有時候隨著時間的推進，binlog會變得非常龐大，如果新增加一臺slave，從頭開始復(fù)制master的binlog文件是非常耗時的，所以我們可以從一個指定的位置開始復(fù)制binlog日志，可以通過其他方法把以前的binlog文件進行快速復(fù)制，例如copy物理文件。在change master to中有兩個參數(shù)可以實現(xiàn)該功能，master_log_file和master_log_pos，通過這兩個參數(shù)指定binlog文件及其位置。我們可以從master上復(fù)制也可以從slave上復(fù)制，假如我們是從master上復(fù)制，具體操作過程如下：

（1）為了防止在操作過程中數(shù)據(jù)更新，導(dǎo)致數(shù)據(jù)不一致，所以需要先刷新數(shù)據(jù)并鎖定數(shù)據(jù)庫：flush tables with read lock。

（2）檢查當(dāng)前的binlog文件及其位置：show master status。

mysql> show master status\G
*************************** 1. row ***************************
File: mysql-bin.000003
Position: 107
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)

（3）通過mysqldump命令創(chuàng)建數(shù)據(jù)庫的邏輯備分：mysqldump --all-databases -hlocalhost -p >back.sql。

（4）有了master的邏輯備份后，對數(shù)據(jù)庫進行解鎖：unlock tables。

（5）把back.sql復(fù)制到新的slave上，執(zhí)行：mysql -hlocalhost -p 把master的邏輯備份插入slave的數(shù)據(jù)庫中。

（6）現(xiàn)在可以把新的slave連接到master上了，只需要在change master to中多設(shè)置兩個參數(shù)master_log_file='mysql-bin.000003'和master_log_pos='107'即可，然后啟動slave：start slave，這樣slave就可以接著107的位置進行復(fù)制了。

change master to master_host='10.1.6.159',master_port=3306,master_user='rep',
master_password='123456',master_log_file='mysql-bin.000003',master_log_pos='107';
start slave;

有時候master并不能讓你鎖住表進行復(fù)制，因為可能跑一些不間斷的服務(wù)，如果這時master已經(jīng)有了一個slave，我們則可以通過這個slave進行再次擴展一個新的slave。原理同在master上進行復(fù)制差不多，關(guān)鍵在于找到binlog的位置，你在復(fù)制的同時可能該slave也在和master進行同步，操作如下：

（1）為了防止數(shù)據(jù)變動，還是需要停止slave的同步：stop slave。

（2）然后刷新表，并用mysqldump邏輯備份數(shù)據(jù)庫。

（3）使用show slave status查看slave的相關(guān)信息，記錄下兩個字段的值Relay_Master_Log_File和Exec_Master_Log_Pos，這個用來確定從后面哪里開始復(fù)制。

（4）對slave解鎖，把備份的邏輯數(shù)據(jù)庫導(dǎo)入新的slave的數(shù)據(jù)庫中，然后設(shè)置change master to，這一步和復(fù)制master一樣。

六、深入了解Mysql主從配置

1、一主多從

由一個master和一個slave組成復(fù)制系統(tǒng)是最簡單的情況。Slave之間并不相互通信，只能與master進行通信。在實際應(yīng)用場景中，MySQL復(fù)制90%以上都是一個Master復(fù)制到一個或者多個Slave的架構(gòu)模式，主要用于讀壓力比較大的應(yīng)用的數(shù)據(jù)庫端廉價擴展解決方案。

在上圖中，是我們開始時提到的一主多從的情況，這時主庫既要負責(zé)寫又要負責(zé)為幾個從庫提供二進制日志。這種情況將二進制日志只給某一從，這一從再開啟二進制日志并將自己的二進制日志再發(fā)給其它從，或者是干脆這個從不記錄只負責(zé)將二進制日志轉(zhuǎn)發(fā)給其它從，這樣架構(gòu)起來性能可能要好得多，而且數(shù)據(jù)之間的延時應(yīng)該也稍微要好一些。PS：這些前面都寫過了，又復(fù)制了一遍。

2、主主復(fù)制

上圖中，Master-Master復(fù)制的兩臺服務(wù)器，既是master，又是另一臺服務(wù)器的slave。這樣，任何一方所做的變更，都會通過復(fù)制應(yīng)用到另外一方的數(shù)據(jù)庫中。在這種復(fù)制架構(gòu)中，各自上運行的不是同一db，比如左邊的是db1,右邊的是db2，db1的從在右邊反之db2的從在左邊，兩者互為主從，再輔助一些監(jiān)控的服務(wù)還可以實現(xiàn)一定程度上的高可以用。

3、主動—被動模式的Master-Master(Master-Master in Active-Passive Mode)

上圖中，這是由master-master結(jié)構(gòu)變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統(tǒng)。它的不同點在于其中只有一個節(jié)點在提供讀寫服務(wù)，另外一個節(jié)點時刻準(zhǔn)備著，當(dāng)主節(jié)點一旦故障馬上接替服務(wù)。比如通過corosync+pacemaker+drbd+MySQL就可以提供這樣一組高可用服務(wù)，主備模式下再跟著slave服務(wù)器，也可以實現(xiàn)讀寫分離。

4、帶從服務(wù)器的Master-Master結(jié)構(gòu)(Master-Master with Slaves)

這種結(jié)構(gòu)的優(yōu)點就是提供了冗余。在地理上分布的復(fù)制結(jié)構(gòu)，它不存在單一節(jié)點故障問題，而且還可以將讀密集型的請求放到slave上。

5、MySQL-5.5支持半同步復(fù)制

早前的MySQL復(fù)制只能是基于異步來實現(xiàn)，從MySQL-5.5開始，支持半自動復(fù)制。在以前的異步（asynchronous）復(fù)制中，主庫在執(zhí)行完一些事務(wù)后，是不會管備庫的進度的。如果備庫處于落后，而更不幸的是主庫此時又出現(xiàn)Crash（例如宕機），這時備庫中的數(shù)據(jù)就是不完整的。簡而言之，在主庫發(fā)生故障的時候，我們無法使用備庫來繼續(xù)提供數(shù)據(jù)一致的服務(wù)了。Semisynchronous Replication(半同步復(fù)制)則一定程度上保證提交的事務(wù)已經(jīng)傳給了至少一個備庫。Semi synchronous中，僅僅保證事務(wù)的已經(jīng)傳遞到備庫上，但是并不確保已經(jīng)在備庫上執(zhí)行完成了。

此外，還有一種情況會導(dǎo)致主備數(shù)據(jù)不一致。在某個session中，主庫上提交一個事務(wù)后，會等待事務(wù)傳遞給至少一個備庫，如果在這個等待過程中主庫Crash，那么也可能備庫和主庫不一致，這是很致命的。如果主備網(wǎng)絡(luò)故障或者備庫掛了，主庫在事務(wù)提交后等待10秒（rpl_semi_sync_master_timeout的默認值）后，就會繼續(xù)。這時，主庫就會變回原來的異步狀態(tài)。

MySQL在加載并開啟Semi-sync插件后，每一個事務(wù)需等待備庫接收日志后才返回給客戶端。如果做的是小事務(wù)，兩臺主機的延遲又較小，則Semi-sync可以實現(xiàn)在性能很小損失的情況下的零數(shù)據(jù)丟失。

看完了這篇文章，相信你對MySql主從復(fù)制是什么有了一定的了解，想了解更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)站欄目：MySql主從復(fù)制是什么
本文路徑：http://aaarwkj.com/article14/gppsge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、動態(tài)網(wǎng)站、網(wǎng)站設(shè)計公司、用戶體驗、定制開發(fā)、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)