1、mysql主從的原理mysql
一、Replication 線程sql
Mysql的 Replication 是一個異步的複製過程(mysql5.1.7以上版本分爲異步複製和半同步兩種模式),從一個 Mysql instace(咱們稱之爲 Master)複製到另外一個 Mysql instance(咱們稱之 Slave)。在 Master 與 Slave 之間的實現整個複製過程主要由三個線程來完成,其中兩個線程(Sql線程和IO線程)在 Slave 端,另一個線程(IO線程)在 Master 端。數據庫
要實現 MySQL 的 Replication ,首先必須打開 Master 端的Binary Log(mysql-bin.xxxxxx)功能,不然沒法實現。由於整個複製過程實際上就是Slave從Master端獲取該日誌而後再在本身身上徹底 順序的執行日誌中所記錄的各類操做。打開 MySQL 的 Binary Log 能夠經過在啓動 MySQL Server 的過程當中使用 「—log-bin」 參數選項,或者在 my.cnf 配置文件中的 mysqld 參數組([mysqld]標識後的參數部分)增長 「log-bin」 參數項。數組
二、MySQL 複製的基本過程以下:緩存
2.1.Slave 上面的IO線程鏈接上 Master,並請求從指定日誌文件的指定位置(或者從最開始的日誌)以後的日誌內容;安全
2.2. Master 接收到來自 Slave 的 IO 線程的請求後,經過負責複製的 IO 線程根據請求信息讀取指定日誌指定位置以後的日誌信息,返回給 Slave 端的 IO 線程。返回信息中除了日誌所包含的信息以外,還包括本次返回的信息在 Master 端的 Binary Log 文件的名稱以及在 Binary Log 中的位置;服務器
2.3. Slave 的 IO 線程接收到信息後,將接收到的日誌內容依次寫入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,並將讀取到的Master端的bin-log的文件名和位置記錄到master- info文件中,以便在下一次讀取的時候可以清楚的高速Master「我須要從某個bin-log的哪一個位置開始日後的日誌內容,請發給我」網絡
2.4. Slave 的 SQL 線程檢測到 Relay Log 中新增長了內容後,會立刻解析該 Log 文件中的內容成爲在 Master 端真實執行時候的那些可執行的 Query 語句,並在自身執行這些 Query。這樣,實際上就是在 Master 端和 Slave 端執行了一樣的 Query,因此兩端的數據是徹底同樣的。多線程
三、Mysql複製的幾種模式架構
3.1.從 MySQL 5.1.12 開始,能夠用如下三種模式來實現:
– 基於SQL語句的複製(statement-based replication, SBR),
– 基於行的複製(row-based replication, RBR),
– 混合模式複製(mixed-based replication, MBR)。
相應地,binlog的格式也有三種:STATEMENT,ROW,MIXED。 MBR 模式中,SBR 模式是默認的。
在運行時能夠動態改動 binlog的格式,除了如下幾種狀況:
1.存儲流程或者觸發器中間
2.啓用了NDB
3.當前會話試用 RBR 模式,而且已打開了臨時表
若是binlog採用了 MIXED 模式,那麼在如下幾種狀況下會自動將binlog的模式由 SBR 模式改爲 RBR 模式:
1.當DML語句更新一個NDB表時
2.當函數中包含 UUID() 時
3.2個及以上包含 AUTO_INCREMENT 字段的表被更新時
4.行任何 INSERT DELAYED 語句時
5.用 UDF 時
6.視圖中必需要求運用 RBR 時,例如創建視圖是運用了 UUID() 函數
3.2.設定主從複製模式:
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"
也能夠在運行時動態修改binlog的格式。例如
mysql> SET SESSION binlog_format = 'STATEMENT';
mysql> SET SESSION binlog_format = 'ROW';
mysql> SET SESSION binlog_format = 'MIXED';
mysql> SET GLOBAL binlog_format = 'STATEMENT';
mysql> SET GLOBAL binlog_format = 'ROW';
mysql> SET GLOBAL binlog_format = 'MIXED';
3.3.兩種模式各自的優缺點:
SBR 的優勢:
歷史悠久,技能成熟
binlog文件較小
binlog中包含了全部數據庫修改信息,能夠據此來審覈數據庫的安全等狀況
binlog能夠用於實時的還原,而不只僅用於複製
主從版本能夠不同,從服務器版本能夠比主服務器版本高
SBR 的缺點:
不是全部的UPDATE語句都能被複制,尤爲是包含不肯定操做的時候。
調用具備不肯定因素的 UDF 時複製也可能出疑問
運用如下函數的語句也不能被複制:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啓動時啓用了 –sysdate-is-now 選項)
INSERT … SELECT 會產生比 RBR 更多的行級鎖
複製需要執行 全表掃描(WHERE 語句中沒有運用到索引)的 UPDATE 時,需要比 RBR 請求更多的行級鎖
對於有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 語句會阻塞其餘 INSERT 語句
對於一些複雜的語句,在從服務器上的耗資源狀況會更嚴重,而 RBR 模式下,只會對那個發生變化的記錄產生影響
存儲函數(不是存儲流程 )在被調用的同時也會執行一次 NOW() 函數,這個能夠說是壞事也多是好事
肯定了的 UDF 也需要在從服務器上執行
數據表必須幾乎和主服務器保持一致才行,不然可能會致使複製出錯
執行復雜語句若是出錯的話,會消耗更多資源
RBR 的優勢:
任何狀況均可以被複制,這對複製來講是最安全可靠的
和其餘大多數數據庫系統的複製技能同樣
多數狀況下,從服務器上的表若是有主鍵的話,複製就會快了不少
複製如下幾種語句時的行鎖更少:
* INSERT … SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒有附帶條件或者並無修改不少記錄的 UPDATE 或 DELETE 語句
執行 INSERT,UPDATE,DELETE 語句時鎖更少
從服務器上採用多線程來執行復製成爲可能
RBR 的缺點:
binlog 大了不少
複雜的回滾時 binlog 中會包含大量的數據
主服務器上執行 UPDATE 語句時,全部發生變化的記錄都會寫到 binlog 中,而 SBR 只會寫一次,這會致使頻繁發生 binlog 的併發寫疑問
UDF 產生的大 BLOB 值會致使複製變慢
不能從 binlog 中看到都複製了寫什麼語句(加密過的)
當在非事務表上執行一段堆積的SQL語句時,最好採用 SBR 模式,不然很容易致使主從服務器的數據不一致狀況發生
另外,針對系統庫 mysql 裏面的表發生變化時的處理準則以下:
若是是採用 INSERT,UPDATE,DELETE 直接操做表的狀況,則日誌格式根據 binlog_format 的設定而記錄
若是是採用 GRANT,REVOKE,SET PASSWORD 等管理語句來作的話,那麼不管如何 都採用 SBR 模式記錄。
注:採用 RBR 模式後,能處理不少原先出現的主鍵重複問題。實例:
對於insert into db_allot_ids select * from db_allot_ids 這個語句:
在BINLOG_FORMAT=STATEMENT 模式下:
BINLOG日誌信息爲:
—————————————–
BEGIN
/*!*/;
# at 173
#090612 16:05:42 server id 1 end_log_pos 288 Query thread_id=4 exec_time=0 error_code=0
SET TIMESTAMP=1244793942/*!*/;
insert into db_allot_ids select * from db_allot_ids
/*!*/;
—————————————–
在BINLOG_FORMAT=ROW 模式下:
BINLOG日誌信息爲:
—————————————–
BINLOG '
hA0yShMBAAAAMwAAAOAAAAAAAA8AAAAAAAAAA1NOUwAMZGJfYWxsb3RfaWRzAAIBAwAA
hA0yShcBAAAANQAAABUBAAAQAA8AAAAAAAEAAv/8AQEAAAD8AQEAAAD8AQEAAAD8AQEAAAA=
'/*!*/;
—————————————–
四、Mysql主從的優缺點
MySQL的主從同步是一個很成熟的架構,優勢爲:①在從服務器能夠執行查詢工做(即咱們常說的讀功能),下降主服 務器壓力;②在從主服務器進行備份,避免備份期間影響主服務器服務;③當主服務器出現問題時,能夠切換到從服務器。因此我在項目部署和實施中常常會採用這種方案;鑑於生產環境下的mysql的嚴謹性。
實際上,在老版本中,MySQL 的複製實如今 Slave 端並非由 SQL 線程和 IO 線程這兩個線程共同協做而完成的,而是由單獨的一個線程來完成全部的工做。可是 MySQL 的工程師們很快發現,這樣作存在很大的風險和性能問題,主要以下:
首先,若是經過一個單一的線程來獨立實現這個工做的話,就使複製 Master 端的,Binary Log日誌,以及解析這些日誌,而後再在自身執行的這個過程成爲一個串行的過程,性能天然會受到較大的限制,這種架構下的 Replication 的延遲天然就比較長了。
其次,Slave 端的這個複製線程從 Master 端獲取 Binary Log 過來以後,須要接着解析這些內容,還原成 Master 端所執行的原始 Query,而後在自身執行。在這個過程當中,Master端極可能又已經產生了大量的變化並生成了大量的 Binary Log 信息。若是在這個階段 Master 端的存儲系統出現了沒法修復的故障,那麼在這個階段所產生的全部變動都將永遠的丟失,沒法再找回來。這種潛在風險在Slave 端壓力比較大的時候尤爲突出,由於若是 Slave 壓力比較大,解析日誌以及應用這些日誌所花費的時間天然就會更長一些,可能丟失的數據也就會更多。
因此,在後期的改造中,新版本的 MySQL 爲了儘可能減少這個風險,並提升複製的性能,將 Slave 端的複製改成兩個線程來完成,也就是前面所提到的 SQL 線程和 IO 線程。最先提出這個改進方案的是Yahoo!的一位工程師「Jeremy Zawodny」。經過這樣的改造,這樣既在很大程度上解決了性能問題,縮短了異步的延時時間,同時也減小了潛在的數據丟失量。
固然,即便是換成了如今這樣兩個線程來協做處理以後,一樣也仍是存在 Slave 數據延時以及數據丟失的可能性的,畢竟這個複製是異步的。只要數據的更改不是在一個事務中,這些問題都是存在的。
若是要徹底避免這些問題,就只能用 MySQL 的 Cluster 來解決了。不過 MySQL的 Cluster 知道筆者寫這部份內容的時候,仍然仍是一個內存數據庫的解決方案,也就是須要將全部數據包括索引所有都 Load 到內存中,這樣就對內存的要求就很是大的大,對於通常的大衆化應用來講可實施性並非太大。MySQL 如今正在不斷改進其 Cluster 的實現,其中很是大的一個改動就是容許數據不用所有 Load 到內存中,而僅僅只是索引所有 Load 到內存中,我想信在完成該項改造以後的 MySQL Cluster 將會更加受人歡迎,可實施性也會更大。
五、Mysql的半同步模式(Semisynchronous Replication)
咱們知道在5.5以前,MySQL的複製實際上是異步操做,而不是同步,也就意味着容許主從之間的數據存在必定的延遲,mysql當初這樣設計的目的可能也是基於可用性的考慮,爲了保證master不受slave的影響,而且異步複製使得master處於一種性能最優的狀態:寫完binlog後便可提交而不須要等待slave的操做完成。這樣存在一個隱患,當你使用slave做爲備份時,若是master掛掉,那麼會存在部分已提交的事務未能成功傳輸到slave的可能,這就意味着數據丟失!
在MySQL5.5版本中,引入了半同步複製模式(Semi-synchronous Replication)可以成功(只是相對的)避免上述數據丟失的隱患。在這種模式下:master會等到binlog成功傳送並寫入至少一個slave的relay log以後纔會提交,不然一直等待,直到timeout(默認10s)。當出現timeout的時候,master會自動切換半同步爲異步,直到至少有一個slave成功收到併發送Acknowledge,master會再切換回半同步模式。結合這個新功能,咱們能夠作到,在容許損失必定的事務吞吐量的前提下來保證同步數據的絕對安全,由於當你設置timeout爲一個足夠大的值的狀況下,任何提交的數據都會安全抵達slave。
mysql5.5 版本支持半同步複製功能(Semisynchronous Replication),但還不是原生的支持,是經過plugin來支持的,而且默認是沒有安裝這個插件的。不管是二進制發佈的,仍是本身源代碼編譯的,都會默認生成這個插件,一個是針對master 的一個是針對slave的,在使用以前須要先安裝這倆plugins。
2、Mysql主從複製的過濾
複製的過濾主要有2種方式:
一、在主服務器在把事件從進二制日誌中過濾掉,相關的參數是:binlog_do_db和binlog_ignore_db。
二、在從服務器上把事件從中繼日誌中過濾掉,相關的參數是replicate_*。
複製只能擴展讀取,不能擴展寫入,對數據進行分區能夠進行擴展寫入。
複製的優化:
在mysql複製環境中,有8個參數可讓咱們控制,須要複製或須要忽略不進行復制的DB或table分別爲:
下面二項須要在Master上設置:
Binlog_Do_DB:設定哪些數據庫須要記錄Binlog
Binlog_Ignore_DB:設定哪裏數據庫不須要記錄Binlog
優勢是Master端的Binlog記錄所帶來的Io量減小,網絡IO減小,還會讓slave端的IO線程,SQL線程減小,從而大幅提升複製性能,
缺點是mysql判斷是否須要複製某個事件不是根據產生該事件的查詢所在的DB,而是根據執行查詢時刻所在的默認數據庫(也就是登陸時指定的庫名或運行"use database"中指定的DB),只有當前默認DB和配置中所設定的DB徹底吻合時IO線程纔會將該事件讀取給slave的IO線程.因此,若是在默認DB和設定需要複製的DB不同的狀況下改變了需要複製的DB中某個Table中的數據,該事件是不會被複制到Slave中去的,這樣就會形成Slave端的數據和Master的數據不一致.一樣,在默認的數據庫下更改了不需要複製的數據庫中的數據,則會被複制到slave端,當slave端並無該數據庫時,則會形成複製出錯而中止。
下面六項須要在slave上設置:
Replicate_Do_DB:設定須要複製的數據庫,多個DB用逗號分隔
Replicate_Ignore_DB:設定能夠忽略的數據庫.
Replicate_Do_Table:設定須要複製的Table
Replicate_Ignore_Table:設定能夠忽略的Table
Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但能夠帶通配符來進行設置。
Replicate_Wild_Ignore_Table:功能同Replicate_Do_Table,功能同Replicate_Ignore_Table,能夠帶通配符。
優勢是在slave端設置複製過濾機制,能夠保證不會出現由於默認的數據庫問題而形成Slave和Master數據不一致或複製出錯的問題.
缺點是性能方面比在Master端差一些.緣由在於:無論是否需要複製,事件都會被IO線程讀取到Slave端,這樣不只增長了網絡IO量,也給Slave端的IO線程增長了Relay Log的寫入量。
注:在實際的生產應用中發現,在mysql5.0之前的版本,mysql的這個過濾設置幾乎是形同虛設,不起做用:無論你在主庫或是從庫上設置了忽略某個數據庫或是表,他依然會進行同步,因此在作5.0之前版本的主從同步時,必定保持主從數據庫的一致性,主上有的庫或是表從上必定要有,不然在同步的過程會出錯。
3、Mysql主從同步的配置
主庫IP:192.168.1.2
從庫IP:192.168.1.3
添加一個用於主從同步的用戶:
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY ‘1q2w3e4r’;
若是監控mysql主從的話,請加上一個super權限:
GRANT SUPER, REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY '1q2w3e4r';
一、主庫的配置
1.1.mysql5.0如下版本的配置
修改主庫mysql配置配置文件,在[mysqld]段添加如下內容:
server-id = 1
log-bin=/home/mysql/logs/binlog/bin-log
max_binlog_size = 500M
binlog_cache_size = 128K
binlog-do-db = adb
binlog-ignore-db = mysql
log-slave-updates
1.2. mysql5.0以上版本的配置
修改主庫mysql配置配置文件,在[mysqld]段添加如下內容:
server-id = 1
log-bin=/home/mysql/logs/binlog/bin-log
max_binlog_size = 500M
binlog_cache_size = 128K
binlog-do-db = adb
binlog-ignore-db = mysql
log-slave-updates
expire_logs_day=2
binlog_format="MIXED"
1.3.各個參數的含義和相關注意項:
server-id = 1 #服務器標誌號,注意在配置文件中不能出現多個這樣的標識,若是出現多個的話mysql以第一個爲準,一組主從中此標識號不能重複。
log-bin=/home/mysql/logs/binlog/bin-log #開啓bin-log,並指定文件目錄和文件名前綴。
max_binlog_size = 500M #每一個bin-log最大大小,當此大小等於500M時會自動生成一個新的日誌文件。一條記錄不會寫在2個日誌文件中,因此有時日誌文件會超過此大小。
binlog_cache_size = 128K #日誌緩存大小
binlog-do-db = adb #須要同步的數據庫名字,若是是多個,就以此格式在寫一行便可。
binlog-ignore-db = mysql #不須要同步的數據庫名字,若是是多個,就以此格式在寫一行便可。
log-slave-updates #當Slave從Master數據庫讀取日誌時更新新寫入日誌中,若是隻啓動log-bin 而沒有啓動log-slave-updates則Slave只記錄針對本身數據庫操做的更新。
expire_logs_day=2 #設置bin-log日誌文件保存的天數,此參數mysql5.0如下版本不支持。
binlog_format="MIXED" #設置bin-log日誌文件格式爲:MIXED,能夠防止主鍵重複。
二、從庫的配置
2.1.mysql5.1.7之前版本
修改從庫mysql配置配置文件,在[mysqld]段添加如下內容:
server-id=2
master-host=192.168.1.2
master-user=repl
master-password=1q2w3e4r
master-port=3306
master-connect-retry=30
slave-skip-errors=1062
replicate-do-db = adb
replicate-ignore-db = mysql