由于歷史原因，MySQL復制基于邏輯的二進制日志，而非重做日志。多次被問到何時MySQL能支持基于物理的復制，其實這就看MySQL各位大佬的想法。上次和賴老師腦暴，倏地說道：MySQL會不會來個基于Paxos的redo復制？

物理復制的真正好處不在于正確性，因為基于ROW格式的日志復制也已能完全保證復制的正確性。由于物理日志的寫入是在事務執(zhí)行過程中就不斷寫入，而二進制日志的寫入僅僅在事務提交時。因此物理日志的優(yōu)勢如下所示：

• 復制架構下，大事務日志提交速度快；
• 復制架構下，主從數據延遲??；

假設執(zhí)行了1個小時的某大事務，在最后提交時，只需寫入最后提交部分的重做日志（redo log可視為物理日志）。雖然此大事務重做日志寫入的總量可能有1G，然而在提交時，數據主從復制僅需將最后一部分日志傳輸到遠程從機，因為之前的重做日志已經在執(zhí)行的1個小時內不斷地同步到從機。

對于二進制日志，由于其寫入時間發(fā)生在事務提交時，因此假設產生了1G的二進制日志，則需要事務提交時間會包含這1G日志的寫入時間。在Oracle中有一種說法，事務的提交速度都是平的，不論事務的大小。這在MySQL數據庫中是不成立的。即，MySQL的提交速度取決于事務產生的二進制日志的大小，事務提交的速度不是平的。

更為糟糕的是，MySQL主從復制在大事務下的延遲。同樣假設1個大事務在主服務器上執(zhí)行了1個小時，則需要在最后的提交時間傳送到從服務器。主從延遲的時間至少為1個小時，若從服務器執(zhí)行還需1個小時，則主從復制延遲的最壞情況可能是2個小時。物理復制則不存在這樣的限制，原因還是如前所述，事務提交過程中，日志已經在傳輸和回放。

物理復制雖好，但是也有自己的缺陷，就我自己的實際體驗來看：

• 物理復制下，主機壞塊會導致主從服務器都無法啟動；相信遇到過此問題的同學不在少數；
• 此外，做ETL是有困難的，比如怎么將物理日志同步到Hadoop大數據平臺呢？

一言以蔽之，對于MySQL數據庫來說，任何時刻不允許有大事務執(zhí)行。若要執(zhí)行，則將大事務拆成一個個小的子事務來執(zhí)行。這是最基本心法口訣，但卻又和Oracle有著很大不同。總之，氣宗、劍宗，本無好壞，學會理解其中的差異，融會貫通方可達風清揚般的致臻境界。

mysql 用主從同步的方法進行讀寫分離，減輕主服務器的壓力的做法現在在業(yè)內做的非常普遍。 主從同步基本上能做到實時同步。我從別的網站借用了主從同步的原理圖。

在配置好了， 主從同步以后， 主服務器會把更新語句寫入binlog,   從服務器的IO 線程(這里要注意， 5.6.3 之前的IO線程僅有一個，5.6.3之后的有多線程去讀了，速度自然也就加快了)回去讀取主服務器的binlog 并且寫到從服務器的Relay log 里面，然后從服務器的 的SQL thread 會一個一個執(zhí)行 relay log 里面的sql ， 進行數據恢復。

relay 就是 傳遞, relay race 就是接力賽的意思

1. 主從同步的延遲的原因

我們知道， 一個服務器開放Ｎ個鏈接給客戶端來連接的，　這樣有會有大并發(fā)的更新操作, 但是從服務器的里面讀取binlog 的線程僅有一個， 當某個SQL在從服務器上執(zhí)行的時間稍長 或者由于某個SQL要進行鎖表就會導致，主服務器的SQL大量積壓，未被同步到從服務器里。這就導致了主從不一致， 也就是主從延遲。

2. 主從同步延遲的解決辦法

實際上主從同步延遲根本沒有什么一招制敵的辦法， 因為所有的SQL必須都要在從服務器里面執(zhí)行一遍，但是主服務器如果不斷的有更新操作源源不斷的寫入， 那么一旦有延遲產生， 那么延遲加重的可能性就會原來越大。 當然我們可以做一些緩解的措施。

• a. 我們知道因為主服務器要負責更新操作， 他對安全性的要求比從服務器高， 所有有些設置可以修改，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之類的設置，而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog，innodb_flushlog， innodb_flush_log_at_trx_commit 也 可以設置為0來提高sql的執(zhí)行效率 這個能很大程度上提高效率。另外就是使用比主庫更好的硬件設備作為slave。
• b. 就是把，一臺從服務器當度作為備份使用， 而不提供查詢， 那邊他的負載下來了， 執(zhí)行relay log 里面的SQL效率自然就高了。
• c. 增加從服務器嘍，這個目的還是分散讀的壓力， 從而降低服務器負載。

3. 判斷主從延遲的方法

MySQL提供了從服務器狀態(tài)命令，可以通過 show slave status 進行查看，  比如可以看看Seconds_Behind_Master參數的值來判斷，是否有發(fā)生主從延時。

其值有這么幾種：

NULL - 表示io_thread或是sql_thread有任何一個發(fā)生故障，也就是該線程的Running狀態(tài)是No,而非Yes.
0 - 該值為零，是我們極為渴望看到的情況，表示主從復制狀態(tài)正常

其它的方法我也沒試過， 暫時不做評論

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接

最新評論