mysql同步成績之Slave延遲很年夜優化辦法。本站提示廣大學習愛好者：（mysql同步成績之Slave延遲很年夜優化辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是mysql同步成績之Slave延遲很年夜優化辦法正文
普通而言，slave絕對master延遲較年夜，其基本緣由就是slave上的復制線程沒方法真正做到並發。簡略說，在master上是並發形式(以InnoDB引擎為主)完成事務提交的，而在slave上，復制線程只要一個sql thread用於binlog的apply，所以難怪slave在高並發時會遠落伍master。
ORACLE MySQL 5.6版本開端支撐多線程復制，設置裝備擺設選項 slave_parallel_workers 便可完成在slave上多線程並發復制。不外，它只能支撐一個實例下多個 database 間的並發復制，其實不能真正做到多表並發復制。是以在較年夜並發負載時，slave照樣沒有方法實時追上master，須要想方法停止優化。
另外一個主要緣由是，傳統的MySQL復制是異步(asynchronous)的，也就是說在master提交完後，才在slave上再運用一遍，其實不是真正意義上的同步。哪怕是後來的Semi-sync Repication(半同步復制)，也不是真同步，由於它只包管事務傳送到slave，但沒請求比及確認事務提交勝利。既然是異步，那確定若干會有延遲。是以，嚴厲意義上講，MySQL復制不克不及叫做MySQL同步(童貞座的面試官有能夠會在面試時把說成MySQL同步的一概刷失落哦)。
別的，很多人的不雅念裡，slave絕對沒那末主要，是以就不會供給和master雷同設置裝備擺設級其余辦事器。有的乃至不只應用更差的辦事器，並且還在下面跑多實例。
綜合這兩個重要緣由，slave想要盡量實時跟上master的進度，可以測驗考試采取以下幾種辦法：
1、采取MariaDB刊行版，它完成了絕對真正意義上的並行復制，其後果遠比ORACLE MySQL好的許多。在我的場景中，采取MariaDB作為slave的實例，簡直老是能實時跟上master。假如不想用這個版本的話，那就誠實期待官方5.7年夜版本宣布吧；
關於MariaDB的Parallel Replication詳細請參考：Replication and Binary Log Server System Variables#slave_parallel_threads – MariaDB Knowledge Base
2、每一個表都要顯式指定主鍵，假如沒有指定主鍵的話，會招致在row形式下，每次修正都要全表掃描，特別是年夜表就異常恐怖了，延遲會更嚴重，乃至招致全部slave庫都被掛起，可參考案例：mysql主鍵的缺乏招致備庫hang；
3、運用法式端多做些事，讓MySQL端少干事，特別是和IO相干的運動，例如：前端經由過程內存CACHE或許當地寫隊列等，歸並屢次讀寫為一次，乃至清除一些寫要求；
4、停止適合的分庫、分表戰略，減小單庫單表復制壓力，防止因為單庫單表的的壓力招致全部實例的復制延遲；
其他進步IOPS機能的幾種辦法，依據後果好壞，我做了個簡略排序：
1、改換成SSD，或許PCIe SSD等IO裝備，其IOPS才能的晉升是通俗15K SAS盤的數以百倍、萬倍，乃至幾十萬倍計；
2、加年夜物理內存，響應進步InnoDB Buffer Pool年夜小，讓更多熱數據放在內存中，下降產生物理IO的頻率；
3、調劑文件體系為 XFS 或 ReiserFS，比擬ext3可以極年夜水平進步IOPS才能。在高IOPS壓力下，比擬ext4有更穩健的IOPS表示(有人以為 XFS 在特殊的場景下會有很年夜的成績，但我們除殘剩磁盤空間少於10%時激發丟數據外，其他的還沒有碰到)；
4、調劑RAID級別為raid 1+0，它比擬raid1、raid5等更能進步IOPS機能。假如曾經全體是SSD裝備了，可以2塊盤做成RAID 1，或許多快盤做成RAID 5(而且可以設置全局熱備盤，進步陣列容錯性)，乃至有些土豪用戶直接將多塊SSD盤構成RAID 50；
5、調劑RAID的寫cache戰略為WB或FORCE WB，概況請參考：經常使用PC辦事器陣列卡、硬盤安康監控 和 PC辦事器陣列卡治理簡略單純手冊；
6、調劑內核的io scheduler，優先應用deadline，假如是SSD，則可使用noop戰略，比擬默許的cfq，個體情形下對IOPS的機能晉升至多是數倍的。
其他更多辦法，迎接年夜家協助彌補 ：)
