1. 备份方案的整体设计并行、限速、永久增量到底怎么组合做DBA这行最怕的不是数据损坏而是备份策略本身就有问题。KingbaseES作为国产数据库里用得比较多的一款很多运维团队一开始用的都是最简单的那种全量备份——每天晚上跑一次数据量小的时候没事等到库涨到几TB问题全来了备份窗口不够、磁盘撑爆、恢复时发现备份链断掉。这套“并行处理 IO 限速 永久增量备份”的组合就是针对这些实际痛点来的。先说说我为什么推荐把这三个东西放在一起讲。并行处理解决的是备份效率问题全量备份单线程跑太慢parallel参数能充分利用多核CPU把大表拆分到多个会话同时读IO限速解决的是备份影响在线业务的问题数据库备份的时候如果磁盘读写太猛生产库的查询响应会明显变慢严重时直接把业务拖垮永久增量备份解决的是备份窗口和存储空间的问题不用每次全量基线之后只做增量而且增量可以一直叠下去配好归档日志后还能做到任意时间点恢复。这三个机制不是孤立存在的。打个比方你开车上高速并行处理就是多车道同时通行IO限速就是限速牌防止超速造成事故永久增量备份则是只记录新跑过的里程不用每次都把整车里程清零重计。三者配合得好备份既能跑得快又不影响边上正常行驶的车辆还能把历史留得足够长。这套方案适合谁如果你正在用KingbaseES V8或者V9版本数据库文件总量在几百GB到几十TB之间业务对备份窗口有硬性要求或者领导开始问“能不能恢复到昨天早上10点半的数据”那你需要把这篇文章看完。我会把每个参数的设置逻辑、命令的执行顺序、以及我踩过的坑都写出来。2. 并行处理不是parallel开得越大越好2.1 并行备份的基本原理KingbaseES的备份工具sys_backup底层用的是物理备份机制备份进程需要把数据库文件从头到尾读一遍。单进程读大文件瓶颈通常在磁盘的顺序读速度上但如果数据库分布在多个磁盘或者文件系统上单进程就没法同时从不同位置取数据。并行备份的原理就是把需要备份的数据文件按一定粒度拆分成多个任务每个任务由独立的备份进程去跑最后合并结果。具体到sys_backup.conf里控制并行的核心参数是PARALLEL_PROCESS。这个参数的值表示同时开启几个备份子进程每个子进程负责备份一部分数据文件。比如一个库有32个数据文件并行度设为8那么每4个文件会分给一个子进程处理。这样总耗时理论上能降到单进程的1/8虽然实际上因为文件大小不均、磁盘争抢等因素达不到这么理想但效果依然非常可观。我遇到过最典型的一个场景客户的生产库大概5TB机械磁盘阵列之前全量备份要跑10个小时备份窗口根本不够。把PARALLEL_PROCESS从默认值调到8之后耗时压到了2小时出头窗口问题直接解决。但注意我并没有继续往16、32去调原因后面细讲。2.2 并行度怎么定才科学并行度的设置一看CPU核心数二看磁盘能力三看备份期间业务负载。很多文档只告诉你“并行度越高越快”实际落地时这个经验害了不少人。我自己的习惯是先看服务器CPU是几核并行度一般不超过核心数的一半。比如32核的机器并行度先给6到8如果是64核给8到12。为什么不直接怼满因为备份进程不只是占CPU还会占内存、占I/O而且备份期间数据库本身还有后台进程在跑你给备份分了太多资源业务SQL就会饿死。再一个看磁盘。如果数据库放在SSD上或者存储是分布式存储池可以适当调高一点如果还是机械盘RAID5这类并行度超出磁盘并发能力后多个进程同时读盘反而会增加寻道开销性能不升反降。判断方法很简单调高并行度跑一次全量观察备份耗时和磁盘util如果util已经到90%以上耗时却没明显缩短那说明瓶颈在磁盘再加大并行度没有意义。还有个容易漏掉的细节并行备份开启后备份临时文件也会并发写入备份目录所以备份盘的速度同样会制约整体效率。如果你的备份目标盘是慢速NFS并行度再高也被写入速度卡死。让我说句实在话——很多备份慢的问题根源在备份盘上不在数据库上。2.3 并行恢复同样值得关注并行不只用于备份恢复过程同样支持并行。sys_backup创建的物理备份集里包含了数据文件列表恢复时可以通过参数让多个文件同时被拷贝和回放。这里的一个关键点在于恢复的并行度和备份时的并行度并不需要完全一致建议恢复并行度按照恢复目标机器配置重新评估而不是照搬备份参数。我经历过一次灾备演练备份时用的parallel8目标恢复机器是16核新机器结果用默认并行度恢复全量恢复耗时比备份还长一度让我怀疑备份集有问题。后来发现是恢复机的磁盘延迟偏高并行进程一多反而互相干扰把并行度调到4之后恢复了正常。这件事给我的教训是参数是给人用的不是给文档看的一切以实测为准。3. IO限速让备份不打扰生产系统3.1 为什么必须限速数据库备份要读大量数据文件这种密集的顺序读会抢占磁盘I/O带宽。对于纯OLTP业务来说大量小随机读本身就需要磁盘快速响应备份流量一来磁盘队列深度被占满业务SQL的延迟立刻飙升。我接手过一个系统上线备份功能后第二天就收到业务投诉——页面打开慢了好几个量级一查就是备份导致的I/O抢占。IO限速解决的就是这个问题。KingbaseES的备份工具支持设置备份过程的读写速率上限让备份流量像一个谦让的住户不走高速高峰慢慢来但稳定到达。代价是备份时间会变长但换来的业务稳定这笔账是划算的。限速的默认单位是MB/s比如设置MAX_RATE100表示备份进程整体最多占用100MB/s的I/O带宽。这个值是所有并行子进程加起来的总上限不是每个子进程单独的上限这点一定要搞清楚不然你以为限了速实际每个进程都在跑满速总量早就超了。3.2 限速值怎么算限速值我用这个思路来定先看备份期间业务允许让出多少I/O。如果生产磁盘阵列整体能扛200MB/s的顺序读业务高峰期实测占用50MB/s那备份限速可以设在100到150MB/s之间留出余量防止突发流量。公式可以这样参考备份限速上限 磁盘总带宽 × 40% ~ 60%。保守一点就取40%业务比较闲的时候可以放到60%。设置完跑一次全量通过iostat观察%util如果业务高峰时段磁盘util已经到80%以上就调低MAX_RATE。另外要注意一点MAX_RATE影响的是读端。如果你备份的同时还开了压缩压缩过程会消耗CPU但不会额外增加I/O所以限速值不需要因为开启压缩而调整。相反如果备份端同时往备份盘写入和从源库读取写入端慢的话读端的限速值就要结合备份盘的写能力来综合判断否则容易在备份目录堆积大量未写完的临时文件。3.3 限速和并行一起设置的效果并行和限速同时配置看起来有点矛盾并行是加速的限速是降速的两者怎么平衡其实它们作用在不同层面并行解决的是“多任务协同”的问题限速解决的是“总量可控”的问题。设置并行度8、MAX_RATE200效果就是8个进程同时跑但总I/O不会超过200MB/s。这个过程相当于高速公路上开放8条车道但入口统一限流保证不会堵死别的路。实际配置时我建议先定限速值再根据限速值反推并行度。比如磁盘带宽200MB/s限速100MB/s每个备份进程平均也就分到12MB/s的吞吐并行度设到8是完全够用的设到16反而每个进程分到的吞吐过低增加了线程切换开销而几乎没有收益。4. 永久增量备份理解原理才能不踩坑4.1 永久增量到底是个什么机制先说清楚概念永久增量备份不是“永远只做增量不做基线”而是“以一次全量作为基线后续所有备份都是增量且增量之间可以无限累积”。每次增量备份都记录自上一次备份以来变化的数据块恢复时按照“全量 增量1 增量2 … 增量N”的顺序依次应用最终得到最新数据。KingbaseES的物理增量备份是基于WAL归档机制实现的。数据库在运行中产生的每一条变更都会写入WAL日志sys_backup在做增量备份时会先记录当前数据文件的整体状态然后借助WAL日志把变化的部分提取出来形成一个增量备份集。增量备份集比全量备份小得多备份时间也快得多所以可以频繁执行比如每天一次甚至在业务低峰期每小时一次。永久增量备份的价值在于备份窗口和存储成本的降低。假设数据库1TB每天变化量10GB如果每天全量一周就要7TB备份空间而“周一全量 周二到周日各10GB增量”的方案总空间只有1TB加上60GB空间节省非常可观。4.2 增量链的完整性和风险增量备份的核心风险在于增量链的连续性——链条上任何一个增量备份集损坏或者丢失后续所有增量全部无法使用。这就是为什么讲永久增量备份的时候我格外强调备份集校验和定期恢复演练。另外一个容易忽视的点是增量备份集依赖全量基线基线如果过期被清理增量就成了孤儿。备份策略中要设计基线的保留策略比如保留最近2份完整基线配合近30天的增量集这样即使最新一份基线损坏还有前一份基线可以接上。我还建议对增量备份做异地副本同步。本地备份集raid损坏的情况虽然少但一旦发生影响是灾难性的。增量集体积小同步成本低利用定时任务把增量备份目录rsync到另一台机器或者对象存储这个操作性价比极高。4.3 永久增量配合时间点恢复永久增量备份集加连续WAL归档日志就可以实现时间点恢复PITR。原理是先恢复到最近一次增量备份完成时的状态然后重放该时间点之后的WAL日志直到目标时间点为止。这比“恢复到备份时刻”更进一步能应对“10秒前误删了一张表”这类事故。时间点恢复的前提是WAL归档是连续不断的。所以备份策略要把数据库的归档配置打开确保每一份WAL日志都有归档副本。很多团队只做备份没开归档出问题时才发现只能恢复到备份时刻误删之后的所有操作全丢了这种情况我见得太多了。5. 完整实操流程从环境准备到首次增量备份5.1 部署前绕不开的准备项KingbaseES装完后的第一件事很多人会卡在登录上。这里说两个和本文主题间接相关但特别关键的准备工作。第一是初始密码。KingbaseES安装过程中会让用户为system超级用户设置密码没有固定默认值。如果你是用一键脚本部署并且跳过了设置步骤密码可能被写在安装日志里。登录失败时的排查顺序是确认是否区分大小写、确认是否在命令中加了空格、最后检查安装目录下的日志文件看看有没有初始化的痕迹。忘记密码的处理办法是用单用户模式重置这个操作建议提前做好方案。第二是授权文件。KingbaseES需要有效的license文件才能正常运行试用版授权可以从官网申请下载。备份工具本身在授权有效期内才允许执行备份和恢复操作如果license过期后备份任务报错不要怀疑备份配置问题先检查授权状态。授权文件下载后放到安装目录的对应位置并确认环境变量指向正确否则会出现工具能启动但授权读取失败的诡异问题。这些基础项排查干净再往下走备份配置否则备份脚本跑到一半报权限或授权错误排错非常痛苦。5.2 sys_backup.conf核心参数配置KingbaseES的备份工具通过一个配置文件控制所有行为路径一般在kingbase/etc/sys_backup.conf。核心配置我按分类整理如下参数说明建议值TARGET_DB_HOST源库地址本机可填127.0.0.1TARGET_DB_PORT源库端口按实际端口填写TARGET_DB_USER备份用户建议使用具有备份权限的专用账号TARGET_DB_PASSWORD备份用户密码建议加密保存BACKUP_MODE备份模式全量填FULL增量填INCREMENTALPARALLEL_PROCESS并行度先按CPU核心数一半预估MAX_RATEIO限速(MB/s)按磁盘带宽的40%-60%COMPRESS_LEVEL压缩级别0-9推荐3-5平衡速度与空间配置文件的路径和参数在不同小版本里略有差异修改前务必先备份原文件。参数生效方式是重新执行备份命令不需要重启数据库服务这个设计对在线操作很友好。5.3 首次全量加多次增量的命令序列初始化备份环境后整个操作流程是这样执行全量备份sys_backup.sh init -U sys_backup -W 密码这个命令会创建备份目录结构并开始第一次全量备份。确认全量备份完成后查看备份集列表确认BASELINE信息。执行增量备份sys_backup.sh incremental系统会自动判断上一个备份集的LSN位置只备份变化的数据块。按业务节奏持续执行增量备份每次增量都会在上一个备份集之后追加。我实际操作中喜欢把增量备份做成crontab定时任务每天凌晨2点跑一次。第一次跑之前先手动执行一次确认日志输出正常再交给调度系统。定时任务执行时注意环境变量crontab里PATH往往不完整最好在脚本开头source数据库用户的环境变量文件。这个坑我同事踩过——命令手动跑一切正常crontab里跑就报找不到命令最后发现是PATH问题。5.4 恢复演练验证增量链是否可靠备份做得再好恢复不了等于白做。恢复操作我建议每季度至少演练一次而且必须是“破坏性演练”——把备份集恢复到一台独立的测试机器上确认数据可用后再销毁。恢复流程概要是# 停止目标实例防止数据文件被占用 sys_ctl stop -D 数据目录 # 执行恢复命令指定备份集ID sys_backup.sh restore -U sys_backup -W 密码 -D 数据目录 # 按需回放到指定时间点 # 完成后启动数据库并检查一致性 sys_ctl start -D 数据目录恢复完成后重点检查三件事数据库能否正常启动、关键业务表的数据是否完整、最后一次增量之后的事务是否已经包含。只检查启动成功是不够的——我就见过一次恢复演练数据库启动正常但某张核心业务表的最后一批数据丢了就是因为增量备份集有缺失没被发现。6. 常见问题与避坑技巧速查6.1 我整理的高频问题清单备份相关的坑很多是重复出现的。下面这几个问题基本覆盖了我处理过的大部分备份故障现象可能原因排查方向备份执行报权限不足备份用户缺少备份权限检查sys_backup用户角色权限MAX_RATE不生效参数单位理解错误或参数未重载确认MB/s换算重新执行备份命令增量备份集异常巨大有大量临时表或未清理的膨胀数据检查数据库膨胀率先执行vacuum再备份恢复后时间点不正确归档日志不连续检查WAL归档目录是否有缺失备份突然中断磁盘空间不足检查备份目录空间及时清理旧备份集6.2 几个必须上心的小细节关于并行度我再强调一次不要超配。32核机器设parallel16实际跑起来CPU使用率能到90%以上业务高峰时这种配置等于自杀。建议先在业务低峰期做一次24小时监控了解当前CPU基线和磁盘util再定参数。关于限速MAX_RATE设定后备份耗时可以通过备份数据量 ÷ 限速值来粗估。比如数据量500GB限速100MB/s理论耗时就是500000MB ÷ 100MB/s ≈ 5000秒约1.4小时。如果实际耗时远超这个估算值说明瓶颈不在限速上要检查是否有其他进程在争抢I/O。关于增量备份最重要的建议是高频增量搭配低频全量。全量基线建议至少保留两份增量集按保留窗口滚动清理。清理时用工具提供的删除功能不要手动删目录文件——手动删除会破坏备份集间的引用关系恢复时会报找不到某个文件。最后分享一个习惯每次备份完成后我都习惯性地看一眼备份日志的结尾几行确认backup completed successfully这样的字样出现而不是看完命令返回值就离开。备份这件事机器出错的概率远低于人出错定时任务配上日志监控才是真正靠谱的运维方式。