近期將公司的MySQL架構升級了，由原先的一主多從換成了DRBD+Heartbeat雙主多從，正好手上有一個電子商務網站新項目也要上線了，用的是DRBD+Heartbeat雙主一從，由於此過程還是有別於以前的MyISAM引擎的，所以這裡也將其心得歸納總結了一下：
1）MySQL的replication過程是一個異步同步的過程，並非完全的主從同步，所以同步的過程中是有延遲的，如果做了讀寫分離的業務的話，建議也要監控此延遲時間；
2）MySQL的master與slave機器記得server-id要保持不一致，如果一樣的話，replication過程中會出現如下報錯:
Fatal error: The slave I/O thread stops because master and slavehave equal MySQL server ids; these ids must be different for replication to work(or the --replicate-same-server-id option must be used on slave but this doesnot always make sense; please check the manual before using it).
這個問題很好處理，即將slave機的server-id修改成跟master機器不一致即可。
3）我以前的一個誤區就是，slave機器是用自己的二進制日志來完成replication過程的，其實不是這樣的，根據復制的工作原理：slave服務器是copy主服務器的二進制日志到自己的中繼日志，即relay-log日志（即centos3-relay-bin.000002這種名字的）中，然後再把更新應用用到自己的數據庫上，所以slave機器是不需要開啟二進制日志的，這樣過程一樣會成功的；除非是准備做主主架構，這才需要slave機器開啟二進制日志，這個問題一直在導著我，我以一直以為slave機器搭建replication環境時是一定要開啟二進制的，
4）在master機器上授權時，盡量只給某一個或某幾個固定機器權限，讓它們只有replication slav，replication client權限，盡量不要給grant權限；另外，雖然數據庫我們一般是通過內網操作，但越是在在內網對MySQL數據庫進行授權操作，越是要注意安全；
5）replication搭建過程按照正常流程走的話，一般很容易實施成功，如果出錯的話，多檢查下網絡環境、權限問題，一般來說整個搭建過程應該還是會比較順利的。
在數據庫設計初期，我已經將此電子商務的數據庫引擎定義為InnoDB，除了數據庫中原有的系統表之外，其它表全部由MyISAM轉成了InnoDB，原因有二：
1）電子商務業務會涉及到交易付款，在這種基本OLTP的應用中，InnoDB應該作為核心應用表的首選存儲引擎；
2）DRBD系統重啟時的過程會比較緩慢，會頻繁的讀表，如果表引擎為MyISAM的話極有可能出現損壞情況，為了造成不必要的問題，我將數據庫的表引擎由MyISAM均轉成了InnoDB引擎的表。
DRBD+Heartbeat+MySQL參考以前的工作文檔，搭建的比較順利，就是在搭建replication環境時遇到了1062報錯，詳細過程如下：
初期參考MySQL手冊操作，取master機器的快照備份，用的是--single-transaction選項，然後同步過程頻繁1062報錯，報錯日志如下：
Last_SQL_Error: Error 'Duplicate entry 'd36ad91bff36308de540bbd9ae6f4279' for key 'PRIMARY'' on query. Default database: 'myproject'. Query: 'INSERT INTO `lee_sessions` (`session_id`, `ip_address`, `user_agent`, `last_activity`, `user_data`) VALUES ('d36ad91bff36308de540bbd9ae6f4279', '180.153.201.218', 'Mozilla/4.0', 1353394206, '')'
後來改變思路，用--master-data選項來取主master快照備份，命令如下所示：
mysqldump -uroot --quick --flush-logs --master-data=1 -p myproject > myproject.sql
