MySQL數據庫InnoDB引擎主從復制同步經歷總結。本站提示廣大學習愛好者：（MySQL數據庫InnoDB引擎主從復制同步經歷總結）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL數據庫InnoDB引擎主從復制同步經歷總結正文
近期將公司的MySQL架構進級了，由本來的一主多從換成了DRBD+Heartbeat雙主多從，正好手上有一個電子商務網站新項目也要上線了，用的是DRBD+Heartbeat雙主一從，因為此進程照樣有別於之前的MyISAM引擎的，所以這裡也將其心得歸結總結了一下：
1）MySQL的replication進程是一個異步同步的進程，並不是完整的主從同步，所以同步的進程中是有延遲的，假如做了讀寫分別的營業的話，建議也要監控此延遲時光；
2）MySQL的master與slave機械記得server-id要堅持紛歧致，假如一樣的話，replication進程中會湧現以下報錯:
Fatal error: The slave I/O threadstopsbecause master and slavehave equal MySQL server ids; these ids mustbedifferent for replication to work(or the --replicate-same-server-id optionmustbe used on slave but this doesnot always make sense; please check themanualbefore 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. Defaultdatabase: '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
附注：--master-data的用法為：經由過程此參數來備份SQL文件時會建議一個slavereplication，當其值為1時，SQL文件中會記載change master語句；當其值為2時，change master會被寫成SQL正文，--master-data在沒有應用--single-transaction選項的情形下會主動應用lock-all-tables選項（即這二代選項不要搭配應用）。若何查找SQL中的的LOG_FILE及LOG_POS呢？我們可以用以下敕令(請留意change單詞要寫成年夜寫的)，以下所示：
grep "CHANGE"myproject.sql
敕令顯示成果以下：
CHANGE MASTER TOMASTER_LOG_FILE='mysql-bin.000008',MASTER_LOG_POS=106;
接上去的replication進程就不具體解釋了，同步完成後我們經由相當長時光的不雅察，再也沒1062報錯了，以下所示：
mysql> show slave status \G;
*************************** 1.row***************************
Slave_IO_State: Waitingformaster to send event
Master_Host: 192.168.11.174
Master_User: rep1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000008
Read_Master_Log_Pos: 27880
Relay_Log_File:centos3-relay-bin.000002
Relay_Log_Pos: 28025
Relay_Master_Log_File: mysql-bin.000008
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 27880
Relay_Log_Space: 28182
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)
任務中InnoDB引擎數據庫主從復制同步心得之前的項目也比擬多的牽扯到InnoDB數據庫的備份及replication，較多的一個做法是停庫停止replication，固然也是處理成績的一種思緒，但究竟屬於停機保護，在一些特別運用場景中是不許可的，我們應當多測驗考試采取mysqldump這類邏輯備份方法來取master主機快照。
