BE磁盘坏了数据还在不在?——Doris数据备份恢复和容灾方案
本文目录
先说结论
Doris的数据保护有三个层面:① 多副本机制(日常容灾,单BE故障自动恢复);② Backup/Restore(定期备份到HDFS/S3,防止人为误删和灾难恢复);③ 回收站机制(DROP TABLE后有72小时恢复窗口)。生产环境至少要做到3副本+定期Backup。
先把这段讲顺;面试官追问时,再展开下面的原理和细节。
详细讲解
在某元宇宙社交公司,有一次凌晨3点BE-2的一块SSD报了坏扇区告警。当时心里一紧:上面有好几张核心表的Tablet副本。好在我们配了3副本,即使BE-2下线,其他两个BE上还有完整的数据副本,查询不受影响。但这次事件让我开始重视备份——如果3个BE的同一个Tablet全挂了呢?如果有人误删了表呢?这些极端场景必须有预案。
第一层保护:多副本机制
-- 查看表的副本数
SHOW CREATE TABLE dwd_user_event;
-- 找 replication_num = 3
-- 建表时指定副本数
CREATE TABLE dwd_user_event (
event_time DATETIME,
user_id BIGINT,
event_name VARCHAR(128)
) DUPLICATE KEY(event_time, user_id)
DISTRIBUTED BY HASH(user_id) BUCKETS 16
PROPERTIES ('replication_num' = '3');
-- 副本数设置建议:
-- 3副本:生产环境标配(任意1个BE故障不影响服务)
-- 2副本:测试环境或成本敏感场景
-- 1副本:开发环境(BE挂了数据就丢了)
-- 查看哪些Tablet有副本缺失
ADMIN SHOW REPLICA STATUS FROM dwd_user_event;
第二层保护:Backup/Restore——定期备份
-- 创建仓库(指向S3/HDFS存储位置)
CREATE REPOSITORY backup_repo
WITH S3
ON LOCATION 's3://my-bucket/doris-backup'
PROPERTIES (
'AWS_ENDPOINT' = 's3.us-west-2.amazonaws.com',
'AWS_ACCESS_KEY' = 'xxx',
'AWS_SECRET_KEY' = 'xxx'
);
-- 执行备份(按数据库或按表)
BACKUP SNAPSHOT mydb.snapshot_20240115
TO backup_repo
ON (dwd_user_event, dim_user, dws_daily_overview);
-- 查看备份状态
SHOW BACKUP FROM mydb;
-- 恢复(误删后的救命操作)
RESTORE SNAPSHOT mydb.snapshot_20240115
FROM backup_repo
ON (dwd_user_event)
PROPERTIES ('replication_num' = '3');
第三层保护:回收站机制
-- 误删了表
DROP TABLE dwd_user_event;
-- 在72小时内可以恢复!
RECOVER TABLE dwd_user_event;
-- 查看回收站里有哪些表
SHOW CATALOG RECYCLE BIN;
-- 修改回收站保留时间(在fe.conf中)
-- catalog_trash_expire_second = 259200 (默认72小时)
-- 建议:生产环境设成7天(604800秒)
-- 注意:TRUNCATE TABLE不进回收站!
-- TRUNCATE是清空数据但保留表结构,数据直接删除无法恢复
-- 所以TRUNCATE权限一定要严格控制(参考第15篇权限管理)
实战经验:我在某元宇宙社交公司的容灾方案
| 保护手段 | 配置 | 防什么 | 恢复时间 |
|---|---|---|---|
| 3副本 | replication_num=3 | 单BE硬件故障 | 秒级(自动切换) |
| 每日Backup | 凌晨3点备份到S3 | 人为误删表 | 分钟到小时 |
| 回收站 | 保留7天 | 误DROP TABLE | 秒级(RECOVER) |
| Flink Checkpoint | Kafka offset保存 | 流式写入中断后重跑 | 分钟级 |
| S3离线存储 | 历史数据存S3 | Doris集群全毁 | 小时级(重新导入) |
实战踩坑:副本缺失导致的数据不安全
有一次某元宇宙社交公司的一台BE磁盘满了(第13篇扩容那次),我临时把一些冷表的副本数从3调到了2来腾空间。过了两周忘了改回来,这时候另一台BE也出了问题——某些Tablet的2个副本分别在这两台BE上,差点只剩1个可用副本。
教训:① 生产环境核心表永远不要降副本数;② 定期跑ADMIN SHOW REPLICA STATUS检查副本缺失;③ 把副本数检查加入监控报警。
面试高频追问
追问一:Doris的备份是全量还是增量?
Doris的Backup是快照备份——备份时点的全量数据。不支持增量备份。大表建议按表分别备份,核心表每天备份,大表可以每周备份一次。
追问二:BE恢复后数据怎么自动补齐?
BE宕机期间如果有Tablet副本数不足,Doris会自动在其他BE上创建新副本补齐。BE恢复后旧副本会从Leader副本拉取增量数据追平。整个过程自动完成。
追问三:Doris支持跨机房容灾吗?
原生不支持跨机房双活。可以通过Flink双写两个集群实现:主集群读写,备集群只写,主集群故障时切换。也可以用Backup/Restore做跨集群同步。
总结
Doris数据保护面试讲三层:① 多副本(日常容灾);② Backup/Restore(定期备份到S3);③ 回收站(DROP TABLE后72小时可恢复,TRUNCATE不进回收站)。核心教训:不要降副本数、定期检查副本状态、备份像保险不能不买。
下一篇聊Doris的SQL优化技巧:除了分区裁剪和索引,还有哪些SQL层面的优化?
你们Doris做了数据备份吗?用什么方案?评论区聊聊~
关注「Wood聊大数据」| 9年大数据老兵,聊技术、聊职场、聊成长