MySQL Replication 大家都非常熟悉了，我也不會寫怎么搭建以及復(fù)制的原理，網(wǎng)上相關(guān)文章非常多，大家可以自己去搜尋。我在這里就是想總結(jié)一下mysql主從復(fù)制需要注意的地方。有人說主從復(fù)制很簡單嘛，就是master，slave的server_id不一樣就搞定。確實，簡單的來說就是這么簡單。但是真正在生產(chǎn)環(huán)境我們需要注意的太多了。首先說說主庫宕機或者從庫宕機后復(fù)制中斷的問題。

雖然很多知識點或許我博客其他文章中都有提到過，或者重復(fù)了，但是我還是想總結(jié)一下。

主庫意外宕機

如果沒有設(shè)置主庫的sync_binlog選項，就可能在奔潰前沒有將最后的幾個二進制日志事件刷新到磁盤中。備庫I/O線程因此也可一直處于讀不到尚未寫入磁盤的事件的狀態(tài)中。當(dāng)主庫從新啟動時，備庫將重連到主庫并再次嘗試去讀該事件，但主庫會告訴備庫沒有這個二進制日志偏移量。解決這個問題的方法是指定備庫從下一個二進制日志的開頭讀日志。但是一些事件將永久丟失。可以使用前面文章提到的工具來檢查主從數(shù)據(jù)一致以及修復(fù)pt-table-checksum。即使開啟了sync_binlog，myisam表的數(shù)據(jù)仍然可能在奔潰的時候損壞。對于innodb表，如果innodb_flush_log_at_trx_commit沒有設(shè)置為1，也可能丟失數(shù)據(jù)，但是數(shù)據(jù)不會損壞。

因此主庫的參數(shù)建議開啟

sync_binlog=1innodb-flush-log-at-trx-commit=1

MySQL 5.6版本之前存在一個bug，即當(dāng)啟用上述兩個參數(shù)時，會使得InnoDB存儲引擎的group commit失效，從而導(dǎo)致在寫密集的環(huán)境中性能的急劇下降。group commit是什么？這是一個知識點，那為什么sync_binlog=1,innodb-flush-log-at-trx-commit=1

會導(dǎo)致組提交失敗？這又是一個知識點，大家可以查閱相關(guān)資料。

因此，我們常常在性能和數(shù)據(jù)一致性中做了妥協(xié)，通常將參數(shù)innodb-flush-log-at-trx-commit設(shè)置為2，而這就導(dǎo)致了master不再是crash safe的，主從數(shù)據(jù)可能會不一致。關(guān)于innodb_flush_log_at_trx_commit的有效值為0,1,2。我這里簡單提一下，因為很多知識點是有連貫性的，往往提到這個問題而又涉及到另外的問題^_^

0代表當(dāng)提交事務(wù)時，并不將事務(wù)的重做日志寫入磁盤上的日志文件，而是等待主線程每秒的刷新。當(dāng)宕機時，丟失1秒的事務(wù)。

1和2有點相同，但是不同的地方在于：1表示在執(zhí)行commit時將重做日志緩沖同步寫到磁盤，即伴有fsync的調(diào)用。2表示將重做日志異步寫到磁盤，即寫到文件系統(tǒng)的緩存中。由操作系統(tǒng)控制刷新。因此不能完全保證在執(zhí)行commit時肯定會寫入重做日志文件，只是有這個動作的發(fā)生。

因此為了保證事務(wù)的ACID中的持久性，必須將innodb_flush_log_at_trx_commit設(shè)置為1，也就是每當(dāng)有事務(wù)提交時，就必須確保事務(wù)都已經(jīng)寫入重做日志文件。那么當(dāng)數(shù)據(jù)庫因為意外發(fā)生宕機時，可以通過重做日志文件恢復(fù)，并保證可以恢復(fù)已經(jīng)提交的事務(wù)。而將該參數(shù)設(shè)置為0或者2，都有可能發(fā)生恢復(fù)時部分事務(wù)的丟失。不同之處在于，設(shè)置為2時，當(dāng)mysql數(shù)據(jù)庫發(fā)生宕機而操作系統(tǒng)及服務(wù)器并沒有發(fā)生宕機時，由于此時未寫入磁盤的事務(wù)日志保存在文件系統(tǒng)緩存中，當(dāng)恢復(fù)時同樣能保證數(shù)據(jù)不丟失。

