★ FEATURED ARTICLE 简介这份PDF手册是迪思杰DSG RealSync复制系统安装配置指南的归纳版围绕数据实时与定时同步场景适合数据库运维、开发及容灾实施人员作为部署参考用于解决多站点数据一致性、备份恢复和灾难恢复中的复制配置问题。压缩包共含1个PDF文件大小1.19MB内容覆盖源端与目标端的安装全流程包括安装前准备、用户/目录/视图创建、RealSync软件安装、Agent启动与日志查看以及注册主机数据库信息、验证配置、设置映射关系并启动复制等关键步骤。手册按Step1Step7的顺序逐步展开并提示了创建专用系统用户、检查网络连接等易错细节具备较强的现场操作指导价值。目前已有62人学习适合在部署同类复制系统前快速对照和梳理配置要点使用。1. 先说清楚这玩意儿DSGRealSync 复制系统到底帮你解决了什么问题做数据库容灾的人都有过这种体验每天夜里跑一个备份脚本第二天一查备份是好的心里才踏实。可一旦生产库真出了事恢复备份、追日志、手工补数据整套流程下来少说几个小时业务早就等不起了。DSGRealSync 复制系统解决的就是这个“等不起”——它通过解析源库的在线日志和归档日志把提交后的增量事务实时投递到目标端让容灾库或分发库始终保持和生产库基本一致。这篇安装配置的归纳笔记适合正在搭容灾环境、做数据分发或系统迁移的工程师新手可以照着从头把链路搭起来熟手重点看第 5 章的现场问题和最后一章的巡检习惯。整个安装配置过程不复杂真正让你翻车的多半是装之前没想清楚的版本、权限和字符集。2. 动手前的三项硬准备版本匹配、账号权限和网络基线日志复制类工具最怕的不是安装步骤多而是前置条件没对齐装完了来回返工。这一章把后面要用到的东西一次想清楚后面每一步都是顺的。2.1 版本匹配源库、目标库版本差一级同步就可能沉默日志复制系统和源库的日志格式绑定得非常紧。Oracle 从 10g 到 11g、再到 12c、19credo log 和归档日志的内部结构一直在变工具识别日志格式的能力是跟着版本走的。版本越新能解析的日志特性越多但兼容范围也可能只精确到某个补丁级别。我的习惯是先建一张版本表把源端和目标端的数据库版本、补丁号、操作系统、字符集都写清楚再决定装哪个 Agent 版本。配置项生产库源端容灾库目标端数据库类型Oracle 11g R2 (11.2.0.4)Oracle 11g R2 (11.2.0.4)操作系统RHEL 7.6 x86_64RHEL 7.6 x86_64字符集AL32UTF8AL32UTF8补丁级别11.2.0.4.16071911.2.0.4.160719两个库的补丁级别最好对齐。补丁不一致时日志解析进程可能能正常启动但处理了一批归档后就会报“找不到重做记录”。这种报错特别有误导性你以为是归档日志传输断了实际上只是解析层不认识某条内部记录结构。把版本和补丁对齐以后这类问题基本消失剩下的才是网络和权限的排查。这里补充一句目标端版本比源端低一级不是一定不行但你要接受一个现实——如果解析逻辑里用到了源端新版本的日志特性目标端 Agent 处理不了就会回退到“跳过该事务”的策略等你发现数据差时已经差出很远。所以通用建议还是让目标端版本不低于源端能同版本最好同版本。如果两端版本差异确实无法避免安装之前在测试环境做一轮 24 小时的持续写入验证确认没有“日志解析跳过”的日志告警再上生产。2.2 源端抓取账号与目标端写入账号最少但刚好够用的一组权限复制系统里面有两组账号最容易搞混源端抓日志的 capture 账号目标端写数据的 apply 账号。很多人图省事直接给个 dba结果带来的问题比解决的问题多目标端有了 dba 权限一旦同步规则里表映射写错它可能会直接建到 sys 表空间或者覆盖同名表生产环境里这种事故不是没发生过。我在生产上给的最小权限是这样一组可以照抄后按需精简-- 源端抓取日志账号 CREATE USER dsg_cap IDENTIFIED BY your_strong_password; GRANT CONNECT, RESOURCE TO dsg_cap; GRANT SELECT ON sys.v_$database TO dsg_cap; GRANT SELECT ON sys.v_$archived_log TO dsg_cap; GRANT SELECT ON sys.v_$log TO dsg_cap; GRANT SELECT ON sys.v_$logfile TO dsg_cap; GRANT SELECT ON sys.v_$parameter TO dsg_cap; GRANT SELECT ON sys.v_$instance TO dsg_cap; GRANT SELECT ON sys.v_$thread TO dsg_cap; GRANT SELECT ON sys.v_$transaction TO dsg_cap; ALTER USER dsg_cap QUOTA UNLIMITED ON users;这段 SQL 的逻辑很简单capture 账号只需要“读”日志相关系统视图的能力。v_$transaction 用来识别未提交事务v_$archived_log 和 v_$log 用来定位日志文件v_$parameter 用来确认补充日志和归档模式等参数配置。如果你同步的表上有访问权限控制还要单独给这些表 SELECT 权限。注意一点这里不要顺手把 dba 角色加上去源端 capture 账号一旦有了 dba反而可能因为权限过高而被安全审计扫描出来到时候整改的麻烦比配权限本身大得多。接下来是目标端写入账号-- 目标端写入账号 CREATE USER dsg_app IDENTIFIED BY your_strong_password; GRANT CONNECT, RESOURCE TO dsg_app; GRANT INSERT, UPDATE, DELETE ON test.orders TO dsg_app; GRANT SELECT ON test.orders TO dsg_app;按表授权看起来繁琐但能让误操作的范围可控。如果同步范围很大可以临时放宽到任何表GRANT SELECT ANY TABLE TO dsg_app; GRANT INSERT ANY TABLE, UPDATE ANY TABLE, DELETE ANY TABLE TO dsg_app;这个放宽操作只在测试环境用。生产环境我仍然建议在同步规则里严格限定 schema 和表名目标端保持白名单式的授权。另外目标端账号一定要有表空间的配额否则同步大表时会在写入阶段报“unable to extend segment”问题表现成任务卡住而不是直接失败容易耽误排查。补充日志这一步也是在动手前就要确认的。如果源端还没开补充日志必须在配置任务前执行ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;如果只有主键还不够某些场景还要加唯一键日志。开启后把当前日志切换一次让新设置立即生效。这一步不做后面的增量任务能启动但拿不到足够信息延迟会越拉越大。2.3 端口、字符集与时区三类低投入高回报的检查项安装前把端口列清楚能省下大量排查时间。一套复制系统通常涉及三类连接管理控制台对外提供 Web 服务的 HTTP(S) 端口控制台和 Agent 之间的数据通道端口Agent 连接源端和目标端数据库的 JDBC 端口。从实际经验看控制台端口常见默认值是 8080 或 9080Agent 通道端口常落在 5000 到 6000 这个区间具体以你手上版本 conf 文件里的实际值为准。防火墙策略这里有一个隐蔽的坑控制台是主动向外连接 Agent 的很多机房策略只放行了入站 TCP没放行回包于是 Agent 注册时握手成功但随后立刻断连。处理办法是把源端、目标端和控制台三个方向之间的所有相关端口都加入白名单并且双向放通。如果你使用容器或负载均衡还要额外注意端口映射别把数据端口的源地址翻译换掉不然跨网段部署时 Agent 能注册但数据传输不稳定。字符集方面源库和目标库字符集一致是最省心的情况。如果实在不一致配置任务时务必备注字符集转换关系例如源端 ZHS16GBK、目标端 AL32UTF8必须在数据源配置里指定转换编码。遗漏这一项时同步任务不会报错但中文列会在目标端变成问号而且这种问题往往在大批量数据同步完成后才被发现重新处理成本很高。时区问题集中在TIMESTAMP WITH TIME ZONE字段。我建议让源端和目标端统一使用 Asia/Shanghai或在两边都做同样的时区偏移设置ALTER SYSTEM SET time_zone 08:00 SCOPEBOTH;这里的关键不是选哪个时区而是源端和目标端必须保持一致。两端时区不一致时同步过来的时间字段会整体偏移如果下游报表按小时统计凌晨会出现一段“看似随机”的断层排查起来非常吃力。2.4 目录规划和控制库存储位置一次想清楚免得迁移安装介质一般分为服务端含 Web 控制台、Agent、授权文件有时还带命令行工具包。收到介质后别直接解压到 /opt 根目录我会先做目录规划把长期运行的数据放在独立数据盘上避免系统盘空间爆炸后整个服务不可用mkdir -p /opt/dsg/{app,data,logs,backup} chown -R dsg:dsg /opt/dsgapp 放程序文件data 放控制库数据和运行期配置logs 放运行日志backup 放配置备份和升级前的快照。这样后面升级时只需要替换 app 目录data 和 logs 不动回滚也有据可查。控制库存储同步任务定义、心跳状态和告警信息是这套系统里最容易被低估的部分。常见部署方式使用内置文件型存储或指定本地目录具体以版本为准。控制库所在目录的磁盘性能影响页面刷新速度和告警写入对同步吞吐影响不大但空间要预留够表数量越多控制库增长越快。我一般按主库业务表总数估算预留 1.5 倍空间。机械盘和 SSD 混用时把 data 放在 SSD 上日志复制系统对随机写的敏感度比你想的高得多。3. 把服务端和 Agent 装起来从解压到服务正常监听这一章按顺序写装服务端、初始化控制库、导入授权、启动验证再装源端和目标端的 Agent。原则是先服务端后 AgentAgent 没装好时控制台里节点显示离线是正常的。3.1 解压服务端安装包目录先选对后面不折腾登录到规划好目录的主机以 dsg 用户操作不要用 root 直接跑安装脚本避免生成 root 属主的文件影响后续维护和升级。su - dsg tar -zxvf DSGRealSync_server_linux.tar.gz -C /opt/dsg/app cd /opt/dsg/app ls解压后目录里一般有 bin、conf、lib、webapps 这几个子目录。bin 存放启动和运维脚本conf 存放核心配置文件lib 是依赖包webapps 是控制台程序。先别急着改配置打开 conf 目录里的主配置文件确认三项内容监听端口、控制库路径、日志目录。grep -E port|datadir|logdir /opt/dsg/app/conf/system.conf这三项确认完再把需要改的端口和数据目录改掉。比如把控制台端口从默认值改成 9080# conf/system.conf server.port9080 console.datadir/opt/dsg/data log.dir/opt/dsg/logs配置文件里的 key 名字不同版本会有差异但思路一样先改端口、数据目录和日志目录别动其他参数。修改完成后先保存然后初始化控制库。3.2 初始化控制库别让它落在程序目录里控制库初始化会生成一些内置表用来记录任务和运行状态。常见做法是执行 bin 目录下的初始化脚本并指定数据目录。cd /opt/dsg/app/bin ./initdb.sh --datadir /opt/dsg/data/console执行完以后/opt/dsg/data/console下会出现控制库文件。这步看起来简单实际上决定了以后迁移的复杂度。如果初始化时把数据目录指在 /opt/dsg/app 里面升级程序时容易把控制库一起覆盖掉。所以我强调一句data 目录和 app 目录分开初始化时显式用--datadir指定不要依赖默认值。初始化完成后建议立刻做一次目录备份备份到 /opt/dsg/backup 下cp -r /opt/dsg/data/console /opt/dsg/backup/console_init_bak这一份备份在后续升级或出问题时就是后悔药。我见过不少现场升级失败后想回滚结果发现控制库已经和程序一起被覆盖最后只能重新配置全部任务重构成本相当高。保留一份干净的初始备份回滚只需要五分钟。3.3 导入授权license 文件放对位置服务才能退出评估模式每套复制系统都会绑定授权文件常见形式是一个 license.dat 文件或一串需要粘贴到配置文件里的密文。安装文档通常会要求你把授权放到 conf 或 data 目录下。我习惯放到 data 目录因为升级程序版本时 data 目录不会被替换。cp /tmp/license.dat /opt/dsg/data/license.dat chown dsg:dsg /opt/dsg/data/license.dat然后修改配置文件中的授权路径# conf/system.conf license.file/opt/dsg/data/license.dat启动服务后在控制台首页看授权到期时间。如果显示未导入或已过期优先检查 license 里的机器绑定信息。常见做法是授权绑定机器的主机名或 MAC 地址需要先确认当前主机和申请授权时用的是同一台不然你会在“服务起不来”上耗一整天。这里有个容易忽略的点申请授权时用的主机名和正式安装时的主机名必须一致如果安装到一半改了主机名授权会直接失效需要重新走一遍授权申请流程。所以改主机名这件事尽量在安装前完成。3.4 启动服务端并验证端口在听、进程在跑、日志没报错服务端启动一般是一个 start 脚本cd /opt/dsg/app/bin ./start.sh启动后验证三步别只看进程在就以为完事了。# 第一步进程状态 ps -ef | grep dsg | grep -v grep # 第二步端口监听 ss -lntp | grep 9080 # 第三步启动日志尾部 tail -50 /opt/dsg/logs/console.log进程在、端口在监听、日志里没有 ERROR才算真正起来了。实际部署里最常见的翻车现象是进程 ps 能看到但端口没监听这时候八成是端口被占用或者配置加载失败直接看 console.log 里的异常信息比重新启动更快。日志里出现Address already in use就换一个端口出现license file not found就检查授权路径出现数据库连接失败就检查控制库的初始化配置。我还会顺手访问一次控制台首页确认 Web 页面能正常打开。如果页面打不开但端口在监听先看日志里有没有静态资源加载失败再确认是不是浏览器访问路径带上了额外前缀。这一步做完服务端就算交付了。3.5 部署源端和目标端 Agent注册成功后控制台才看到节点Agent 装在源库主机和目标库主机上分别负责日志抓取和写入。每个被同步的数据库实例一般都需要部署一个对应的 Agent 进程。tar -zxvf DSGRealSync_agent_linux.tar.gz -C /opt/dsg/app/agent cd /opt/dsg/app/agent ./agent_install.sh --server 192.168.10.10:9080 --token your_register_token--server指向控制台的地址和端口--token是控制台生成的注册令牌一般可以在控制台系统设置或 Agent 管理页面查到。执行成功后Agent 进程会启动并向控制台发起注册。验证 Agent 是否注册成功登录控制台的 Agent 管理页面查看节点状态正常应该是绿色在线。如果节点一直显示待注册或离线第一件事是检查--server里的端口是否和控制台实际监听端口一致第二件事是看 Agent 主机的运行日志tail -100 /opt/dsg/app/agent/logs/agent.logAgent 日志里如果出现Connection refused是控制台端口或网络不通出现token invalid是注册令牌过期或复制错误。从我的经验看Agent 安装这一步 90% 的问题出在网络策略和端口写错剩下 10% 才是 token 权限。所以网络基线那一章的内容一定要在安装前做扎实。4. 配置第一个同步任务源端、目标端和映射规则如何串起来服务端和 Agent 都上线后接下来的工作是在控制台里配置同步任务。这一章把最常用的 Oracle 到 Oracle 同步路径拆成四步配数据源、选同步模式、加同步对象、启动前检查。4.1 添加源端和目标端数据源连接串、用户和字符集一次填对在控制台的“数据源管理”里分别添加源端和目标端。连接信息通常包括 IP、端口、服务名或 SID、用户名和密码以及字符集。以 Oracle 为例JDBC 连接串一般是jdbc:oracle:thin://192.168.10.20:1521/prod源端填 dsg_cap 账号目标端填 dsg_app 账号。字符集一栏不要跟随连接工具自动识别按第 2 章里的对照表明确填写比如源端填 AL32UTF8目标端如果不同就填 ZHS16GBK。字符集这里填错了控制台连接测试照样能通过但跑起来以后就会出现 5.2 里说的中文乱码。添加完成后控制台一般会提供“连接测试”按钮。这个测试只是验证 JDBC 能连上并不代表日志解析链路是通的。更可靠的验证方式是稍后创建任务后用任务里的日志抓取状态来判断。这里我习惯先手动在源端执行一次日志切换制造一条可见的日志记录方便任务启动后立刻验证抓取ALTER SYSTEM SWITCH LOGFILE;4.2 选择同步模式全量加增量是最省心的起点同步模式的选择直接影响初始化到交付的时间。常见做法是先做一轮全量数据初始化把当前基线搬到目标端再开启增量同步追平此期间产生的事务另一种方式是从归档日志最早点开始做纯增量同步。生产上我更推荐全量加增量方式原因有两条第一它不用依赖归档保留周期尤其适合源端归档经常被清理的库第二全量阶段完成后可以立刻做数据比对验证表之间能不能对齐。配置模式时有个参数需要重点看全量阶段冗余日志的处理方式。部分系统支持在全量进行的同时记录增量这样全量结束后不需要再重新读取日志去补差异同步窗口被压缩得很短。选择这个参数后目标端在全量期间会以“延迟应用”的方式排队全量结束再统一应用增量事务。这个功能如果需要提前确认源端归档空间够不够因为全量期间会额外占用一部分日志空间。同步粒度上分为库级、Schema 级和表级。初装阶段建议选表级只勾选最核心的几张表跑通链路再扩大到 Schema 级。直接配库级同步虽然省事但会把不需要的临时表、日志表都纳入增加控制库负载和排错难度。4.3 同步对象与表映射主键、大小写和排除规则在同步对象配置界面里选择要同步的 schema 和表。最直接的加表方式是逐表勾选但遇到几百上千张表时应该使用“按模式添加”再配合排除清单。排除清单通常包括日志表、临时表、大字段档案表。日志表被同步过来没有任何意义纯占空间大字段档案表单独评估不要跟普通业务表混在一个任务里否则一张大字段表的重试会把整个任务的吞吐拖垮。表映射规则里三个常见坑一次说完。第一表名大小写。Oracle 里表名默认大写如果源端建表时用了双引号小写目标端的表名很可能也带双引号。映射规则里如果没保持一致同步任务启动后会在“找不到目标表”上反复摩擦。正确的做法是在目标端创建同名表并在映射配置里把大小写与源端完全一致地填进去。第二主键必须存在并有明确顺序。没有主键或唯一索引的表增量更新会退化成删除后插入性能差且容易产生重复数据。如果业务表确实没有主键至少要在映射规则里指定一个唯一列组合否则我不建议开启这张表的增量同步。这里还要注意主键列在目标端不能被允许为空否则插入时数据库会报约束错误。第三列映射不要自作聪明。常见做法是只同步同名同类型列如果目标端有额外列且允许为空可以直接忽略如果目标端列比源端少则要在映射规则里剔除否则任务启动时报列数不匹配。列类型不一致是最容易忽略的比如源端是 NUMBER、目标端是 VARCHAR2同步数据时数字会变成字符查询统计结果全错。4.4 启动任务先小表后大表先单表后整库任务配置好以后第一件事不是点“全部启动”而是选一张小表单独启动观察一轮抓取、投递、落库的全过程。我一般的启动顺序是# 控制台命令行或页面按钮先启动单表任务 dsgctl task start --task-id sync_test_001 # 观察任务运行状态 dsgctl task status --task-id sync_test_001如果你的版本只有 Web 控制台没有命令行工具直接在页面点启动即可然后翻到“运行监控”页看延迟。判断正常的标准有三个任务是运行态延迟数值在减小目标端表行数在增长。延迟从几万秒逐渐降到几十秒说明链路正常如果任务状态是运行中但延迟越来越大基本能从第 2 章的权限配置和版本问题上找到线索。小表验证通过后再逐步扩大到全部同步对象。无论用哪种方式启动都要在源端确认补充日志已开启。没有补充日志时任务即使启动成功也会在更新一条无主键记录时报“缺少唯一键信息”这种错误在监控里看起来像是偶发网络抖动实际原因是日志解析拿不到旧值。全部任务启动后把控制台的告警阈值设置好再按第 6 章的巡检节奏走起来这套链路就算进入稳定运行状态了。5. 安装配置常见问题避坑指南五条现场翻车记录这一章每一条都是我在现场遇到过、或拆过别人现场总结出来的按“现象 → 原因 → 解决”写方便你直接对着问题找答案。5.1 现象任务启动后目标端迟迟不来数据延迟久居不下原因通常有两个一是源端补充日志没有打开Agent 解析日志时拿不到足够信息处理速度极慢二是目标端表空间不足或处于只读状态。第一点最隐蔽因为任务状态不报错你只能在日志里反复看到 “no supplemental log data” 这类提示。解决在源端开启补充日志并确认日志模式为ARCHIVELOGALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER SYSTEM SWITCH LOGFILE;开启后重启任务正常情况下延迟在几分钟内开始下降。如果重启后仍然高延迟再查目标端表空间剩余量把表空间扩容或清理归档后再试。注意补充日志开启前已经产生的归档日志里没有补充信息所以任务要从开关切换后的时间点重新开始否则旧日志段还是会一直处理不出来。5.2 现象同步过来的中文全是问号但两端字符集明明一致看到这个现象时先从两个方向排查。首先确认数据库本身字符集SELECT userenv(language) FROM dual;两端一致时问题往往出在数据源配置里的字符集填写。有的版本不填字符集会按 JDBC 驱动默认字符集去解码最终落到目标端就是乱码。另一个方向是操作系统 LANG 环境变量。Agent 进程如果以 root 启动LANG 不对时会用系统的默认编码读日志。解决数据源配置里显式填写源端和目标端字符集Agent 启动用户的环境变量加上export LANGen_US.UTF-8重新启动 Agent。两端字符集确认一致后重建这张表的同步任务再对比一次中文列。乱码这种事最怕只修表现不修根改完字符集不重建任务旧数据里的乱码还在原地。5.3 现象同步的 CLOB/BLOB 字段内容为空或写入不完整原因大概率是抓取进程对大字段对象有单独的处理通道而这个通道在目标端没有对应权限或表空间。CLOB 字段的内容一般会单独存放在内部 LOB 段如果目标端账号没有读取该 LOB 段的权限内容就会在投递时被跳过表现为主键和普通字段正常更新唯独大字段为空。解决给目标端账号加上对源端 LOB 列的读权限。如果目标端表空间存不下大字段单独为 LOB 表规划表空间并在映射规则中确认该表启用了 LOB 支持。另外LOB 字段同步对网络带宽敏感跨机房带宽不足时大字段写入超时会被判定为失败然后自动重试重试期间整条任务吞吐下降所以要给大字段任务单独设置带宽限制避免把普通表同步拖慢。5.4 现象Agent 频繁掉线控制台节点状态红绿跳变原因大多是 Agent 与控制台之间的心跳超时而超时又往往由网络抖动或中间链路防火墙的会话超时导致。有的防火墙默认空闲连接超时时间较短长连接超过阈值就会被切断。Agent 的自动重连机制虽然存在但每次重连都会清空一部分缓存进度掉线越频繁延迟涨得越快。解决把 Agent 到控制台之间所有 TCP 连接的空闲超时调大一般调到 6 小时以上同时确认 Agent 侧的心跳间隔设置在 30 秒到 60 秒之间。防火墙策略只能按端口维度放行时建议把 Agent 通道端口独立开放不与其他业务共用 NAT 策略。改完这些重连告警应该明显减少。这个问题的难点在于网络设备往往不归你管需要提前把端口和超时要求写在部署申请里。5.5 现象license 授权没到期但重启服务后提示授权失效原因大多是启动脚本读取 license 的路径和实际放置路径不一致。很多部署习惯把 license 放在安装目录下升级时整个目录被替换授权又变成默认值。还有一种情况是授权绑定主机名而机器启动后主机名被 DHCP 或初始化脚本重置了。解决统一把 license 放在 data 目录并在配置里显式写绝对路径。升级时保留 data 目录授权不受影响。追加一条习惯每次导入新 license 后备份一份到 backup 目录文件名带上日期比如license_20250101.dat。这样即使授权文件损坏也能找到最近的备份恢复。6. 同步做完后的验证和巡检三条命令加一张日常检查表任务启动只是起点真正要交付的是“源端和目标端在任意时刻都对齐”这个结果。我每次交付前会走三道检查。第一道是行数比对。对全量表跑一次 count对按月分区的大表按分区比对把行数不一致定位到具体分区再细看。源端和目标端分别执行-- 源端 SELECT COUNT(*) FROM test.orders; -- 目标端 SELECT COUNT(*) FROM test.orders;第二道是明细比对。取最近变动的 100 条记录逐列比对关键业务字段尤其数值列和带中文的字符串列。数据量小时可以直接把两端查询结果导出后做 diff数据量大时按主键分批抽样每批抽几十条就够了不用全量比对。第三道是切换演练。把源端业务写入停掉确认同步延迟归零然后在目标端开只读会话查询最新数据。这一步做完才敢跟业务说可以切。演练结束后再恢复写入观察延迟从零重新开始爬升并趋于平稳这比任何监控告警都更能说明问题。日常巡检我建议按下面的节奏延迟趋势每 15 分钟刷新一次连续三次上升就触发告警而不是等绝对值突破阈值每天看一次源端归档目录和目标端表空间使用率每周做一次增量数据抽样核对升级或变更前备份 data 目录和 logs 目录最后说一个自己的教训。之前一套库稳定跑了大半年某天业务人员清理了一张历史大表目标端延迟几分钟内从 0 涨到几千秒监控告警因为阈值设得太宽没有触发。事后我翻延迟曲线发现前一天晚上就有缓慢爬升的苗头只是绝对值还在阈值以内。从那次以后我把告警逻辑改成趋势判断连续三次上升就通知值班而不是等延迟超过固定值。这个习惯让我躲过了后面好几次相似的事故。这篇归纳要是能在“先把版本、账号、字符集和目录一次想清楚”上帮到你一点半夜的告警电话就能少几个。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
