㈠ 哪些原因會導致mysql主從數據不一致
1.網路的延遲
由於mysql主從復制是基於binlog的一種非同步復制，通過網路傳送binlog文件，理所當然網路延遲是主從不同步的絕大多數的原因，特別是跨機房的數據同步出現這種幾率非常的大，所以做讀寫分離，注意從業務層進行前期設計。
2.主從兩台機器的負載不一致
由於mysql主從復制是主資料庫上面啟動1個io線程，而從上面啟動1個sql線程和1個io線程，當中任何一台機器的負載很高，忙不過來，導致其中的任何一個線程出現資源不足，都將出現主從不一致的情況。
3.max_allowed_packet設置不一致
主資料庫上面設置的max_allowed_packet比從資料庫大，當一個大的sql語句，能在主資料庫上面執行完畢，從資料庫上面設置過小，無法執行，導致的主從不一致。
4.key自增鍵開始的鍵值跟自增步長設置不一致引起的主從不一致。
5.mysql異常宕機情況下，如果未設置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出現binlog或者relaylog文件出現損壞，導致主從不一致。
6.mysql本身的bug引起的主從不同步。
7.版本不一致，特別是高版本是主，低版本為從的情況下，主資料庫上面支持的功能，從資料庫上面不支持該功能。
㈡ mysql主從同步,一個是mysql的5.5.56-MariaDB, 另外一個是 mysql的5.6.14 ,能數據
首先， 我要著重詳述下為什麼我們沒有把MySQL 5.6 直接拿過來作為二次開發的基礎，去做一個產品，可以稱為 MariaDB 5.6. 這個原因的細節我們直接都沒有和眾人分享。
1. MySQL5.6 的代碼庫的文件結構已經被改動了。比如單個代碼文件已經被分成多個，又或者是某些代碼已經被重新歸類到了不同的文件內。所以要把MariaDB 去配合現在這個文件結構一定是一個非常消耗時間的過程。而其實我確實不是很明白MySQL為什麼要改動現有的文件結構。
2. MairaDB 5.5 已經有大量的代碼不同於MySQL 5.5 的版本，而且也有很多的新的特徵被整合到MariaDB 5.5 中，而這些特徵直到 5.6 版本才出現在MySQL中。所以我們在比較同樣功能的MySQL 和MariaDB的版本，同時在完成設計和QA方面的審核後，一個很明顯的結論是MariaDB會是一個更好的產品。在大多數情況下，在選擇MariaDB的時候，人們會更多的考慮到功能方面的偏好。
3. 所以MySQL的新代碼，至少是修改bug的代碼以後都沒有必要進行相應的測試了。我們試想一下，當有這樣一個功能要加入到一段代碼中，而這個功能原本就是來源於這段代碼的情況下，測試將是一個異常重要的過程來保證這個功能的正常運行。
sjZ52
翻譯於 2年前
0人頂
頂 翻譯的不錯哦!
和上文中提到的第二點和第三點一樣，Stewart Smith在Percona寫到關於Mysql最後安全補丁的回歸測試和QA如何測試使用MariaDB工程，以及保存在Percona伺服器用作回歸測試的測試用例的重要性。參考：wrote yesterday about the latest security fix in MySQL introcing a regression
MariaDB不僅僅是Mysql的一個替代品。它的主要目的是創新和提高Mysql的技術，Mysql5.6不是一個合適的創新基礎平台，所以我們就做了下面的事情：
1.由於我們引入了一些新功能（像 multi-source replication多源復制, Cassandra integration, engine independent statistics獨立統計系統等），所以我們需要搞個新版本。通常當你引入新功能時，你需要新建個版本。
2.下個版本稱作「MariaDB5.6」是不準確的，因為他不是基於Mysql5.6，取而代之，我們決定版本號調為10.0
3.MariaDB引入Mysql5.6作為一種替代方案的話，需要提升很多功能，我們已經邁出了第一步，正朝著合並或者重建Mysql5.6的功能方向發展。