對于性能與安全我們都要的情況下，我們肯定會使用RAID，并且開啟Write Back功能，而且RAID卡提供電池備份單元(BBU,Battery Backup Unit)，關(guān)于這塊的知識，童鞋們可以自行查閱相關(guān)資料。

備庫意外宕機：

當(dāng)備庫在一次非計劃的關(guān)閉后重啟時，會去讀master.info文件以找到上次停止復(fù)制的位置。不幸的是，該文件可能并沒有同步寫到磁盤，因為該信息是在緩存中，可能并沒有刷新到磁盤文件master.info。文件中存儲的信息可能是錯誤的，備庫可能會嘗試重新執(zhí)行一些二進制日志事件，這可能導(dǎo)致主鍵沖突，就是我們常常看見的1062錯誤。除非能確定備庫在哪里停止(很難)，否則唯一的辦法就是忽略那些錯誤。

在從庫導(dǎo)致復(fù)制中斷有兩方面的原因，即replication中的SQL thread和IO thread。首先來看SQL thread，其主要完成兩個操作：

1.運行relay log中對應(yīng)的事務(wù)信息

2.更新relay-info.log文件

更新relay-info.log文件是為了記錄已經(jīng)執(zhí)行relay log中的位置，當(dāng)slave重啟后可以根據(jù)這個位置繼續(xù)同步relay log。但是，這里用戶會發(fā)現(xiàn)這兩個操作不是在一個事務(wù)中，一個是數(shù)據(jù)庫操作，一個是文件操作，因此不能達到原子的效果。此外，MySQL數(shù)據(jù)庫默認對于文件relay-info.log是寫入到操作系統(tǒng)緩存，因此在發(fā)生宕機時可能導(dǎo)致大量的已更新位置的丟失，從而導(dǎo)致重復(fù)執(zhí)行SQL語句，最終的現(xiàn)象就是主從數(shù)據(jù)不一致。MySQL 5.5新增了參數(shù)sync_relay_log_info,可以控制每次事務(wù)更新relay-info.log后就進行一次fdatasync操作，這加重了系統(tǒng)負擔(dān)，而且即使這樣也可能存在最后一個事務(wù)丟失的情況。

IO thread用于同步master上的二進制日志，但是其在crash時依然會導(dǎo)致數(shù)據(jù)不一致的情況發(fā)生。IO thread將收到的二進制日志寫入到relay log，每個二進制日志由多個log event組成，所以每接受到一個log event就需要更新master-info.log。和relay-info.log一樣，其也是寫入操作系統(tǒng)緩存，參數(shù)sync_master_info可以控制fdatasync的時間。由于IO thread的更新不能像SQL thread一樣進行放到一個事務(wù)進行原子操作，因此其是對數(shù)據(jù)一致性會產(chǎn)生影響，設(shè)想一個log event傳送到了relay log中兩次的情形。

不過好在從MySQL 5.5版本開始提供了參數(shù)relay_log_recovery，當(dāng)發(fā)生crash導(dǎo)致重連master時，其不根據(jù)master-info.log的信息進行重連，而是根據(jù)relay-info中執(zhí)行到master的位置信息重新開始拉master上的日志數(shù)據(jù)(不過需要確保日志依然存在于master上，否則就。。。)

so，mysql 5.5版本的從庫推薦配置參數(shù)：

sync_master_info = 1sync_relay_log= 1sync_relay_log_info= 1read_only #從庫只讀，但是有super權(quán)限的依然可以寫入

