mysql主從複製原理
主庫會將變更寫入biglog日誌中，主庫生成乙個 log dump 執行緒，用來給從庫 i/o執行緒傳binlog；
從庫生成兩個執行緒，乙個i/o執行緒，乙個sql執行緒；
i/o執行緒去請求主庫 的binlog，並將得到的binlog日誌寫到relay log（中繼日誌） 檔案中；
sql 執行緒，會讀取relay log檔案中的日誌，並解析成具體操作，來實現主從的操作一致，而最終資料一致；
從庫同步主庫資料的過程是序列化的，也就是說主庫上並行的操作，在從庫上會序列執行。所以這就是乙個非常重要的點了，由於從庫從主庫拷貝日誌以及序列執行sql的特點，在高併發場景下，從庫的資料一定會比主庫慢一些，是有延時的。
另外乙個問題，就是如果主庫突然宕機，然後恰好資料還沒同步到從庫，那麼有些資料可能在從庫上是沒有的，有些資料可能就丟失了。
這裡一般用並行複製，用來解決主從同步延時問題；半同步複製，用來解決主庫資料丟失問題。
並行複製，指的是從庫開啟多個執行緒，並行讀取relay log中不同庫的日誌，然後並行重放不同庫的日誌，這是庫級別的並行。
半同步複製（semi-sync複製），指的就是主庫寫入binlog日誌之後，就會將強制此時立即將資料同步到從庫，從庫將日誌寫入自己本地的relay log之後，接著會返回乙個ack給主庫，主庫接收到至少乙個從庫的ack之後才會認為寫操作完成了。
mysql主從同步，建議是一般在讀遠遠多於寫，而且讀的時候一般對資料時效性要求沒那麼高的時候，用mysql主從同步，會對於那種寫了之後立馬就要保證可以查到的場景，採用強制讀主庫的方式。
一般來說，如果主從延遲較為嚴重
1、分庫，將乙個主庫拆分為4個主庫，每個主庫的寫併發就500/s，此時主從延遲可以忽略不計
2、開啟mysql支援的並行複製，多個庫並行複製，如果說某個庫的寫入併發就是特別高，單庫寫併發達到了2000/s，並行複製還是沒意義。28法則，很多時候比如說，就是少數的幾個訂單表，寫入了2000/s，其他幾十個表10/s。
3、重寫**，寫**的同學，要慎重，當時我們其實短期是讓那個同學重寫了一下**，插入資料之後，直接就更新，不要查詢
4、如果確實是存在必須先插入，立馬要求就查詢到，然後立馬就要反過來執行一些操作，對這個查詢設定直連主庫。不推薦這種方法，你這麼搞導致讀寫分離的意義就喪失了。
分布式事務
參考： 關於分布式事務、兩階段提交、一階段提交、best efforts 1pc模式和事務補償機制的研究優點基於兩階段提交，最大限度地保證了跨資料庫操作的「原子性」，是分布式系統下最嚴格的事務實現方式。實現簡單，工作量小。由於多數應用伺服器以及一些獨立的分布式事務協調器做了大量的封裝工作，使得專案中引入分布式事務的難度和工作量基本上可以忽略不計。缺點系統「水平」伸縮的死敵。基於兩階段提交的分布式事務在提交事務時需要在多個節點之間進行協調,最大限度地推後了提交事務的時間點，客觀上延長了事務的執行時間，這會導致事務在訪問共享資源時發生衝突和死鎖的概率增高，隨著資料庫節點的增多，這種趨勢會越來越嚴重，從而成為系統在資料庫層面上水平伸縮的"枷鎖"， 這是很多sharding系統不採用分布式事務的主要原因。基於best efforts 1pc模式的事務
參考spring-data-neo4j的實現。鑑於best efforts 1pc模式的效能優勢，以及相對簡單的實現方式，它被大多數的sharding框架和專案採用
事務補償（冪等值）
對於那些對效能要求很高，但對一致性要求並不高的系統，往往並不苛求系統的實時一致性，只要在乙個允許的時間週期內達到最終一致性即可，這使得事務補償機制成為一種可行的方案。
事務補償機制最初被提出是在「長事務」的處理中，但是對於分布式系統確保一致性也有很好的參考意義。籠統地講，與事務在執行中發生錯誤後立即回滾的方式不同，事務補償是一種事後檢查並補救的措施，它只期望在乙個容許時間週期內得到最終一致的結果就可以了。事務補償的實現與系統業務緊密相關，並沒有一種標準的處理方式。一些常見的實現方式有：對資料進行對帳檢查;基於日誌進行比對;定期同標準資料**進行同步，等等
mysql資料庫主從複製
mysqld the tcp ip port the mysql server will listen on port 3307 path to installation directory.all paths are usually resolved relative to this.basedi...
資料庫（十） MySQL主從複製
複製的基本原理 複製的基本原則 複製的最大問題 說一說三個正規化 百萬級別或以上的資料如何刪除 關於索引 由於索引需要額外的維護成本，因為索引檔案是單獨存在的檔案,所以當我們對資料的增加,修改,刪除,都會產生額外的對索引檔案的操作,這些操作需要消耗額外的io,會降低增 改 刪的執行效率。所以，在我們...
MySQL 資料庫主從複製架構
前文 mysql 資料庫事務與複製 分析了 mysql 複製過程中如何保證 binlog 和事務資料之間的一致性，本文進一步分析引入從庫後需要保證主從的資料一致性需要考慮哪些方面。mysql 的原生複製架構原理如上圖所示。從庫的 i o thread 執行緒負責不斷讀取主庫的 binlog 日誌檔案...