MySQL主從延遲分析

標籤：mysql

Step1 : iostat 查看IO情況

 iostat -x 1 查看IO情況,哪個磁碟的IO負載較高，接下來我們就來定位具體的負載來源

Step2： iotop定位負載來源進程

 iotop的本質是一個python指令碼，從proc中擷取thread的IO資訊，進行匯總。

 從可以看出大部分的IO來源都來自於mysqld進程。因此可以確定dfa的負載來源是資料庫

Step3 pt-ioprofile定位負載來源檔案

 pt-ioprofile的原理是對某個pid附加一個strace進程進行IO分析。

以下是摘自官網的一段警示：

 However, it works by attaching strace to the process using ptrace(), which will make it run very slowly until strace detaches. In addition to freezing the server, there is also some risk of the process crashing or performing badly after strace detaches from it, or indeed of strace not detaching cleanly and leaving the process in a sleeping state. As a result, this should be considered an intrusive tool, and should not be used on production servers unless you are comfortable with that.

通過ps aux|grep mysqld 找到 mysqld進程對應的進程號，通過pt-ioprofile查看哪個檔案的IO佔用時間最多。

預設參數下該工具展示的是IO佔用的時間。

pt-ioprofile --profile-pid 3082

對於定位問題更有用的是通過IO的輸送量來進行定位。使用參數 --cell=sizes，該參數將結果已 B/s 的方式展示出來

pt-ioprofile --profile-pid 3082 --cell

第一種：表未建主鍵和二級索引（排查最容易忽略的情況）

如，當sql_thread在重放relay log時會根據表是否有主鍵（註：這就是為什麼建表必須要有主鍵原因之一）和二級索引來判斷是否全表掃描

650) this.width=650;" src="https://s4.51cto.com/wyfs02/M02/A7/14/wKioL1ngWaSSKD68AAA9z-Eaj4A708.png-wh_500x0-wm_3-wmp_4-s_2269621050.png" title="從庫複製原理" alt="wKioL1ngWaSSKD68AAA9z-Eaj4A708.png-wh_50" />

在MySQL5.6中提供了一個新的參數：slave_rows_search_algorithms, 可以部分解決無主鍵表導致的複寫延遲問題，其基本思路是對於在一個ROWS EVENT中的所有前鏡像收集起來，然後在一次掃描全表時，判斷HASH中的每一條記錄進行更新；

slave_rows_search_algorithms由三個值的組合組成：TABLE_SCAN，INDEX_SCAN， HASH_SCANTABLE_SCAN,INDEX_SCAN  (預設配置，表示如果有索引就用索引，否則使用全表掃描)

使用組合包括：

INDEX_SCAN,HASH_SCAN

TABLE_SCAN,HASH_SCAN

TABLE_SCAN,INDEX_SCAN,HASH_SCAN(等價於INDEX_SCAN, HASH_SCAN)

未完待續。。。。。

本文出自 “個人的家” 部落格，請務必保留此出處http://8184738.blog.51cto.com/8174738/1972083

MySQL主從延遲分析