InnoDB引擎數(shù)據(jù)庫主從復(fù)制同步新的分享
更新時間：2012年11月28日 09:06:34 作者：
近期將公司的MySQL架構(gòu)升級了，由原先的一主多從換成了DRBD+Heartbeat雙主多從,所以這里也將其心得歸納總結(jié)了一下
近期將公司的MySQL架構(gòu)升級了，由原先的一主多從換成了DRBD+Heartbeat雙主多從，正好手上有一個電子商務(wù)網(wǎng)站新項(xiàng)目也要上線了，用的是DRBD+Heartbeat雙主一從，由于此過程還是有別于以前的MyISAM引擎的，所以這里也將其心得歸納總結(jié)了一下：
1）MySQL的replication過程是一個異步同步的過程，并非完全的主從同步，所以同步的過程中是有延遲的，如果做了讀寫分離的業(yè)務(wù)的話，建議也要監(jiān)控此延遲時間；
2）MySQL的master與slave機(jī)器記得server-id要保持不一致，如果一樣的話，replication過程中會出現(xiàn)如下報錯:
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機(jī)的server-id修改成跟master機(jī)器不一致即可。
3）我以前的一個誤區(qū)就是，slave機(jī)器是用自己的二進(jìn)制日志來完成replication過程的，其實(shí)不是這樣的，根據(jù)復(fù)制的工作原理：slave服務(wù)器是copy主服務(wù)器的二進(jìn)制日志到自己的中繼日志，即relay-log日志（即centos3-relay-bin.000002這種名字的）中，然后再把更新應(yīng)用用到自己的數(shù)據(jù)庫上，所以slave機(jī)器是不需要開啟二進(jìn)制日志的，這樣過程一樣會成功的；除非是準(zhǔn)備做主主架構(gòu)，這才需要slave機(jī)器開啟二進(jìn)制日志，這個問題一直在導(dǎo)著我，我以一直以為slave機(jī)器搭建replication環(huán)境時是一定要開啟二進(jìn)制的，
4）在master機(jī)器上授權(quán)時，盡量只給某一個或某幾個固定機(jī)器權(quán)限，讓它們只有replication slav，replication client權(quán)限，盡量不要給grant權(quán)限；另外，雖然數(shù)據(jù)庫我們一般是通過內(nèi)網(wǎng)操作，但越是在在內(nèi)網(wǎng)對MySQL數(shù)據(jù)庫進(jìn)行授權(quán)操作，越是要注意安全；
5）replication搭建過程按照正常流程走的話，一般很容易實(shí)施成功，如果出錯的話，多檢查下網(wǎng)絡(luò)環(huán)境、權(quán)限問題，一般來說整個搭建過程應(yīng)該還是會比較順利的。
在數(shù)據(jù)庫設(shè)計初期，我已經(jīng)將此電子商務(wù)的數(shù)據(jù)庫引擎定義為InnoDB，除了數(shù)據(jù)庫中原有的系統(tǒng)表之外，其它表全部由MyISAM轉(zhuǎn)成了InnoDB，原因有二：
1）電子商務(wù)業(yè)務(wù)會涉及到交易付款，在這種基本OLTP的應(yīng)用中，InnoDB應(yīng)該作為核心應(yīng)用表的首選存儲引擎；
2）DRBD系統(tǒng)重啟時的過程會比較緩慢，會頻繁的讀表，如果表引擎為MyISAM的話極有可能出現(xiàn)損壞情況，為了造成不必要的問題，我將數(shù)據(jù)庫的表引擎由MyISAM均轉(zhuǎn)成了InnoDB引擎的表。
DRBD+Heartbeat+MySQL參考以前的工作文檔，搭建的比較順利，就是在搭建replication環(huán)境時遇到了1062報錯，詳細(xì)過程如下：
初期參考MySQL手冊操作，取master機(jī)器的快照備份，用的是--single-transaction選項(xiàng)，然后同步過程頻繁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選項(xiàng)來取主master快照備份，命令如下所示：
mysqldump -uroot --quick --flush-logs --master-data=1 -p myproject > myproject.sql
1）MySQL的replication過程是一個異步同步的過程，并非完全的主從同步，所以同步的過程中是有延遲的，如果做了讀寫分離的業(yè)務(wù)的話，建議也要監(jiān)控此延遲時間；
2）MySQL的master與slave機(jī)器記得server-id要保持不一致，如果一樣的話，replication過程中會出現(xiàn)如下報錯:
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機(jī)的server-id修改成跟master機(jī)器不一致即可。
3）我以前的一個誤區(qū)就是，slave機(jī)器是用自己的二進(jìn)制日志來完成replication過程的，其實(shí)不是這樣的，根據(jù)復(fù)制的工作原理：slave服務(wù)器是copy主服務(wù)器的二進(jìn)制日志到自己的中繼日志，即relay-log日志（即centos3-relay-bin.000002這種名字的）中，然后再把更新應(yīng)用用到自己的數(shù)據(jù)庫上，所以slave機(jī)器是不需要開啟二進(jìn)制日志的，這樣過程一樣會成功的；除非是準(zhǔn)備做主主架構(gòu)，這才需要slave機(jī)器開啟二進(jìn)制日志，這個問題一直在導(dǎo)著我，我以一直以為slave機(jī)器搭建replication環(huán)境時是一定要開啟二進(jìn)制的，
4）在master機(jī)器上授權(quán)時，盡量只給某一個或某幾個固定機(jī)器權(quán)限，讓它們只有replication slav，replication client權(quán)限，盡量不要給grant權(quán)限；另外，雖然數(shù)據(jù)庫我們一般是通過內(nèi)網(wǎng)操作，但越是在在內(nèi)網(wǎng)對MySQL數(shù)據(jù)庫進(jìn)行授權(quán)操作，越是要注意安全；
5）replication搭建過程按照正常流程走的話，一般很容易實(shí)施成功，如果出錯的話，多檢查下網(wǎng)絡(luò)環(huán)境、權(quán)限問題，一般來說整個搭建過程應(yīng)該還是會比較順利的。
在數(shù)據(jù)庫設(shè)計初期，我已經(jīng)將此電子商務(wù)的數(shù)據(jù)庫引擎定義為InnoDB，除了數(shù)據(jù)庫中原有的系統(tǒng)表之外，其它表全部由MyISAM轉(zhuǎn)成了InnoDB，原因有二：
1）電子商務(wù)業(yè)務(wù)會涉及到交易付款，在這種基本OLTP的應(yīng)用中，InnoDB應(yīng)該作為核心應(yīng)用表的首選存儲引擎；
2）DRBD系統(tǒng)重啟時的過程會比較緩慢，會頻繁的讀表，如果表引擎為MyISAM的話極有可能出現(xiàn)損壞情況，為了造成不必要的問題，我將數(shù)據(jù)庫的表引擎由MyISAM均轉(zhuǎn)成了InnoDB引擎的表。
DRBD+Heartbeat+MySQL參考以前的工作文檔，搭建的比較順利，就是在搭建replication環(huán)境時遇到了1062報錯，詳細(xì)過程如下：
初期參考MySQL手冊操作，取master機(jī)器的快照備份，用的是--single-transaction選項(xiàng)，然后同步過程頻繁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選項(xiàng)來取主master快照備份，命令如下所示：
mysqldump -uroot --quick --flush-logs --master-data=1 -p myproject > myproject.sql
相關(guān)文章
mysql查詢每小時數(shù)據(jù)和上小時數(shù)據(jù)的差值實(shí)現(xiàn)思路詳解
這篇文章主要介紹了mysql查詢每小時數(shù)據(jù)和上小時數(shù)據(jù)的差值,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2020-04-04
詳解數(shù)據(jù)庫_MySQL: mysql函數(shù)
這篇文章主要介紹了數(shù)據(jù)庫_MySQL: mysql函數(shù)，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2019-03-03
MySQL 邏輯備份與恢復(fù)測試的相關(guān)總結(jié)
數(shù)據(jù)庫邏輯備份就是備份軟件按照我們最初所設(shè)計的邏輯關(guān)系，以數(shù)據(jù)庫的邏輯結(jié)構(gòu)對象為單位，將數(shù)據(jù)庫中的數(shù)據(jù)按照預(yù)定義的邏輯關(guān)聯(lián)格式一條一條生成相關(guān)的文本文件，以達(dá)到備份的目的。本文將具體介紹MySQL 邏輯備份的相關(guān)概念及如何做恢復(fù)測試。2021-05-05
本文將詳細(xì)介紹mysql 事務(wù)處理及表鎖定,需要了解更多的朋友可以參考下2012-11-11
mysql支持的字符串截取函數(shù)主要有?left()、right()、substring()、substring_index(),下面是這些函數(shù)的詳細(xì)使用方法2022-10-10
這篇文章主要介紹了MySQL COUNT(*)性能原理詳解，文章圍繞主題展開詳細(xì)的內(nèi)容介紹，具有一定的參考價值，需要的小伙伴可以參考一下2022-08-08
在這里我將介紹兩個使用MySQL數(shù)據(jù)庫時候簡化輸入的小技巧。2011-09-09
這篇文章主要介紹了如何解決mysql表輸入中文出現(xiàn)問號的問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-01-01
mysql中用的最多存儲引擎就是innodb和myisam。做為Mysql的默認(rèn)存儲引擎,myisam值得我們學(xué)習(xí)一下，以下是我對《高性能MYSQL》書中提到的myisam的理解,請大家多多指教2012-04-04
mysql 5.7.17 安裝配置方法圖文教程(CentOS7)
這篇文章主要為大家詳細(xì)介紹了CentOS7下mysql 5.7.17 安裝配置方法圖文教程，感興趣的小伙伴們可以參考一下2016-12-12