[MySQL5.1體驗]MySQL復(fù)制
來源:懂視網(wǎng)
責(zé)編:小采
時間:2020-11-09 15:39:36
[MySQL5.1體驗]MySQL復(fù)制
[MySQL5.1體驗]MySQL復(fù)制:作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下
導(dǎo)讀[MySQL5.1體驗]MySQL復(fù)制:作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下
作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下三種模式來實
作/譯者:葉金榮(Email:
),來源:http://imysql.cn
MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前
的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下三種模式來實現(xiàn):基于SQL語句的復(fù)制(statement-based replication, SBR),基于行的復(fù)制(row-based replication, RBR),混合模式復(fù)制(mixed-based replication, MBR)。相應(yīng)地,binlog的格式也有三種:STATEMENT,ROW,MIXED。MBR 模式中,SBR 模式是默認(rèn)的。
在運行時可以動態(tài)低改變binlog的格式,除了以下幾種情況:
存儲過程或者觸發(fā)器中間
啟用了NDB
當(dāng)前會話試用 RBR 模式,并且已打開了臨時表
如果binlog采用了 MIXED 模式,那么在以下幾種情況下會自動將binlog的模式由 SBR 模式改成 RBR 模式。
當(dāng)DML語句更新一個NDB表時
當(dāng)函數(shù)中包含 UUID() 時
2個及以上包含 AUTO_INCREMENT 字段的表被更新時
行任何 INSERT DELAYED 語句時
用 UDF 時
視圖中必須要求使用 RBR 時,例如創(chuàng)建視圖是使用了 UUID() 函數(shù)
設(shè)定主從復(fù)制模式的方法非常簡單,只要在以前設(shè)定復(fù)制配置的基礎(chǔ)上,再加一個參數(shù):
binlog_format="STATEMENT"
#binlog_format="ROW"
#binlog_format="MIXED"
當(dāng)然了,也可以在運行時動態(tài)修改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';
現(xiàn)在來比較以下 SBR 和 RBR 2中模式各自的優(yōu)缺點:
SBR 的優(yōu)點:
歷史悠久,技術(shù)成熟
binlog文件較小
binlog中包含了所有數(shù)據(jù)庫更改信息,可以據(jù)此來審核數(shù)據(jù)庫的安全等情況
binlog可以用于實時的還原,而不僅僅用于復(fù)制
主從版本可以不一樣,從服務(wù)器版本可以比主服務(wù)器版本高
SBR 的缺點:
不是所有的UPDATE語句都能被復(fù)制,尤其是包含不確定操作的時候。
調(diào)用具有不確定因素的 UDF 時復(fù)制也可能出問題
使用以下函數(shù)的語句也無法被復(fù)制:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非啟動時啟用了 --sysdate-is-now 選項)
INSERT ... SELECT 會產(chǎn)生比 RBR 更多的行級鎖
復(fù)制需要進(jìn)行全表掃描(WHERE 語句中沒有使用到索引)的 UPDATE 時,需要比 RBR 請求更多的行級鎖
對于有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 語句會阻塞其他 INSERT 語句
對于一些復(fù)雜的語句,在從服務(wù)器上的耗資源情況會更嚴(yán)重,而 RBR 模式下,只會對那個發(fā)生變化的記錄產(chǎn)生影響
存儲函數(shù)(不是存儲過程)在被調(diào)用的同時也會執(zhí)行一次 NOW() 函數(shù),這個可以說是壞事也可能是好事
確定了的 UDF 也需要在從服務(wù)器上執(zhí)行
數(shù)據(jù)表必須幾乎和主服務(wù)器保持一致才行,否則可能會導(dǎo)致復(fù)制出錯
執(zhí)行復(fù)雜語句如果出錯的話,會消耗更多資源
RBR 的優(yōu)點:
任何情況都可以被復(fù)制,這對復(fù)制來說是最安全可靠的
和其他大多數(shù)數(shù)據(jù)庫系統(tǒng)的復(fù)制技術(shù)一樣
多數(shù)情況下,從服務(wù)器上的表如果有主鍵的話,復(fù)制就會快了很多
復(fù)制以下幾種語句時的行鎖更少:
* INSERT ... SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 沒有附帶條件或者并沒有修改很多記錄的 UPDATE 或 DELETE 語句
執(zhí)行 INSERT,UPDATE,DELETE 語句時鎖更少
從服務(wù)器上采用多線程來執(zhí)行復(fù)制成為可能
RBR 的缺點:
binlog 大了很多
復(fù)雜的回滾時 binlog 中會包含大量的數(shù)據(jù)
主服務(wù)器上執(zhí)行 UPDATE 語句時,所有發(fā)生變化的記錄都會寫到 binlog 中,而 SBR 只會寫一次,這會導(dǎo)致頻繁發(fā)生 binlog 的并發(fā)寫問題
UDF 產(chǎn)生的大 BLOB 值會導(dǎo)致復(fù)制變慢
無法從 binlog 中看到都復(fù)制了寫什么語句
當(dāng)在非事務(wù)表上執(zhí)行一段堆積的SQL語句時,最好采用 SBR 模式,否則很容易導(dǎo)致主從服務(wù)器的數(shù)據(jù)不一致情況發(fā)生
另外,針對系統(tǒng)庫 mysql 里面的表發(fā)生變化時的處理規(guī)則如下:
如果是采用 INSERT,UPDATE,DELETE 直接操作表的情況,則日志格式根據(jù) binlog_format 的設(shè)定而記錄
如果是采用 GRANT,REVOKE,SET PASSWORD 等管理語句來做的話,那么無論如何都采用 SBR 模式記錄
注:采用 RBR 模式后,能解決很多原先出現(xiàn)的主鍵重復(fù)問題。
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
[MySQL5.1體驗]MySQL復(fù)制
[MySQL5.1體驗]MySQL復(fù)制:作/譯者:葉金榮(Email: ),來源:http://imysql.cn MySQL 5.1 中,在復(fù)制方面的改進(jìn)就是引進(jìn)了新的復(fù)制技術(shù):基于行的復(fù)制。簡言之,這種新技術(shù)就是關(guān)注表中發(fā)生變化的記錄,而非以前 的照抄 binlog 模式。從 MySQL 5.1.12 開始,可以用以下