溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下MySql主從復制是什么，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！
MySQL主從復制是其最重要的功能之一。主從復制是指一臺服務器充當主數據庫服務器，另一臺或多臺服務器充當從數據庫服務器，主服務器中的數據自動復制到從服務器之中。對于多級復制，數據庫服務器即可充當主機，也可充當從機。MySQL主從復制的基礎是主服務器對數據庫修改記錄二進制日志，從服務器通過主服務器的二進制日志自動執行更新。
主服務器上面執行的語句在從服務器上面再執行一遍，在MySQL-3.23版本以后支持。
存在的問題：時間上可能不完全同步造成偏差，執行語句的用戶也可能是不同一個用戶。
把主服務器上面改編后的內容直接復制過去，而不關心到底改變該內容是由哪條語句引發的，在MySQL-5.0版本以后引入。
存在的問題：比如一個工資表中有一萬個用戶，我們把每個用戶的工資+1000，那么基于行的復制則要復制一萬行的內容，由此造成的開銷比較大，而基于語句的復制僅僅一條語句就可以了。
MySQL默認使用基于語句的復制，當基于語句的復制會引發問題的時候就會使用基于行的復制，MySQL會自動進行選擇。
在MySQL主從復制架構中，讀操作可以在所有的服務器上面進行，而寫操作只能在主服務器上面進行。主從復制架構雖然給讀操作提供了擴展，可如果寫操作也比較多的話（多臺從服務器還要從主服務器上面同步數據），單主模型的復制中主服務器勢必會成為性能瓶頸。
1、基于語句的復制：主服務器上面執行的語句在從服務器上面再執行一遍，在MySQL-3.23版本以后支持。
存在的問題：時間上可能不完全同步造成偏差，執行語句的用戶也可能是不同一個用戶。
2、基于行的復制：把主服務器上面改編后的內容直接復制過去，而不關心到底改變該內容是由哪條語句引發的，在MySQL-5.0版本以后引入。
存在的問題：比如一個工資表中有一萬個用戶，我們把每個用戶的工資+1000，那么基于行的復制則要復制一萬行的內容，由此造成的開銷比較大，而基于語句的復制僅僅一條語句就可以了。
3、混合類型的復制：MySQL默認使用基于語句的復制，當基于語句的復制會引發問題的時候就會使用基于行的復制，MySQL會自動進行選擇。
在MySQL主從復制架構中，讀操作可以在所有的服務器上面進行，而寫操作只能在主服務器上面進行。主從復制架構雖然給讀操作提供了擴展，可如果寫操作也比較多的話（多臺從服務器還要從主服務器上面同步數據），單主模型的復制中主服務器勢必會成為性能瓶頸。
三 MySQL主從復制工作原理
如下圖所示：
主服務器上面的任何修改都會保存在二進制日志Binary log里面，從服務器上面啟動一個I/O thread（實際上就是一個主服務器的客戶端進程），連接到主服務器上面請求讀取二進制日志，然后把讀取到的二進制日志寫到本地的一個Realy log里面。從服務器上面開啟一個SQL thread定時檢查Realy log，如果發現有更改立即把更改的內容在本機上面執行一遍。
如果一主多從的話，這時主庫既要負責寫又要負責為幾個從庫提供二進制日志。此時可以稍做調整，將二進制日志只給某一從，這一從再開啟二進制日志并將自己的二進制日志再發給其它從。或者是干脆這個從不記錄只負責將二進制日志轉發給其它從，這樣架構起來性能可能要好得多，而且數據之間的延時應該也稍微要好一些。工作原理圖如下：
實際上在老版本的MySQL主從復制中Slave端并不是兩個進程完成的，而是由一個進程完成。但是后來發現這樣做存在較大的風險和性能問題，主要如下：
首先，一個進程會使復制bin-log日志和解析日志并在自身執行的過程成為一個串行的過程，性能受到了一定的限制，異步復制的延遲也會比較長。
另外，Slave端從Master端獲取bin-log過來之后，需要接著解析日志內容，然后在自身執行。在這個過程中，Master端可能又產生了大量變化并新增了大量的日志。如果在這個階段Master端的存儲出現了無法修復的錯誤，那么在這個階段所產生的所有變更都將永遠無法找回。如果在Slave端的壓力比較大的時候，這個過程的時間可能會比較長。
為了提高復制的性能并解決存在的風險，后面版本的MySQL將Slave端的復制動作交由兩個進程來完成。提出這個改進方案的人是Yahoo!的一位工程師“Jeremy Zawodny”。這樣既解決了性能問題，又縮短了異步的延時時間，同時也減少了可能存在的數據丟失量。
當然，即使是換成了現在這樣兩個線程處理以后，同樣也還是存在slave數據延時以及數據丟失的可能性的，畢竟這個復制是異步的。只要數據的更改不是在一個事物中，這些問題都是會存在的。如果要完全避免這些問題，就只能用MySQL的cluster來解決了。不過MySQL的cluster是內存數據庫的解決方案，需要將所有數據都load到內存中，這樣就對內存的要求就非常大了，對于一般的應用來說可實施性不是太大。
還有一點要提的是MySQL的復制過濾(Replication Filters)，復制過濾可以讓你只復制服務器中的一部分數據。有兩種復制過濾：在Master上過濾二進制日志中的事件；在Slave上過濾中繼日志中的事件。如下：
配置Master的my.cnf文件(關鍵性的配置)/etc/my.cnf
log-bin=mysql-bin server-id = 1 binlog-do-db=icinga binlog-do-db=DB2 //如果備份多個數據庫，重復設置這個選項即可 binlog-do-db=DB3 //需要同步的數據庫，如果沒有本行，即表示同步所有的數據庫 binlog-ignore-db=mysql //被忽略的數據庫 配置Slave的my.cnf文件(關鍵性的配置)/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 //需要同步的數據庫，如果沒有本行，即表示同步所有的數據庫 replicate-ignore-db=mysql //被忽略的數據庫
網友說replicate-do-db的使用中可能會出些問題（http://blog.knowsky.com/19696...），自己沒有親自去測試。猜想binlog-do-db參數用于主服務器中，通過過濾Binary Log來過濾掉配置文件中不允許復制的數據庫，也就是不向Binary Log中寫入不允許復制數據的操作日志；而replicate-do-db用于從服務器中，通過過濾Relay Log來過濾掉不允許復制的數據庫或表，也就是執行Relay Log中的動作時不執行那些不被允許的修改動作。這樣的話，多個從數據庫服務器的情況：有的從服務器既從主服務器中復制數據，又做為主服務器向另外的從服務器復制數據，那它的配置文件中應該可以同時存在binlog-do-db、replicate-do-db這兩個參數才對。一切都是自己的預測，關于binlog-do-db、replicate-do-db的具體使用方法還得在實際開發中一點點摸索才可以。
網上有說，復制時忽略某些數據庫或者表的操作最好不要在主服務器上面進行，因為主服務器忽略之后就不會再往二進制文件中寫了，但是在從服務器上面雖然忽略了某些數據庫但是主服務器上面的這些操作信息依然會被復制到從服務器上面的relay log里面，只是不會在從服務器上面執行而已。我想這個意思應該是建議在從服務器中設置replicate-do-db，而不要在主服務器上設置binlog-do-db。
另外，不管是黑名單（binlog-ignore-db、replicate-ignore-db）還是白名單（binlog-do-db、replicate-do-db）只寫一個就行了，如果同時使用那么只有白名單生效。
MySQL主從復制的兩種情況：同步復制和異步復制，實際復制架構中大部分為異步復制。
復制的基本過程如下：
Slave上面的IO進程連接上Master，并請求從指定日志文件的指定位置（或者從最開始的日志）之后的日志內容。
Master接收到來自Slave的IO進程的請求后，負責復制的IO進程會根據請求信息讀取日志指定位置之后的日志信息，返回給Slave的IO進程。返回信息中除了日志所包含的信息之外，還包括本次返回的信息已經到Master端的bin-log文件的名稱以及bin-log的位置。
Slave的IO進程接收到信息后，將接收到的日志內容依次添加到Slave端的relay-log文件的最末端，并將讀取到的Master端的 bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候能夠清楚的告訴Master“我需要從某個bin-log的哪個位置開始往后的日志內容，請發給我”。
Slave的Sql進程檢測到relay-log中新增加了內容后，會馬上解析relay-log的內容成為在Master端真實執行時候的那些可執行的內容，并在自身執行。
復制通常用來創建主節點的副本，通過添加冗余節點來保證高可用性，當然復制也可以用于其他用途，例如在從節點上進行數據讀、分析等等。在橫向擴展的業務中，復制很容易實施，主要表現在在利用主節點進行寫操作，多個從節點進行讀操作，MySQL復制的異步性是指：事物首先在主節點上提交，然后復制給從節點并在從節點上應用，這樣意味著在同一個時間點主從上的數據可能不一致。異步復制的好處在于它比同步復制要快，如果對數據的一致性要求很高，還是采用同步復制較好。
最簡單的復制模式就是一主一從的復制模式了，這樣一個簡單的架構只需要三個步驟即可完成：
（1）建立一個主節點，開啟binlog，設置服務器id；
（2）建立一個從節點，設置服務器id；
（3）將從節點連接到主節點上。
下面我們開始操作，以MySQL 5.5為例，操作系統Ubuntu12.10，Master 10.1.6.159 Slave 10.1.6.191。
apt-get install mysql-server
Master上面開啟binlog日志，并且設置一個唯一的服務器id，在局域網內這個id必須唯一。二進制的binlog日志記錄master上的所有數據庫改變，這個日志會被復制到從節點上，并且在從節點上回放。修改my.cnf文件，在mysqld模塊下修改如下內容：
[mysqld] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log
log_bin設置二進制日志所產生文件的基本名稱，二進制日志由一系列文件組成，log_bin的值是可選項，如果沒有為log_bin設置值，則默認值是：主機名-bin。如果隨便修改主機名，則binlog日志的名稱也會被改變的。server-id是用來唯一標識一個服務器的，每個服務器的server-id都不一樣。這樣slave連接到master后，會請求master將所有的binlog傳遞給它，然后將這些binlog在slave上回放。為了防止權限混亂，一般都是建立一個單獨用于復制的賬戶。
binlog是復制過程的關鍵，它記錄了數據庫的所有改變，通常即將執行完畢的語句會在binlog日志的末尾寫入一條記錄，binlog只記錄改變數據庫的語句，對于不改變數據庫的語句則不進行記錄。這種情況叫做基于語句的復制，前面提到過還有一種情況是基于行的復制，兩種模式各有各的優缺點。
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上做一些針對改變數據庫的操作，來觀察slave的變化情況。在修改完my.cnf配置重啟數據庫后，就開始記錄binlog了。可以在/var/log/mysql目錄下看到一個mysql-bin.000001文件，而且還有一個mysql-bin.index文件，這個mysql-bin.index文件是什么？這個文件保存了所有的binlog文件列表，但是我們在配置文件中并沒有設置改值，這個可以通過log_bin_index進行設置，如果沒有設置改值，則默認值和log_bin一樣。在master上執行show binlog events命令，可以看到第一個binlog文件的內容。
注意：上面的sql語句是從頭開始復制第一個binlog，如果想從某個位置開始復制binlog，就需要在change master to時指定要開始的binlog文件名和語句在文件中的起點位置，參數如下：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類型結束
Server_id 創建該事件的服務器id
End_log_pos 該事件的結束位置，也是下一個事件的開始位置，因此事件范圍為Pos~End_log_pos-1
Info 事件信息的可讀文本，不同的事件有不同的信息
示例
在master的test庫中創建一個rep表，并插入一條記錄。
create table rep(name var);
insert into rep values ("guol");
flush logs;flush logs命令強制輪轉日志，生成一個新的二進制日志，可以通過show binlog events in 'xxx'來查看該二進制日志。可以通過show master status查看當前正在寫入的binlog文件。這樣就會在slave上執行相應的改變操作。
上面就是最簡單的主從復制模式，不過有時候隨著時間的推進，binlog會變得非常龐大，如果新增加一臺slave，從頭開始復制master的binlog文件是非常耗時的，所以我們可以從一個指定的位置開始復制binlog日志，可以通過其他方法把以前的binlog文件進行快速復制，例如copy物理文件。在change master to中有兩個參數可以實現該功能，master_log_file和master_log_pos，通過這兩個參數指定binlog文件及其位置。我們可以從master上復制也可以從slave上復制，假如我們是從master上復制，具體操作過程如下：
（1）為了防止在操作過程中數據更新，導致數據不一致，所以需要先刷新數據并鎖定數據庫：flush tables with read lock。
（2）檢查當前的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命令創建數據庫的邏輯備分：mysqldump --all-databases -hlocalhost -p >back.sql。
（4）有了master的邏輯備份后，對數據庫進行解鎖：unlock tables。
（5）把back.sql復制到新的slave上，執行：mysql -hlocalhost -p 把master的邏輯備份插入slave的數據庫中。
（6）現在可以把新的slave連接到master上了，只需要在change master to中多設置兩個參數master_log_file='mysql-bin.000003'和master_log_pos='107'即可，然后啟動slave：start slave，這樣slave就可以接著107的位置進行復制了。
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并不能讓你鎖住表進行復制，因為可能跑一些不間斷的服務，如果這時master已經有了一個slave，我們則可以通過這個slave進行再次擴展一個新的slave。原理同在master上進行復制差不多，關鍵在于找到binlog的位置，你在復制的同時可能該slave也在和master進行同步，操作如下：
（1）為了防止數據變動，還是需要停止slave的同步：stop slave。
（2）然后刷新表，并用mysqldump邏輯備份數據庫。
（3）使用show slave status查看slave的相關信息，記錄下兩個字段的值Relay_Master_Log_File和Exec_Master_Log_Pos，這個用來確定從后面哪里開始復制。
（4）對slave解鎖，把備份的邏輯數據庫導入新的slave的數據庫中，然后設置change master to，這一步和復制master一樣。
由一個master和一個slave組成復制系統是最簡單的情況。Slave之間并不相互通信，只能與master進行通信。在實際應用場景中，MySQL復制90%以上都是一個Master復制到一個或者多個Slave的架構模式，主要用于讀壓力比較大的應用的數據庫端廉價擴展解決方案。
在上圖中，是我們開始時提到的一主多從的情況，這時主庫既要負責寫又要負責為幾個從庫提供二進制日志。這種情況將二進制日志只給某一從，這一從再開啟二進制日志并將自己的二進制日志再發給其它從，或者是干脆這個從不記錄只負責將二進制日志轉發給其它從，這樣架構起來性能可能要好得多，而且數據之間的延時應該也稍微要好一些。PS：這些前面都寫過了，又復制了一遍。
上圖中，Master-Master復制的兩臺服務器，既是master，又是另一臺服務器的slave。這樣，任何一方所做的變更，都會通過復制應用到另外一方的數據庫中。在這種復制架構中，各自上運行的不是同一db，比如左邊的是db1,右邊的是db2，db1的從在右邊反之db2的從在左邊，兩者互為主從，再輔助一些監控的服務還可以實現一定程度上的高可以用。
上圖中，這是由master-master結構變化而來的，它避免了M-M的缺點，實際上，這是一種具有容錯和高可用性的系統。它的不同點在于其中只有一個節點在提供讀寫服務，另外一個節點時刻準備著，當主節點一旦故障馬上接替服務。比如通過corosync+pacemaker+drbd+MySQL就可以提供這樣一組高可用服務，主備模式下再跟著slave服務器，也可以實現讀寫分離。
這種結構的優點就是提供了冗余。在地理上分布的復制結構，它不存在單一節點故障問題，而且還可以將讀密集型的請求放到slave上。
早前的MySQL復制只能是基于異步來實現，從MySQL-5.5開始，支持半自動復制。在以前的異步（asynchronous）復制中，主庫在執行完一些事務后，是不會管備庫的進度的。如果備庫處于落后，而更不幸的是主庫此時又出現Crash（例如宕機），這時備庫中的數據就是不完整的。簡而言之，在主庫發生故障的時候，我們無法使用備庫來繼續提供數據一致的服務了。Semisynchronous Replication(半同步復制)則一定程度上保證提交的事務已經傳給了至少一個備庫。Semi synchronous中，僅僅保證事務的已經傳遞到備庫上，但是并不確保已經在備庫上執行完成了。
此外，還有一種情況會導致主備數據不一致。在某個session中，主庫上提交一個事務后，會等待事務傳遞給至少一個備庫，如果在這個等待過程中主庫Crash，那么也可能備庫和主庫不一致，這是很致命的。如果主備網絡故障或者備庫掛了，主庫在事務提交后等待10秒（rpl_semi_sync_master_timeout的默認值）后，就會繼續。這時，主庫就會變回原來的異步狀態。
MySQL在加載并開啟Semi-sync插件后，每一個事務需等待備庫接收日志后才返回給客戶端。如果做的是小事務，兩臺主機的延遲又較小，則Semi-sync可以實現在性能很小損失的情況下的零數據丟失。
看完了這篇文章，相信你對MySql主從復制是什么有了一定的了解，想了解更多相關知識，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
