简介Sybase复制服务器是解决分布式数据库数据一致性的重要工具本资源以铁路客票系统(SMART)为应用场景面向数据库运维人员、系统架构师及对分布式数据同步技术感兴趣的开发者。内容围绕Sybase Replication Server从v11.0.1到v11.5.1的升级详细对比旧版基于OpenServer/OpenClient架构的LTM进程监控方式与新版将LTM整合为数据库内部代理线程的改进方案读者可从中掌握DDL复制、日志处理、错误恢复等关键特性理解RS在客票系统全路大联网中保障数据实时同步与高可用的实施路径。该资源为单个PDF文档压缩包约459KB技术密度高便于快速查阅目前已有87人学习下载对理解Sybase复制服务器在大型实时交易系统中的应用具有直接参考价值。1. 票务系统为什么需要 Sybase 复制服务器客票系统最大的矛盾不是数据量大而是同一份数据要同时扛着交易、统计和异地灾备三份工作。窗口一开主库的写压力瞬间顶上来读库和灾备库也必须拿到几乎实时的数据这时候靠业务代码里“先删后插”的同步脚本迟早会在回环边界上翻车。把 Sybase 复制服务器引入到架构里之后我发现数据一致性可以靠构造本身解决而不是靠开发人员一遍遍补 SQL。它直接扫描主库事务日志把已提交事务原样分发到复制库读库和备库拿到的是同一份事务序列。这篇笔记围绕复制服务器的构造原理、初始化步骤、参数选择和客票环境下的排障经验展开适合正在部署复制链路或者打算替代自研同步方案的运维和 DBA 阅读。2. Sybase 复制服务器构造拆解从主库日志到目标库的完整链路Sybase 复制服务器和普通数据同步工具的根本区别在于它不关心业务表的新增、修改、删除语句怎么写只关心主数据库的事务日志里已经落地的每个操作。主库返回客户端“提交成功”之后复制服务器才把这段日志按复制定义翻译成目标库可以执行的 SQL 或行级操作。这个“先落地后复制”的顺序保证了主备两库即使在复制延迟期间出现短暂不一致最终也能收敛到同一事务序列而不是靠定时任务跑一夜批处理。2.1 复制服务器实例的最小组成Rep Agent、主接口、订阅代理要讲构造先分清三个容易混淆的角色。第一个是复制服务器实例本身它在部署中是一个独立进程维护自己的系统库RSSD早期版本也叫复制服务器系统库用于存放复制定义、订阅、路由、队列等元数据。第二个是主数据库上的 Replication Agent简称 Rep Agent它长在主库 ASE 进程附近专职扫描事务日志旧版本通过 Log Transfer Manager 做这件事现在多用 sp_config_rep_agent 管理。第三个是目标端角色它不叫“从库 Agent”而是由复制服务器直接连接目标数据库用一个维护用户把变更写入。这三个角色在客票场景里对应三台不同的机器。主库部署在交易机房复制服务器实例可以部署在中间链路节点上目标读库放在统计或灾备机房。完整链路是“主库日志 → Rep Agent → 复制服务器稳定队列 → 目标库维护用户写库”。很多新接触的人会把 Rep Agent 和复制服务器进程混在一起实际上复制服务器可以同时管理多条主链路而每个启用复制的主数据库只需要一个正常运行的 Rep Agent。提示复制服务器不是一个备份工具。它不产生全量快照也不负责在目标库建表首次同步时对历史数据的选择性初始化是由订阅的物化步骤完成的增量复制只处理订阅建立之后发生的日志变更。2.2 复制定义与订阅两张配置对象决定“哪些行、落到哪里”复制定义是这一切的中心。它抽象描述了一张表的复制契约主数据服务器是哪个库、表名是什么、主键是什么、需要复制哪些列。客票订单表我会把主键定义为联合主键比如“订单号 出票日期”而不是只取订单号否则按日期分区清理历史时复制链路上的 before-image 匹配会出问题。当复制定义覆盖某张表之后复制服务器只对这个定义覆盖的表做日志转换。没有被定义覆盖的表写入哪怕日志里看得见也不会被搬运。所以部署阶段最常出现的现象是“目标库上某张表死活不同步”那不是链路断了而是忘了给这张表建复制定义。订阅描述的是“哪个目标库需要这份定义的哪些行”。通过 where 条件可以做行级过滤比如只订阅sale_date 2024-01-01的订单。这个 where 条件在物化时会替目标库过滤历史数据在增量阶段会作为附加匹配条件写进复制服务器的订阅表从而减少网络传输量和目标库写压力。一张复制定义可以挂多个订阅每个订阅互不影响同一个订阅也可以针对同一张复制定义在不同目标库上分别启用。2.3 多级路由与复制拓扑异地灾备时的级联分发方式客票系统一旦做两地三中心单跳复制是不够的。复制服务器支持把目标库所在的数据服务器当作下一级主数据服务器继续分发这叫级联或多层复制。第一级复制服务器把订单表复制到中转库第二级复制服务器再接上中转库日志继续复制到更远的灾备库。级联链路的代价是延迟叠加而且每一级都要再配一个 Rep Agent因为第二级复制服务器照样要靠日志驱动。我的经验是级联深度控制在两层以内超过两层之后排查日志断点时每级都要单独对齐很容易出现中间层正常、末端库延迟到分钟级的情况。如果只是做异地灾备可以在复制服务器上建立路由通道让一份队列数据并行写多个目标库而不是逐级串行。这里用一张表看三者的分工更直观组件所在位置职责常见故障表现主数据库交易机房产生事务日志日志满、Rep Agent 未启动Rep Agent紧邻主库扫描日志并发送日志流主库日志暴涨但复制无进展复制服务器实例单独进程日志转换、入队、分发稳定队列积压、订阅状态异常目标数据库读库 / 灾备库执行维护用户写入主键冲突、列宽不足这样拆完之后后面不管是初始化还是排障都能顺着“主库日志 → 队列 → 目标库”这条线定位。3. 搭建最小复制通道从零初始化到首次数据落地这一章按“先在测试库跑通最小链路”的路子写。假设主库是 ASE目标库是另一个 ASE 实例版本都对齐到 12.5 以上新版本提前确认 Replication Server 与 ASE 的兼容矩阵。最小链路只需要一台复制服务器连接两个数据库实例。3.1 构建前检查版本对齐与主键约束开工前先检查四件事。第一主库和目标库的 ASE 补丁版本尽量一致尤其字符集和排序规则不能跨太多版本。第二复制涉及的表必须有明确主键复制服务器按主键匹配 before/after 镜像。第三主库的日志设备要处于没有被其他程序占用的状态比如已有别的日志分析工具在读日志需要先协调。第四目标库的开销用户也就是维护用户要对目标表有插入、更新、删除权限不能只给一个 select 权限。如果是从零安装先把 Replication Server 的安装目录和环境变量配置好。下面是一个典型的配置步骤片段用于把复制服务器实例 rs1 注册到接口文件我一般把主库 ASE 的入口也一并核对一遍# 编辑接口文件追加复制服务器入口 import rs1 mastertcp ether ip_address 4100 querytcp ether ip_address 4100这段配置的关键在于两条xxxether行。master 连接用于建库和控制query 连接用于业务查询两个端口都必须能从复制服务器所在主机访问到 ASE 实例所在主机的对应端口。如果中间有防火墙放开 ASE 默认端口和复制服务器端口即可。3.2 初始化复制服务器实例并激活主库日志捕获注册完接口后在安装目录下执行 rs_init 完成初始化。rs_init 会创建 RSSD、启动复制服务器进程并把主库、目标库的 DSN 信息写进系统库。命令长这样## 初始化一个名为 rs1 的复制服务器实例 rs_init -R rs1 ## 之后确认进程状态 showserver | grep Replication-R参数表示这是一次全新初始化后面跟实例名。初始化完成后用 showserver 能看到复制服务器的监听端口和进程 PID。如果没有看到 Replication Server 字样先看日志文件$SYBASE/install/rs1.log常见原因是端口被占用或 RSSD 建库失败。接着在主库上启用 Rep Agent以 ASE 的 isql 方式进入主库执行-- 在主库启用复制代理并启动 use master go exec sp_config_rep_agent booking_db, true go exec sp_start_rep_agent booking_db go -- 查看代理状态 exec sp_help_rep_agent booking_db gosp_config_rep_agent的第一个参数是库名第二个参数true表示开启复制代理sp_start_rep_agent是真正拉起日志扫描线程。这里最容易踩的坑如果主库之前做过 dump/load 恢复Rep Agent 的起始日志位置可能和当前数据库的日志末尾不一致必须在启用前记录一次dbcc gettrunc的值作为对账基准。3.3 创建复制定义与订阅核心 SQL 脚本复制服务器在运行了主库日志也有人在扫接下来就是定义“抄哪些列、落到哪张表”。进入复制服务器的 isql 控制台依次执行下面两组脚本。-- 1. 创建复制定义指定主库、表名、主键和复制列 create replication definition rep_def_order with primary at PRIDB.booking_db with all tables named t_order primary key (order_no, sale_date) replicate columns ( order_no, sale_date, ticket_status, train_no, passenger_no, pay_amount, sale_time ) go这段脚本的with primary at PRIDB.booking_db指主库的数据服务器名和库名with all tables named t_order说明复制定义绑定到主库里的哪张物理表。主键取两列联合就是为了避免不同出票日期下订单号重复导致复制匹配错乱。replicate columns只列出需要复制的业务列主键默认包含在复制范围内不需要重复写。创建完定义后创建订阅。订阅要指定目标库和落点-- 2. 创建订阅目标库只接收近一年的订单 create subscription sub_order_recent for rep_def_order with replicate at RPLDB.rpl_db where sale_date 2024-01-01 go这里的with replicate at指定目标库的物理位置where子句是行级过滤条件增量阶段复制服务器只把满足条件的行写入目标表。如果业务上需要全量同步去掉 where 条件即可。订阅名在同一实例内要唯一两个订阅不能同名。3.4 首次数据落地验证观察复制状态与日志水印脚本执行完复制链路并不会立即开始搬运历史数据要先做物化。物化是复制服务器在订阅首次生效时从主库把满足 where 条件的已有数据抄一份到目标库的动作。物化期间主库正常读写增量日志会挂起在稳定队列里等物化完成后再按顺序追放。判断链路是否真正打通我一般看四步。第一步执行admin who_is_down查看有没有订阅处于 down 状态。第二步在主库插入一条满足 where 条件的记录回目标库 select 是否出现。第三步看主库 Rep Agent 日志有没有报错。第四步用rs_repstat -S 1看复制延迟延迟数值在秒级左右就算正常。-- 在主库手工造数 use booking_db go insert into t_order(order_no, sale_date, ticket_status, train_no) values(20240001, 2024-05-01, OK, G123) go提示如果目标库迟迟查不到数据先执行admin disk_usage看稳定队列是不是已经堆起来再返回主库看 Rep Agent 是否在正常扫描。绝大多数首次不通都卡在 Rep Agent 没有真正启动而不是复制定义写错。4. 客票场景下的复制参数选型与读写分离客票系统比一般业务更挑链路稳定性。切票窗口一开瞬时写入量是平时峰值的好几倍到了夜间清算又要保证统计库和生产库的数据差距在几十秒内。下面三条最值得在部署阶段就想清楚。4.1 高峰写入下的队列与批回放设置复制服务器自身的吞吐瓶颈通常不在日志扫描而在于入队和出队两个环节。主库日志扫描是顺序读复制服务器却要把事务按订阅拆分到不同队列再一批批发往目标库。客票切票时如果所有订单都订阅到同一个目标库就只有一个稳定队列在扛事务一积压延迟会线性上涨。我在客票项目里的习惯是把核心交易表按业务域拆成多张复制定义分别订阅到不同目标库而不是一张大表订阅到所有读库。比如订单主表、余票表、结算流水表各建各的定义读支撑库只订订单主表统计库订全部三个定义。这样同一时刻的分发压力被拆开不会出现一个库的订阅把复制服务器进程拖死的情况。批回放大小也要单独调。批回放设置太小复制服务器会频繁切换上下文设置太大目标库一次性锁表时间过长日报表查询会被锁住。我的基准值是从 64 到 128 条事务之间开始压测看目标库锁等待和复制延迟两个指标的反向关系再定。4.2 延迟敏感的读库内存队列与磁盘队列取舍复制服务器的稳定队列有内存队列和磁盘队列两种形态。内存队列响应快但复制服务器进程一旦崩溃未落盘的队列会丢磁盘队列会先写日志文件再对外确认进程恢复后可以从断点继续分发。客票系统里支撑余票实时查询的读库延迟比不丢更重要我会给这条链路开较大的内存队列上限让日志流尽量留在内存里直接分拨。统计库则反过来它要的是不丢应该挂在磁盘队列后面。队列大小不是全局配置是按连接和路由设置的。不同版本里参数名称略有差异原则是内存队列给高优先级读库 8 到 16MB 起步磁盘队列放在独立的临时盘上不要和 ASE 的数据库设备放同一块盘否则队列日志暴涨时会把整块盘的 I/O 拖垮。客票夜间跑批时磁盘队列的大小直接决定是否会把复制服务器所在磁盘撑满建议按日交易量的 3 倍预留容量。4.3 主备切换换主节点时的复制定义与订阅保持方式客票系统在机房搬迁或大促演练时会做双机切换从备库提升为新主库。多数人以为是直接把客户端连接切过去复制服务器也会跟着自动切实际不是。复制服务器的主接口是绑定在数据服务器上的备库转正后需要把主数据服务器改为备库所在的数据服务器并且要在新主库上重新启用 Rep Agent同时撤销旧主库的订阅关系。正确顺序是先停旧主库上的 Rep Agent再在备库上启用 Rep Agent最后重建复制定义的主接口目标库订阅不需要重建但复制定义的 with primary at 要改成新主库逻辑名。这一个改动恰恰是复制链路里最容易翻车的环节很多联调到一半发现新主库的日志扫描根本不工作就是因为旧主库的 Rep Agent 还在占用日志设备。切换动作执行方注意点停旧主库 Rep Agent旧主库确认日志已全部送出启用新主库 Rep Agent新主库记录 dbcc gettrunc 基准重建复制定义主接口复制服务器with primary at 指向新库逻辑名检查目标库订阅复制服务器订阅无需重建但要确认状态5. 复制故障排查与避坑记录客票系统里反复踩过的 5 个坑下面五条坑是我在客票和类似交易系统里真实遇过的按“现象 → 原因 → 解决”写可以直接对照排查。5.1 主库日志暴涨且无法截断复制链路却显示正常现象主库日志设备在切票高峰后很快被写满手动 dump transaction 却提示日志未被消耗复制服务器侧看订阅、看队列都正常。原因Rep Agent 进程虽然启动了但它扫描日志的起始位点还停留在很久以前主库日志在等待这个 Agent 消费。更隐蔽的情况是主库做过数据库恢复日志断点被重置而 Agent 不知道。解决先停掉 Rep Agent用dbcc gettrunc记录当前日志末端再重新启动 Rep Agent。如果链路已经堆积太多老日志可以在复制服务器侧执行订阅的重新初始化把物化起点对齐到当前时刻。日常巡检里要盯主库日志截断历史连续一周截断量持续下降就该查 Rep Agent 是不是还活着。5.2 误用 alter subscription 导致目标库数据被全量重建现象为了新增业务我曾在原有订阅上追加一个过滤条件执行了 alter subscription 后目标库的表被清空并重新物化读库半小时不可用。原因部分复制服务器版本在修改 where 条件时会把 alter subscription 当作订阅定义变更默认触发重新物化。解决不需要过滤规则变更时不要动 where 条件。如果必须改先建新的订阅在维护窗口期切换应用连接再删旧订阅。任何修改订阅的运维脚本都先在测试环境跑一遍物化耗时别在生产上直接试。5.3 日期时间与 decimal 精度在复制链路中被截断现象目标库上某些订单金额字段比主库少了几厘钱日期字段在一些订阅里只剩年月日。原因复制定义的 replicate columns 只写了列名没有指定数据类型的映射规则在跨版本或跨字符集复制时默认类型转换可能把 time 或 decimal 保留位数截掉。解决在复制定义的 replicate columns 里显式给金额字段定义with datatype decimal(14,2)日期字段不要在目标库用 datetime 默认映射建议用with datatype datetime并显式注明该列由复制服务器以原样传递。复制定义创建后不能随便改列类型初始设计时就要把字段精度列全。5.4 对复制表做索引或 DDL 变更导致复制定义失效现象DBA 在目标库一张复制表上加了唯一索引复制服务器就开始报 duplicate key。又或者主库新增一列后目标库一直不同步这列。原因复制定义在创建时固定了列集合和目标表结构。主库 DDL 新增列复制服务器不会自动带入目标库加了约束或索引复制服务器执行更新时可能因为唯一键冲突整条事务失败。解决任何结构变更都要先在复制定义侧做重建。顺序是先查订阅停订阅改表结构重建复制定义最后重新订阅。禁止只在一侧直接改表。这个操作最好走变更工单因为涉及窗口期读库不可用。5.5 主备轮流写导致两库主键冲突现象双机切换演练结束后备库上出现一些主库看不到的订单号随后复制链路开始报主键冲突。原因演练时测试程序同时在旧主库和新主库上各写了少量数据切换回旧主库后复制服务器把新主库上写过的订单又复制回旧主库两库数据逻辑上已经分叉。解决演练时严格按“切换 → 应用全停 → 写校验数据 → 回切 → 全量对账”的步骤控制写入口。复制服务器只保证日志一致不保证业务逻辑上的防重。对账脚本要拿订单号加交易时间做联合比对只看主键会漏。6. 复制链路健康状态巡检与性能调优运维视角的最后一公里6.1 用 rs_repstat 与 admin 系列命令检查复制亚健康客票系统平时不显眼大促前一般会做一轮巡检。巡检我在意的不是“通或不通”而是延迟变化和队列水位。一个简单的巡检脚本可以这样写# 每天定时检查复制延迟和订阅状态 echo Replication Server version rs_repstat -S 1 | head -10 echo Disk queue usage isql -Usa -Ppassword -SRS1 -e admin disk_usage echo Active subscriptions isql -Usa -Ppassword -SRS1 -e admin who_is_down这个脚本里rs_repstat -S 1看延迟admin disk_usage看队列积压admin who_is_down看哪些订阅离线。大促前一周延迟应该持续回落而不是上升如果disk_usage持续高于 30%建议扩大队列文件或拆分订阅。6.2 按票务高峰曲线调整复制批回放参数业务上切票日内高峰和清算低谷非常分明参数可以写成两套。高峰时段减少复制服务器并发批大小让路由和查询线程更稳定低谷时段适当加大批大小让队列加速排空。批回放大小固定的话大促时容易出现目标库锁等待上升而低谷时段队列排空太慢白白占用内存。我的个人习惯是把批回放大小设为 64 到 128 条事务之间配合目标库的锁等待阈值一起压测。如果监控里目标库锁超时次数增加就先降批大小而不是直接加内存。这个平衡点跟硬件和表锁粒度强相关没有固定常量只能靠结果反向调整。另一个常被忽略的优化是把复制服务器的日志文件放在和 ASE 日志设备不同的物理盘上避免两者争抢 I/O。做完这两件事大促时的复制延迟一般能维持在主库日志产生速度的 1.5 倍以内已经算是可接受的范围。复制链路不是搭好就完每个大促窗口我都把它当成一次小型故障演练来做选参数、看队列、查断点这套动作反复练熟了故障来时才有后悔药可吃。希望帮到你。本文还有配套的精品资源点击获取