日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢(xún)
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問(wèn)題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營(yíng)銷(xiāo)解決方案
意想不到的MySQL復(fù)制延遲原因

導(dǎo)讀

線上有個(gè)MySQL實(shí)例，存在嚴(yán)重的復(fù)制延遲問(wèn)題，原因出乎意料。

線上有個(gè)MySQL 5.7版本的實(shí)例，從服務(wù)器延遲了3萬(wàn)多秒，而且延遲看起來(lái)好像還在加劇。

MySQL版本

 
 
 
 
      
  
  
  
  1. Server version: 5.7.18-log MySQL Community Server (GPL) 
    2.

看下延遲狀況

 
 
 
 
      
  
  
  
  1. yejr@imysql.com:mysql3306.sock : (none) > show slave status\G 
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3. Master_Log_File: mysql-bin.013225 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5. Read_Master_Log_Pos: 1059111551 
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7. Relay_Master_Log_File: mysql-bin.013161 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. Exec_Master_Log_Pos: 773131396 
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11. Master_UUID: e7c35a95-ffb1-11e6-9620-90e2babb5b90  
    12.

我們看到，binlog文件落后了64個(gè)，相當(dāng)?shù)目鋸垺?/p>

MySQL 5.7不是已經(jīng)實(shí)現(xiàn)并行復(fù)制了嗎，怎么還會(huì)延遲這么厲害?

先檢查系統(tǒng)負(fù)載。

看到mysqld進(jìn)程其實(shí)負(fù)載還好，不算太高，也不存在嚴(yán)重的SWAP等問(wèn)題。

再看I/O子系統(tǒng)負(fù)載，沒(méi)看到這方面存在瓶頸(await\svctm\%util都不高)。

再看mysqld進(jìn)程的CPU消耗。

雖然mysqld進(jìn)程的CPU消耗總是超過(guò)100%，不過(guò)也不算太高。

再檢查MySQL復(fù)制現(xiàn)場(chǎng)，確認(rèn)了幾個(gè)頻繁更新的表都有主鍵，以及必要的索引。相應(yīng)的DML操作也幾乎都是基于主鍵或唯一索引條件執(zhí)行的，排除無(wú)主鍵、無(wú)合理索引方面的因素。

***只能祭出perf top神器了。

perf top -p `pidof mysqld`

看到perf top***的報(bào)告是這樣的

 
 
 
 
      
  
  
  
  1. Samples: 107K of event 'cycles', Event count (approx.): 29813195000 
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3. Overhead Shared Object Symbol 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5. 56.19% mysqld [.] bitmap_get_next_set 
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7. 16.18% mysqld [.] build_template_field 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. 4.61% mysqld [.] ha_innopart::try_semi_consistent_read 
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11. 4.44% mysqld [.] dict_index_copy_types 
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13. 4.16% libc-2.12.so [.] __memset_sse2 
    14.   
  
  
  
  14.  
    15.   
  
  
  
  15. 2.92% mysqld [.] ha_innobase::build_template  
    16.

我們看到， bitmap_get_next_set 這個(gè)函數(shù)調(diào)用占到了 56.19%，非常高，其次是 build_template_field 函數(shù)，占了 16.18%。

經(jīng)過(guò)檢查MySQL源碼并請(qǐng)教MySQL內(nèi)核開(kāi)發(fā)專(zhuān)家，***確認(rèn)這兩個(gè)函數(shù)跟啟用表分區(qū)有關(guān)系。

查詢(xún)下當(dāng)前實(shí)例有多少個(gè)表分區(qū)：

 
 
 
 
      
  
  
  
  1. yejr@imysql.com:mysql3306.sock : (none) > select count(*) from partitions where partition_name is not null; 
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3. +----------+ 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5. | count(*) | 
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7. +----------+ 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. | 32128 | 
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11. +----------+ 
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13. 1 row in set (11.92 sec)  
    14.

額滴神啊，竟然有3萬(wàn)多個(gè)表分區(qū)，難怪上面那兩個(gè)函數(shù)調(diào)用那么高。

這個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)幾個(gè)大表采用每天一個(gè)分區(qū)方案，而且把直到當(dāng)年年底所有分區(qū)也都給提前創(chuàng)建好了，所以才會(huì)有這么多。

不過(guò)，雖然有這么多表分區(qū)，在master服務(wù)器上卻不存在這個(gè)瓶頸，看起來(lái)是在主從復(fù)制以及大量表分區(qū)的綜合因素下才有這個(gè)瓶頸，最終導(dǎo)致主從復(fù)制延遲越來(lái)越嚴(yán)重。

知道問(wèn)題所在，解決起來(lái)就簡(jiǎn)單了。把到下個(gè)月底前用不到的表分區(qū)全部刪除，之后約只剩下1.6萬(wàn)個(gè)分區(qū)。重啟slave線程，問(wèn)題解決，主從復(fù)制延遲很快就消失了。


新聞標(biāo)題：意想不到的MySQL復(fù)制延遲原因
文章位置：http://m.5511xx.com/article/dhecshs.html