作者：任坤
現居珠海，先後擔任專職 Oracle 和 MySQL DBA，現在主要負責 MySQL、mongoDB 和 Redis 維護工作。
本文來源：原創投稿
*愛可生開源社群出品，原創內容未經授權不得隨意使用，轉載請聯絡小編並註明來源。
1、背景
線上某核心 MySQL ，版本為 5.6，本地機房1主2從，同時部署了一個異地從庫。
從2月14號起異地從庫開始報警複製延遲，一開始以為是網路波動導致就沒有處理，但是2天后該報警依然存在且延遲越來越高。
2、診斷
登入該異地從庫，首先甄別是不是IO複製執行緒引發的延遲。
該步驟很簡單，檢視 show slave status 的 Master_Log_File 是不是主庫當前的 binlog ，如果是說明IO複製執行緒沒有延遲，那就是 SQL 複製 執行緒引起的。
獲取該 mysqld 的程式 ID ，執行 perf record -ag -p 11029 -- sleep 10; perf report
反覆執行多次，每次都有 deflate_slow 且佔據比例最高
將其展開，和壓縮頁有關聯
pstack 11029 多次抓取現場，也是和壓縮頁有關。
該例項確實有個大表，並且只有異地從庫開啟了頁壓縮，將其行格式轉為 dynamic 。
檢視 Seconds_Behind_Master，延遲指標開始逐步下降，說明該方案生效了。
再次抓取 perf 和 pstack 現場。
--perf report
--pstack
可以看到和頁壓縮相關的 API 已經消失，再次確認了本次複製延遲和大表開啟頁壓縮有直接關係。
3、小結
藉助 perf 和 pstack 工具，能很快定位是壓縮表引發的 SQL 執行緒複製延遲，將大表解壓縮後最終解決該問題。