relay_log_recovery = 1

skip_slave_start # 默認啟動從庫就開啟了同步，io線程和sql線程都運行了，該參數(shù)是需要手動執(zhí)行start slave方可啟動同步

復(fù)制過濾選項

常常看見很多同學(xué)在主庫進行過濾選項設(shè)置，當(dāng)然這也有好處，減少了帶寬，但是在主庫設(shè)置過濾選項是非常危險的操作，因為無論是顯示要過濾的或者要同步的，二進制日志只記錄你設(shè)置的，其他的是不會記錄的。當(dāng)主庫有數(shù)據(jù)需要用到binlog恢復(fù)時，你就準備哭吧。所以通常在備庫進行過濾選項設(shè)置。比如忽略某個庫，同步所有庫，或者同步某一個庫，當(dāng)然這會浪費帶寬，但是和安全比起來，這點浪費不算什么。有時候安全與性能往往需要我們自己平衡。

還有就是跨庫更新，如果我們在備庫是這樣設(shè)置的，比如同步y(tǒng)ayun這個庫

replicate_do_db=yayun

主庫記錄如下：

mysql> select * fromt1;+----+-------+

| id | name |

+----+-------+

| 1 | yayun |

| 2 | atlas |

| 3 | mysql |

+----+-------+

3 rows in set (0.00sec)

mysql>

備庫記錄如下：

mysql> select * fromt1;+----+-------+

| id | name |

+----+-------+

| 1 | yayun |

| 2 | atlas |

| 3 | mysql |

+----+-------+

3 rows in set (0.00sec)

mysql>

現(xiàn)在我們在主庫插入一條記錄

mysql> usetest;

Readingtable information for completion of table and columnnames

You can turnoff this feature to get a quicker startup with -ADatabasechanged

mysql> insert into yayun.t1 (name) values ('good yayun');

Query OK,1 row affected (0.01sec)

mysql> select * fromyayun.t1;+----+------------+

| id | name |

+----+------------+

| 1 | yayun |

| 2 | atlas |

| 3 | mysql |

| 5 | good yayun |

+----+------------+

4 rows in set (0.00sec)

mysql>

查看備庫：

mysql> select * fromt1;+----+-------+

| id | name |

+----+-------+

| 1 | yayun |

| 2 | atlas |

| 3 | mysql |

+----+-------+

3 rows in set (0.00sec)

mysql>

怎么回事？怎么沒有同步？這就是跨庫更新帶來的問題，比如下面的更新：

usetestinsert into yayun.t1 (name) values ('good yayun')

當(dāng)然你會說哪個2B會這么干啊，呵呵，有時2B還是有的。所以我們還有另外2個過濾復(fù)制參數(shù)

replicate_wild_do_table

replicate_wild_ignore_table

一個是要同步的表，一個是不同步的表，通常我們可以這樣寫

replicate_wild_do_table=yayun.%

表示同步y(tǒng)ayun庫下面的所有表，這樣就解決的跨庫更新的問題。

復(fù)制格式的問題

通常推薦使用ROW格式，為什么使用？看看我前面文章MySQL數(shù)據(jù)恢復(fù)和復(fù)制對InnoDB鎖機制的影響

不要用Seconds_Behind_Master來衡量MySQL主備的延遲時間

這個后續(xù)我會寫相關(guān)文章解釋為什么不要用該參數(shù)衡量主備的延遲時間。

總結(jié)：

上面所提到的參數(shù)都是最大限度保證主從數(shù)據(jù)一致，以及主庫宕機，從庫宕機復(fù)制不會中斷，但是性能會打折扣，所以需要我們自己去衡量，或者做妥協(xié)。

還有很多很多的問題，我也只總結(jié)了這么一點，要是還有大神知道更詳細的，歡迎一起交流，共同進步。^_^

參考資料：

總結(jié)

以上是生活随笔為你收集整理的检查mysql的replication_MySQL Replication需要注意的问题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。