2026/2/10 21:15:42
网站建设
项目流程
网站做框架,四川建设网官网地址,成都做公司网站推广,利用ps怎么做网站首页很多数据库事故的真相是#xff1a;
不是没备份#xff0c;而是备份根本用不了。如果你的备份流程是#xff1a;
定时 mysqldump打包成 .sql.gz文件存在就当成功
那这个“备份”#xff0c;本质上只是心理安慰。❗ 问题到底出在哪#xff1f;
因为你从来没有做过这一步不是没备份而是备份根本用不了。如果你的备份流程是定时mysqldump打包成.sql.gz文件存在就当成功那这个“备份”本质上只是心理安慰。❗ 问题到底出在哪因为你从来没有做过这一步真正把备份恢复到数据库里跑一次。事故发生前你不知道事故发生后你不敢赌。 本文只做一件事把「数据库备份」升级成下面这个完整闭环成功失败定时触发导出数据库压缩归档启动临时数据库导入备份执行校验 SQL备份有效备份失败只有走到最后一步备份才算成功。✅ 最终你会得到什么每天凌晨系统会自动完成1️⃣ 真实导出生产数据库2️⃣ 压缩并保存备份文件3️⃣ 启动一份临时 MySQL 实例4️⃣ 把备份完整导入5️⃣ 执行真实业务 SQL 校验6️⃣ 校验通过 → 备份才算“有效”任何一步失败整个任务失败。 项目目录结构db-backup/ ├── backup.sh # 核心备份 恢复校验脚本 ├── verify.sql # 恢复校验 SQL ├── .env # 数据库配置 └── backups/ # 历史备份目录 配置说明.envDB_HOST127.0.0.1 DB_PORT3306 DB_USERbackup DB_PASSWORDbackup_pass DB_NAMEprod_db RETENTION_DAYS7所有配置与脚本分离脚本不改换库直接复用。 恢复校验 SQLverify.sql⚠️ 这是整套方案的核心价值点。-- 核心表是否存在SELECTCOUNT(*)FROMusers;SELECTCOUNT(*)FROMorders;-- 核心字段是否可查询SELECTid,emailFROMusersLIMIT1;-- 近期业务数据是否存在SELECTCOUNT(*)FROMordersWHEREcreated_atNOW()-INTERVAL7DAY;只要任意一条 SQL 执行失败 这个备份 不可用 核心脚本backup.sh完整可用#!/usr/bin/env bashset-euo pipefailBASE_DIR$(cd $(dirname$0)pwd) source ${BASE_DIR}/.env DATE$(date%Y%m%d_%H%M%S)BACKUP_DIR${BASE_DIR}/backups BACKUP_FILE${BACKUP_DIR}/${DB_NAME}_${DATE}.sql.gz mkdir -p ${BACKUP_DIR} echo [1/6]dump database mysqldump \ -h ${DB_HOST} \ -P ${DB_PORT} \ -u ${DB_USER} \ -p${DB_PASSWORD} \ --single-transaction \ --routines \ --triggers \ ${DB_NAME} | gzip ${BACKUP_FILE} echo [2/6]start temporary mysql TMP_CONTAINERmysql-verify-${DATE} docker run -d --rm \ --name ${TMP_CONTAINER} \ -e MYSQL_ROOT_PASSWORDroot \ -e MYSQL_DATABASEverify_db \ mysql:8.0 sleep 20 echo [3/6]restore backup gunzip -c ${BACKUP_FILE} | docker exec -i ${TMP_CONTAINER} \ mysql -uroot -proot verify_db echo [4/6]run verify sql docker exec -i ${TMP_CONTAINER} \ mysql -uroot -proot verify_db ${BASE_DIR}/verify.sql echo [5/6]stop temporary mysql docker stop ${TMP_CONTAINER} /dev/null echo [6/6]cleanup old backups find ${BACKUP_DIR} -type f -mtime ${RETENTION_DAYS} -delete echo backup verified successfully▶️ 一次完整执行流程直观版DockerMySQLMySQLScriptCronDockerMySQLMySQLScriptCron定时执行 backup.shmysqldump 导出启动临时实例导入备份执行 verify.sql校验成功备份完成 手动运行验证chmodx backup.sh ./backup.sh成功输出示例[1/6] dump database [2/6] start temporary mysql [3/6] restore backup [4/6] run verify sql [5/6] stop temporary mysql [6/6] cleanup old backups backup verified successfully⏰ 设置为每日自动执行crontab-e02* * * /opt/db-backup/backup.sh/var/log/db-backup.log21 这套方案和“普通备份”的本质区别未知普通备份文件存在是否能恢复?心理安慰本文方案文件存在真实恢复SQL 校验通过可用备份 最重要的一句话数据库备份的唯一标准你敢不敢用它恢复生产。这套方案的意义就在于你已经恢复过一次了。 后续这类“不是概念、是真正生产闭环的自动化脚本”都会持续整理在《程序员自动化工具箱》。如果你只想要事故发生时真的能救命的方案这个专栏是为你准备的。