MySQL 運維自動化：三大核心 Shell 腳本實戰分享

前言

生產環境 MySQL 運維離不開自動化腳本。本文分享三個實戰驗證的 Shell 腳本：Memcached 服務管理、Binlog 自動清理、主從同步自動修復，涵蓋高可用架構核心運維場景。

腳本一：Memcached 系統服務管理腳本

特性

• 支援 start|stop|restart|condrestart|reload|status 標準服務命令
• 自動偵測網卡 IP 綁定（eth1）
• 完整的 PID/鎖文件管理，支援 chkconfig 開機自啟

關鍵配置區塊

IPADDR=`/sbin/ifconfig eth1 | awk -F ':' '/inet addr/{print $2}' | sed 's/[a-zA-Z ]//g'`
PORT="11211"
USER="root"
SIZE="2048"           # 記憶體 2GB
CONNNUM="51200"       # 最大連接數
BINFILE="/usr/local/memcached/bin/memcached"
PIDFILE="/var/run/memcached.pid"
LOCKFILE="/var/lock/subsys/memcached"

部署命令

chmod +x /etc/init.d/memcached
chkconfig --add memcached
chkconfig --level 235 memcached on
service memcached start

腳本二：MySQL Binlog 自動清理腳本（主庫端運行）

核心邏輯

1. 檢查主從同步狀態（Slave_IO_Running=Yes 且 Slave_SQL_Running=Yes）
2. 驗證從庫可連通、同步延遲正常（Seconds_Behind_Master=0）
3. 建立測試資料庫驗證同步鏈路完整
4. 智能判斷當前最舊可清理的 Binlog 文件：

   # 三種同步場景判斷邏輯
   if [[ "${SLAVE_BINLOG1}" = "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]]; then
       CURR_BINLOG="${MASTER_BINLOG}"           # 主從完全同步
   elif [[ "${SLAVE_BINLOG1}" = "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" != "${MASTER_BINLOG}" ]]; then
       CURR_BINLOG="${SLAVE_BINLOG1}"           # 從庫追趕中
   elif [[ "${SLAVE_BINLOG1}" != "${SLAVE_BINLOG2}" && "${SLAVE_BINLOG1}" = "${MASTER_BINLOG}" ]]; then
       CURR_BINLOG="${SLAVE_BINLOG2}"           # Relay log 尚未追上
   else
       exit 1  # 異常狀態
   fi

5. 執行 PURGE BINARY LOGS TO 'CURR_BINLOG' 安全清理

定時任務配置

# 每天凌晨 5:30 執行
30 05 * * * /data/scripts/delete_mysql_binlog.sh >/dev/null 2>&1

腳本三：MySQL 主從同步自動修復腳本

修復流程

1. 檢測 MySQL 進程存活
2. 自動定位 relay-log 路徑與 master.info 文件
3. 讀取主庫同步座標（REPLI_BINLOG_FILE, REPLI_IPADDR, REPLI_USER, REPLI_PWD）
4. 清理損壞的 Relay Binlog：rm -rf ${RELAY_BINLOG_PATH}/*-relay-bin.*
5. 重置同步位點至 Binlog 起始位置：

   CHANGE MASTER TO
       MASTER_HOST='${REPLI_IPADDR}',
       MASTER_USER='${REPLI_USER}',
       MASTER_PASSWORD='${REPLI_PWD}',
       MASTER_LOG_FILE='${REPLI_BINLOG_FILE}',
       MASTER_LOG_POS=0;

6. 啟動同步並進入監控迴圈：
   • 同步報錯 → 記錄錯誤 → SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1 跳過錯誤 → 重試
   • 同步追上（IO/SQL=Yes 且 Seconds_Behind_Master=0） → 記錄成功 → 退出

生產環境部署建議

• 權限最小化：腳本使用專用監控帳號（check_binlog），僅授予 REPLICATION CLIENT、SUPER 權限
• 日誌審計：所有操作記錄至 /data/logs/，便於事後追蹤
• 測試先行：非生產環境完整驗證腳本邏輯，特別是 Binlog 清理判斷邏輯
• 告警聯動：腳本異常退出時觸發監控告警（如發送郵件/企業微信）

結語

這三個腳本覆蓋了緩存服務管理、存儲空間回收、高可用自愈三大核心運維場景。實際部署時請根據架構拓撲（如多從庫、GTID 模式）調整判斷邏輯，並建立完善的變更管理流程。