备份脚本需避开mysqldump权限和连接失败两大坑：一是显式指定socket路径并确保用户有读权限，二是授权时匹配host（用localhost而非127.0.0.1）；压缩与清理用find按mtime控制，避免logrotate误判；必须检查dump文件非空、gzip完整性，并用绝对路径、独立配置文件、显式PATH适配cron环境。
备份脚本必须避开 mysqldump 权限和连接失败这两个坑
直接运行 mysqldump 报 Access denied 或 Can't connect to local MySQL server 是最常见问题。根本原因不是密码写错了，而是：MySQL 客户端默认尝试用 socket 连接（/var/run/mysqld/mysqld.sock），但脚本里没指定 --socket 路径，或用户没权限读该 socket 文件；另一个是 root@localhost 和 root@127.0.0.1 在 MySQL 权限表里是两条不同记录，用 -h 127.0.0.1 却没给对应 host 授权就会被拒。
实操建议：
- 先确认 socket 路径：
mysql --help | grep "socket"，常用路径有/var/run/mysqld/mysqld.sock、/tmp/mysql.sock，脚本中显式加--socket=/path/to/socket - 授权时用
CREATE USER 'backup'@'localhost' IDENTIFIED BY 'xxx'; GRANT SELECT, LOCK TABLES ON *.* TO 'backup'@'localhost';，避免依赖root - 连接参数统一用
-h localhost（走 socket）而不是-h 127.0.0.1（走 TCP），除非你明确需要网络连接
压缩与保留策略要用 find + mtime 控制，别信 logrotate 对 SQL 文件的自动处理
logrotate 默认按文件名匹配，对 backup_20240512.sql.gz 这类带日期的文件不敏感，容易误删或漏删。真正可控的方式是用 find 按修改时间清理。
实操建议：
- 备份后立即压缩：
mysqldump ... | gzip > "$backup_dir/backup_$(date +\%Y\%m\%d_\%H\%M).sql.gz" - 保留最近 7 天：
find "$backup_dir" -name "backup_*.sql.gz" -mtime +7 -delete - 注意
mtime是“最后修改时间”，不是“创建时间”；如果文件刚解压又立刻压缩，mtime会更新，导致误判；所以备份脚本里不要做解压操作 - 加
-print先试运行：find "$backup_dir" -name "backup_*.sql.gz" -mtime +7 -print，确认要删的文件无误再加-delete
关键错误得捕获，不能只靠 set -e
set -e 只在命令非零退出时中断，但 mysqldump 遇到部分表导出失败时可能仍返回 0（尤其加了 --force），结果备份文件里缺表却没报警。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
实操建议：
- 每次
mysqldump后检查输出大小：if [ ! -s "$file" ]; then echo "ERROR: empty dump" >&2; exit 1; fi - 用
gzip -t验证压缩完整性：gzip -t "$file" || { echo "ERROR: corrupt gzip" >&2; exit 1; } - 把关键步骤日志重定向到文件并追加时间戳：
echo "$(date): start dump" >> "$log_file"，方便排查哪一步卡住 - 邮件通知别用
mail命令硬编码，改用logger写系统日志，再由rsyslog转发——更可靠
定时执行前必须用 crontab -e 测试环境变量
Cron 环境极其精简：PATH 通常只有 /usr/bin:/bin，mysqldump 如果装在 /usr/local/mysql/bin/ 就根本找不到；而且 cron 不读 ~/.bashrc，export MYSQL_PWD 这类设置全失效。
实操建议：
- 脚本开头显式声明 PATH：
PATH="/usr/local/mysql/bin:/usr/bin:/bin" - 密码绝不用
-p$PASS形式（会被 ps 看见），改用配置文件：mysqldump --defaults-extra-file=/etc/mysql/backup.cnf ...，其中backup.cnf权限设为600，内容：[client] user=backup password=xxx socket=/var/run/mysqld/mysqld.sock
- 先手动执行一遍：
/bin/bash -x /path/to/backup.sh，确认每行都成功；再放进 cron 前加一行* * * * * /bin/bash -c 'echo $PATH' >> /tmp/cron_path.log 2>&1，比对 PATH 差异
实际跑起来你会发现：socket 路径、用户权限、cron 环境这三处一旦配错，脚本就静默失败，连日志都不留。与其反复调试，不如一开始就用绝对路径 + 显式参数 + 独立配置文件。
