在 CentOS 中备份 Trigger 的实用方案
一、先明确你的 Trigger 类型
- 数据库触发器 Trigger：指 MySQL/MariaDB 中的 DML 触发器，依附于表，随库/表迁移而迁移。
- 系统级触发器：指 inotify 这类“文件变化即触发”的机制，用于执行同步/备份脚本，本身不是可备份的数据对象。
二、MySQL/MariaDB 触发器的备份与恢复
- 推荐方式一：逻辑导出包含触发器的表或整个库
- 备份单个库（包含触发器、存储过程、事件等）：
- 命令：mysqldump -u用户名 -p --routines --triggers --single-transaction --hex-blob --set-gtid-purged=OFF 数据库名 > db_backup.sql
- 说明：选项 –triggers 默认已启用；–routines 一并导出存储过程/函数；–single-transaction 减少锁表影响；–hex-blob 更安全地处理二进制字段。
- 备份单表（含触发器）：
- 命令：mysqldump -u用户名 -p --triggers --single-transaction 数据库名 表名 > table_backup.sql
- 恢复：mysql -u用户名 -p 目标库 < db_backup.sql
- 推荐方式二：仅导出/导入触发器定义
- 导出所有触发器：mysqldump -u用户名 -p --no-data --no-create-info --triggers --skip-routines --skip-events 数据库名 > triggers_only.sql
- 导出指定表的触发器：mysqldump -u用户名 -p --no-data --no-create-info --triggers 数据库名 表名 > table_triggers.sql
- 说明：使用 –triggers 配合 –no-data 可只得到 CREATE TRIGGER 语句，便于审计或迁移到已有表结构。
- 备份策略建议
- 将触发器脚本纳入版本控制（如 Git），与表结构脚本一起管理。
- 与生产库一致的备份窗口执行导出，避免结构变更导致不一致。
- 定期在测试环境恢复验证触发器可用性（含 RENAME TABLE、分表、主从切换等场景）。
三、文件系统事件触发器的备份与恢复（inotify）
- 这类“触发器”本质是监控脚本（如 inotifywait + rsync），应备份其脚本与配置，而非“事件”本身。
- 备份清单
- 脚本与配置：/root/shell/rsync.sh、/etc/rsyncd/rsyncd.secrets（权限应为 600）、相关 systemd 服务/定时器单元文件。
- 示例 inotifywait 用法（用于理解备份对象）：
- inotifywait -m /path/to/dir -e create -e delete | while read path action file; do …; done
- 恢复与验证
- 在新主机安装 inotify-tools：yum install -y inotify-tools
- 恢复脚本与密钥，按原参数启动；用 inotifywait 的 -m（monitor）模式观察事件是否能被捕获，并做一次真实文件变更验证同步是否触发。
四、定时触发备份的通用做法（可选）
- 使用 cron 定时执行备份脚本（适合数据库与文件系统的定时备份）
- 示例（每天 02:00 备份 /data 并压缩）：
- 0 2 * * * tar czf /backup/data_$(date +%F).tar.gz /data
- 使用 systemd Timer 替代 cron（更现代的定时/事件能力）
- 示例 Timer：OnCalendar=--* 02:00:00；配合对应的 Service 单元执行备份脚本。
- 如需跨机自动传输，可在脚本中加入 scp 或使用 rsync over SSH，并提前配置 SSH 免密登录 以免交互阻塞定时任务。