近期將公司的MySQL架構(gòu)升級了，由原先的一主多從換成了DRBD+Heartbeat雙主多從，正好手上有一個電子商務網(wǎng)站新項目也要上線了，用的是DRBD+Heartbeat雙主一從，由于此過程還是有別于以前的MyISAM引擎的，所以這里也將其心得歸納總結(jié)了一下：

1）MySQL的replication過程是一個異步同步的過程，并非完全的主從同步，所以同步的過程中是有延遲的，如果做了讀寫分離的業(yè)務的話，建議也要監(jiān)控此延遲時間；

2）MySQL的master與slave機器記得server-id要保持不一致，如果一樣的話，replication過程中會出現(xiàn)如下報錯:

這個問題很好處理，即將slave機的server-id修改成跟master機器不一致即可。

3）我以前的一個誤區(qū)就是，slave機器是用自己的二進制日志來完成replication過程的，其實不是這樣的，根據(jù)復制的工作原理：slave服務器是copy主服務器的二進制日志到自己的中繼日志，即relay-log日志（即centos3-relay-bin.000002這種名字的）中，然后再把更新應用用到自己的數(shù)據(jù)庫上，所以slave機器是不需要開啟二進制日志的，這樣過程一樣會成功的；除非是準備做主主架構(gòu)，這才需要slave機器開啟二進制日志，這個問題一直在導著我，我以一直以為slave機器搭建replication環(huán)境時是一定要開啟二進制的

4）在master機器上授權(quán)時，盡量只給某一個或某幾個固定機器權(quán)限，讓它們只有replication slav，replication client權(quán)限，盡量不要給grant權(quán)限；另外，雖然數(shù)據(jù)庫我們一般是通過內(nèi)網(wǎng)操作，但越是在在內(nèi)網(wǎng)對MySQL數(shù)據(jù)庫進行授權(quán)操作，越是要注意安全；

5）replication搭建過程按照正常流程走的話，一般很容易實施成功，如果出錯的話，多檢查下網(wǎng)絡環(huán)境、權(quán)限問題，一般來說整個搭建過程應該還是會比較順利的。

在數(shù)據(jù)庫設計初期，我已經(jīng)將此電子商務的數(shù)據(jù)庫引擎定義為InnoDB，除了數(shù)據(jù)庫中原有的系統(tǒng)表之外，其它表全部由MyISAM轉(zhuǎn)成了InnoDB，原因有二：

1）電子商務業(yè)務會涉及到交易付款，在這種基本OLTP的應用中，InnoDB應該作為核心應用表的首選存儲引擎；
2）DRBD系統(tǒng)重啟時的過程會比較緩慢，會頻繁的讀表，如果表引擎為MyISAM的話極有可能出現(xiàn)損壞情況，為了造成不必要的問題，我將數(shù)據(jù)庫的表引擎由MyISAM均轉(zhuǎn)成了InnoDB引擎的表。

DRBD+Heartbeat+MySQL參考以前的工作文檔，搭建的比較順利，就是在搭建replication環(huán)境時遇到了1062報錯，詳細過程如下：
初期參考MySQL手冊操作，取master機器的快照備份，用的是--single-transaction選項，然后同步過程頻繁1062報錯，報錯日志如下：

后來改變思路，用--master-data選項來取主master快照備份，命令如下所示：

附注：--master-data的用法為：通過此參數(shù)來備份SQL文件時會建議一個slavereplication，當其值為1時，SQL文件中會記錄change master語句；當其值為2時，change master會被寫成SQL注釋，--master-data在沒有使用--single-transaction選項的情況下會自動使用lock-all-tables選項（即這二代選項不要搭配使用）。如何查找SQL中的的LOG_FILE及LOG_POS呢？我們可以用如下命令(請注意change單詞要寫成大寫的)，如下所示：

接下來的replication過程就不詳細說明了，同步完成后我們經(jīng)過相當長時間的觀察，再也沒1062報錯了，如下所示：

工作中InnoDB引擎數(shù)據(jù)庫主從復制同步心得以前的項目也比較多的牽涉到InnoDB數(shù)據(jù)庫的備份及replication，較多的一個做法是停庫進行replication，雖然也是解決問題的一種思路，但畢竟屬于停機維護，在一些特殊應用場景中是不允許的，我們應該多嘗試采用mysqldump這種邏輯備份方式來取master主機快照。

最新評論