Mysql數據庫主從配置及原理

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

相關文章
相關標籤/搜索