主从重同步后盯着 Seconds_Behind_Master?一个 pager 命令,把 show slave status 砍到只剩 3 行

说出来不怕丢人。上周主从又双叒出问题,我重做完同步,接下来干的事特别蠢——

盯着终端,一遍一遍敲 show slave status\G,然后歪着头在满屏输出里找那三行:Slave_IO_Running:、Slave_SQL_Running:、Seconds_Behind_Master:。

Seconds_Behind_Master 还没归 0 的时候,这活儿最折磨人。它归 0 之前你根本不敢走,每刷一次就盼着那个数字小一点。问题是 show slave status\G 一打出来小 60 行,我要看的那三行既不顶头也不压尾,偏偏卡在中间偏下。

屏幕就那么大。每次刷新,光标甩在最底下,我得手动往上滚半屏,才在一堆 Retrieved_Gtid_Set、Executed_Gtid_Set 的 UUID 乱码里把那三行捞出来。一场观察下来,右手食指在滚动条上磨出茧。

真正的折磨不是主从坏了,是你修完之后,还得在 60 行废话里去找 3 行真话。

为什么这么拧巴

根子就一个:show slave status\G 把能报的都报了,但重同步观察期,我只在乎三件事——IO 线程活没活、SQL 线程追没追、落后几秒。其余 50 多行,全是噪声。

我试过几招,都不灵:

• 把终端窗口拉到最大。 屏是够大了,可那三行还是在画面中下部,刷新一次滚一次,治标不治本。
• 在 shell 里 mysql -e "show slave status\G" | grep。 能用，但还要输一次密码，也麻烦。
• 开个 watch 窗口外部轮询。 需要在命令行中使用-pXXXX，会增加密码泄露的风险。多占一个屏,而且每轮重连,Seconds_Behind_Master 的跳动看着没那么连续,心里更没底。

救我的那一行

后来才想起来,MySQL 客户端自带 pager,能把查询结果先过一道管道再显示。我要的不过是把无关行滤掉,所以一个 egrep 就够了:

SQL
mysql> pager cat | egrep -i 'Slave_IO_Running:|Slave_SQL_Running:|Seconds_Behind_Master:';
PAGER set to 'cat | egrep -i 'Slave_IO_Running:|Slave_SQL_Running:|Seconds_Behind_Master:''

mysql> show slave status\G;
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0
1 row in set (0.00 sec)

从那以后,我刷新一次,屏幕上就干干净净这三行。Seconds_Behind_Master 从几百秒一路往下掉,掉到 0,我一眼就看见,关终端走人。

pager 不是什么高深玩意儿,它就是把"你只想看的那点东西"从噪声里拎出来。

之前 vs 现在,对比一下就懂了:

顺手记两个同款用法

同一个 pager,还能干别的脏活:

只看耗时,不看结果。 有时候我就想确认一条慢查询跑多久,不关心它吐了啥:

SQL
mysql> pager cat /dev/null;
PAGER set to 'cat /dev/null'
mysql> show databases;
14 rows in set (0.00 sec)

结果集被丢进黑洞,只剩 N rows in set (x.xx sec)。看完 nopager; 切回去。

数连接里有多少 Sleep。 连接一堆的时候,show processlist 刷半天找不到重点:

SQL
mysql> pager grep Sleep | wc -l
PAGER set to 'grep Sleep | wc -l'
mysql> show processlist;
0
3 rows in set (0.00 sec)

直接给你 Sleep 连接的数量。

一个坑,别踩

pager 一旦设上,后面每一条查询都会被它过一遍。你要是忘了 nopager; 或 \n 切回 stdout,下一条正常查询也会只剩过滤后的残影,容易以为数据丢了。我现在养成习惯:用完立马 nopager;,哪怕多敲一行。

写在最后

这事儿技术含量约等于零,但我绕了 40 分钟的弯路才想起它。

工程师的成长,经常不是学会了多厉害的命令,而是把"明明很简单却一直忍着"的笨办法,换成一行顺手的命令。