debian服务器定时运维保障数据库稳定运行

Debian服务器在长期运行数据库服务时，最容易被忽视的往往不是初始部署，而是定时运维策略的缺失。很多人把数据库装好、业务跑通之后就再也不管，直到某天凌晨磁盘写满、日志膨胀、备份失效或者表损坏才紧急处理。要保障数据库稳定运行，核心思路是把“被动救火”转成“主动巡检”，用cron定时任务把检查、清理、备份、监控串成一套自动化的运维动作。下面直接讲具体的执行方案和配置细节。

Debian 11和12默认都带有cron，但如果你希望任务执行更可控、日志更规范，建议优先考虑systemd timer。systemd timer可以精确控制执行间隔、随机延迟、持久化触发，并且每次执行都有独立的日志记录，便于排查问题。创建一个定时器需要两个文件，一个是service单元，一个是timer单元。比如要每小时检查一次MariaDB的运行状态，可以先写/etc/systemd/system/db-health.service：

[Unit]
Description=Database health check
After=network.target mariadb.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/db-health-check.sh
User=root

再创建/etc/systemd/system/db-health.timer：

[Unit]
Description=Run database health check hourly

[Timer]
OnBootSec=5min
OnUnitActiveSec=1h
RandomizedDelaySec=60
Persistent=true

[Install]
WantedBy=timers.target

启用方式很简单，执行systemctl enable db-health.timer --now即可。Persistent=true的作用是如果服务器在计划执行时间处于关机状态，下次启动后会立即补跑一次，这对数据库运维非常关键，能避免漏检。

数据库稳定运行的第一道防线是备份，但备份不是每天全量打包那么简单。对于MariaDB或PostgreSQL，建议采用“每日全量+每小时增量”的分层策略。Debian上常用的工具是mariabackup和pg_basebackup，配合binlog或WAL日志做增量恢复。全量备份脚本可以放在/etc/cron.daily/目录下，Debian默认会通过run-parts执行该目录中的脚本。一个完整的MariaDB全量备份脚本示例：

#!/bin/bash
BACKUP_DIR="/backup/mariadb/full"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_DIR/$DATE
mariabackup --backup --target-dir=$BACKUP_DIR/$DATE --user=backupuser --password='strongpass' --compress
if [ $? -eq 0 ]; then
    find $BACKUP_DIR -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;
fi

增量备份则要结合binlog。在MariaDB配置中开启log_bin，然后每小时执行一次mysqladmin flush-logs，把当前binlog归档到备份目录。注意不要只备份数据库文件，还要定期验证备份可恢复性。建议每月安排一次恢复演练，把备份拉到测试机做还原，确认备份不是“安慰剂”。

数据库日志是磁盘占用的主要来源之一。Debian自带的logrotate可以处理大部分系统日志，但数据库的慢查询日志、错误日志、binlog往往需要单独配置。对于MariaDB，可以在/etc/logrotate.d/下新建一个配置文件：

/var/log/mysql/mariadb-slow.log /var/log/mysql/mariadb-error.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 640 mysql adm
    postrotate
        systemctl kill -s HUP mariadb.service
    endscript
}

binlog不能简单用logrotate处理，因为数据库自身管理binlog的写入和清理。建议在数据库配置中设置expire_logs_days=7或binlog_expire_logs_seconds=604800，让数据库自动清理过期binlog。同时每周定时检查数据目录的磁盘使用率，超过80%就触发告警。可以用df配合awk写一个简单的检查脚本，放入cron.weekly。

数据库稳定运行不只是“不宕机”，性能劣化同样致命。定时采集慢查询日志并分析，能提前发现索引缺失和SQL效率问题。在MariaDB中开启slow_query_log，设置long_query_time=2，然后每天凌晨用pt-query-digest分析前一天的慢查询，把结果发到运维邮箱或者写入本地报告目录。Debian安装percona-toolkit后可以直接使用：

pt-query-digest /var/log/mysql/mariadb-slow.log --since=24h > /var/reports/slow-query-report.txt

除了慢查询，还要定时采集连接数、缓冲池命中率、临时表使用情况等指标。可以写一个SQL脚本，每小时执行一次，把结果追加到CSV文件，方便后续画趋势图。重点监控Threads_connected、Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads的比值、Created_tmp_disk_tables的增长速度。这些指标如果出现异常波动，往往意味着业务量变化或SQL写法有问题。

InnoDB表在频繁更新和删除后会产生页碎片，虽然现代InnoDB的碎片影响不如MyISAM时代严重，但定期执行OPTIMIZE TABLE或ALTER TABLE ... ENGINE=InnoDB仍然有助于回收空间和重建索引。注意OPTIMIZE TABLE会锁表，对于大表要谨慎，建议在业务低峰期执行。可以写一个脚本，每周日凌晨对超过一定碎片率的表做维护。判断碎片率可以通过查询information_schema.tables中的DATA_FREE字段：

SELECT TABLE_NAME, DATA_FREE FROM information_schema.TABLES 
WHERE TABLE_SCHEMA='yourdb' AND DATA_FREE > 100*1024*1024;

对于PostgreSQL，对应的操作是VACUUM和ANALYZE。Debian上PostgreSQL默认开启了autovacuum，但大表更新频繁时，自动清理可能跟不上，需要定时手动执行VACUUM ANALYZE。建议每天凌晨对核心业务表执行一次，防止事务ID回卷和统计信息过期。

定时运维的最后一环是把检查结果转化为可执行的告警和自愈动作。Debian上可以配合mailutils发送告警邮件，或者使用ntfy、Telegram Bot等轻量通知渠道。自愈脚本要谨慎设计，只处理明确无副作用的场景，比如自动清理临时文件、自动重启僵死的连接池、自动kill长时间未提交的事务。对于需要人工判断的问题，比如主从延迟、磁盘即将写满、备份失败，只告警不自动处理。

一个实用的自愈脚本示例，用于自动终止超过300秒的未提交事务：

#!/bin/bash
mysql -e "SELECT ID FROM information_schema.PROCESSLIST WHERE COMMAND='Sleep' AND TIME>300 AND USER!='system user'" -N | while read id; do
    mysql -e "KILL $id"
done

把这个脚本放入cron，每10分钟执行一次。同时配合监控脚本检查主从状态，如果Seconds_Behind_Master超过阈值就发送告警。对于使用systemd的服务，还可以利用Restart=on-failure和WatchdogSec参数实现进程级自愈，但数据库服务不建议设置过于激进的自动重启，以免掩盖深层问题。

Debian的unattended-upgrades可以自动安装安全更新，但数据库相关包需要单独配置。建议在/etc/apt/apt.conf.d/50unattended-upgrades中明确包含mariadb、postgresql相关的源，并设置只在每周日凌晨自动安装。更新前一定要确保备份完整，因为数据库大版本升级可能涉及数据文件格式变化。更稳妥的做法是每月手动执行一次apt update和apt upgrade，先在测试环境验证，再上生产。

数据库的稳定运行从来不是靠某一个工具或某一条命令，而是靠一整套定时执行的运维动作持续叠加。Debian服务器提供了cron、systemd timer、logrotate、unattended-upgrades等成熟组件，把它们和数据库自身的备份、日志、维护机制结合起来，就能把大部分风险挡在发生之前。关键是不要只配置不验证，每个定时任务都要有执行日志和失败告警，每项备份都要定期做恢复测试，这样定时运维才真正有意义。