Sybase复制服务器在客票系统中的选型与实战配置

简介这份PDF技术文档围绕Sybase复制服务器Replication Server的体系结构及其在铁路客票系统SMART中的落地应用展开面向数据库运维工程师、分布式系统架构人员及铁路信息化从业者帮助读者理解分布式数据库间数据一致性的实现思路与升级实践。资源包内含1个PDF文件大小约459KB内容涵盖RS从v11.0.1到v11.5.1的版本演进、LTM进程与Agent线程的架构对比、日志处理与路由机制、错误恢复及监控管理工具等要点并具体剖析了客票系统在购票、退票、改签等实时交易场景下的数据同步方案。目前已有88人学习下载适合需要研究大型分布式系统数据复制、系统升级与高可用保障的技术人员参考借鉴。1. 客票系统为什么还在用 Sybase 复制服务器一次真实的选型复盘客票系统这类场景有个很拧巴的特点查询量巨大、写入相对集中、对数据一致性要求高但又不允许因为主库压力大就随便停机扩容。很多年前我第一次接触这类系统时第一反应是为什么不用现在流行的方案后来才明白Sybase 复制服务器Replication Server解决的恰恰是异构、跨版本、跨机房、低带宽下准实时同步这个组合问题。它的核心思路是主库把事务日志里的变更抽出来通过 Replication Agent 送到 Replication Server再由后者分发到一个或多个 Replicate Database。整个过程对应用基本透明应用只管写主库复制链路自己扛延迟和断点续传。这篇文章面向的是还在维护 Sybase ASE 客票类系统的工程师或者需要评估老系统怎么平滑扩容的架构同学。我会把复制服务器的构造逻辑、最小可跑通的配置、参数怎么调、坑在哪按我自己踩过的顺序讲一遍。不是科普是能照着复现的笔记。2. Sybase复制服务器的构造从主库到从库的四段链路2.1 复制链路到底由哪几个组件拼起来先把构造拆清楚不然后面配参数全是玄学。一条完整的 Sybase 复制链路标准情况下有四个角色主库Primary Database业务真正写入的库客票系统里就是售票、退票、改签落库的那个。Replication Agent通常叫 RepAgent跑在主库上的线程负责读事务日志把标记为复制的表变更抽出来。Replication ServerRSSD复制服务器本体它自己也需要一个库来存队列、订阅、路由信息这个库叫 RSSDReplication Server System Database。从库Replicate Database接收变更的目标库客票系统里常用来做查询分流、报表、异地容灾。数据流是单向的主库日志 → RepAgent → Replication Server → 从库。注意复制服务器不是靠触发器也不是靠轮询表它是读日志的。这一点决定了它的延迟特性和对主库的侵入程度——侵入小但要求主库必须开 trunc log on chkpt 之外的日志保留策略否则日志被截断了RepAgent 还没读到的变更就丢了。构造里还有一个容易被忽略的角色ID Server。如果链路里涉及多个 Replication Server 互相同步需要有一个稳定的 ID Server 来分配复制用的唯一标识。单链路场景可以先不折腾它但心里要有数。2.2 主库侧要做的三件事标记、日志、RepAgent主库不是配个连接就完事得先让数据库知道哪些表要复制。核心命令是 sp_setreptable把表标记为可复制。下面是我一般会走的最小步骤-- 1. 确认主库已经开启复制相关选项 -- 这一步在 master 库执行标记目标库允许复制 use master go sp_config_rep_agent PRIMARY_DB, enable go -- 2. 在目标业务库里把需要复制的表逐个标记 use PRIMARY_DB go -- 标记整表复制true 表示复制所有列 sp_setreptable TICKET_ORDER, true go sp_setreptable TICKET_REFUND, true go -- 3. 确认标记结果 sp_help_reptable go逻辑说明sp_config_rep_agent 是告诉 ASE 这个库要参与复制RepAgent 线程才会被拉起sp_setreptable 是逐表授权只有被标记的表日志里的变更才会被 RepAgent 识别。参数 true 表示复制全部列如果只想复制部分列得用 sp_setreptable 的列级变体但客票系统里我一般不建议列级复制因为一旦表结构变更列级标记很容易和实际 schema 对不上排查起来非常痛苦。参数上要盯两个一是主库的 trunc log on chkpt 必须关掉否则日志一截断RepAgent 没读完就永久丢数据二是 RepAgent 的扫描间隔默认值在低峰期够用但客票系统高峰期写入密集我一般会把 scan timeout 调小让日志读取更及时。2.3 Replication Server 侧RSSD、连接、路由Replication Server 自己是个独立进程它需要先有一个 RSSD 库来存元数据。构造顺序是先建 RSSD再启动 RS再在 RS 里定义到主库和从库的连接最后建路由和订阅。-- 在 Replication Server 上创建到主库的连接 -- PRIMARY_DB 是主库名sa 是登录名具体密码按实际填 create connection to PRIMARY_DB.PRIMARY_SERVER set username sa set password your_password go -- 创建到从库的连接 create connection to REPLICATE_DB.REPLICATE_SERVER set username sa set password your_password go -- 定义从主库到从库的路由 create route to REPLICATE_DB set username sa set password your_password go逻辑说明create connection 是让 RS 知道我能连上谁create route 是让 RS 知道变更该往哪送。这两个概念新手最容易混连接是能力路由是方向。没有路由连接建了也不会转发数据。参数上连接里的 username/password 是 RS 用来登录 ASE 的账号这个账号需要在主库和从库都有足够权限通常给 replication_role。路由的 username/password 是 RS 之间或 RS 到从库的认证单链路场景下和连接账号可以复用但生产环境我建议分开方便审计。2.4 从库侧订阅与物化从库不是建好表就自动同步得先做订阅subscription。订阅分两种一种是表级订阅一种是数据库级订阅。客票系统里我一般用表级订阅粒度可控。-- 在 Replication Server 上创建表级订阅 -- 订阅名、复制定义名、从库名、从库用户名依次给出 create subscription TICKET_ORDER_SUB for TICKET_ORDER_REPDEF with replicate at REPLICATE_DB without materialization go -- 如果需要初始数据同步用 with materialization -- 但物化会锁表客票系统高峰期千万别做逻辑说明without materialization 表示只同步订阅之后的增量变更历史数据需要自己用 bcp 或 dump/load 先灌过去with materialization 表示 RS 会帮你把当前数据也推过去但这个过程会占用大量资源客票系统这种大表物化基本等于一次小型停机。参数上订阅创建后要检查 subscription 状态用 check subscription 命令确认是 VALID 还是 PENDING。PENDING 状态下数据不会流动得先解决定义不匹配的问题。3. 在客票系统里落地从建链路到验证同步的完整步骤3.1 环境准备与版本对齐客票系统这种老系统最怕的就是版本不对齐。Sybase ASE 和 Replication Server 的版本兼容性有明确矩阵ASE 12.5 配 RS 12.6 和 ASE 15.7 配 RS 15.7行为差异很大。我一般会先确认三件事主库 ASE 版本、RS 版本、从库 ASE 版本。三者不要求完全一致但 RS 版本必须不低于它要支持的 ASE 版本。准备阶段还要确认网络端口。RS 默认用 2745 之类的端口但客票系统往往在内网端口可能被安全策略限制。我遇到过 RS 进程起来了连接建了但数据不动最后发现是 RS 到从库的端口没放通。这种问题排查起来就是黑匣子所以提前用 telnet 或 nc 确认端口连通性能省很多时间。3.2 建库、建表、建复制定义从库的表结构必须和主库一致至少被复制的列要一致。复制定义replication definition是 RS 里的概念它描述了主库的这张表长什么样从库该怎么接。-- 在主库上为复制定义准备表结构信息 -- 这一步通常在 RS 上执行引用主库的表 create replication definition TICKET_ORDER_REPDEF with primary at PRIMARY_DB.PRIMARY_SERVER with all tables named TICKET_ORDER ( ORDER_ID int, PASSENGER_ID varchar(32), TRAIN_NO varchar(16), SEAT_NO varchar(8), ORDER_TIME datetime, STATUS char(1) ) primary key (ORDER_ID) go逻辑说明复制定义里的列必须和主库表结构严格对应类型、长度、顺序都要对。primary key 是必须的RS 靠它来定位从库的行。如果主库表有自增列复制定义里要特别处理否则从库插入时会冲突。参数上with all tables named 后面跟的是主库表名大小写敏感取决于 ASE 的排序规则。客票系统里表名往往是大写复制定义里也要大写不然会报table not found。3.3 启动 RepAgent 并观察日志RepAgent 是链路的心跳它不动后面全白搭。启动命令在主库上执行-- 启动主库的 RepAgent use PRIMARY_DB go sp_start_rep_agent PRIMARY_DB go -- 查看 RepAgent 状态 sp_help_rep_agent PRIMARY_DB go逻辑说明sp_start_rep_agent 会拉起 RepAgent 线程它开始扫描事务日志。sp_help_rep_agent 能看到当前扫描位置、是否有错误、延迟大概多少。如果状态显示 Not running 或 Suspended先看 ASE 的 errorlogRepAgent 的问题基本都会往那里写。参数上RepAgent 的 scan batch size 和 timeout 是两个关键值。batch size 太大单次扫描耗时长延迟高太小频繁唤醒CPU 开销大。客票系统高峰期我一般把 batch size 控制在 200 左右timeout 设 1 秒平衡延迟和开销。3.4 验证同步用一条真实订单走一遍链路建好后别急着上生产先造一条测试数据走一遍。我一般会在主库插一条订单然后去从库查-- 主库插入测试订单 use PRIMARY_DB go insert into TICKET_ORDER (ORDER_ID, PASSENGER_ID, TRAIN_NO, SEAT_NO, ORDER_TIME, STATUS) values (999999, TEST_PASSENGER, G1234, 08A, getdate(), N) go -- 等待几秒后在从库查询 use REPLICATE_DB go select * from TICKET_ORDER where ORDER_ID 999999 go逻辑说明如果从库能查到这条记录说明链路通了。如果查不到按顺序排查主库 RepAgent 是否在跑、RS 的连接是否正常、路由是否存在、订阅是否 VALID、从库是否有错误日志。这个顺序能覆盖 90% 的问题。参数上等待时间取决于链路延迟正常应该在秒级。如果超过 10 秒还没到就要看 RS 的队列积压情况用 admin who 或 admin stats 看。4. 避坑与排查复制链路最常见的五类翻车4.1 日志截断导致变更丢失现象从库数据比主库少但 RS 队列里没有积压RepAgent 状态正常。原因主库的 trunc log on chkpt 没关或者日志空间满了触发了自动截断RepAgent 还没读到的日志被清掉了。解决立刻关掉 trunc log on chkpt扩大日志空间然后从库需要重新做一次全量同步。这个坑我踩过一次客票系统高峰期日志涨得飞快DBA 为了省空间开了截断结果复制链路直接断了一天。4.2 复制定义与表结构不一致现象订阅创建时报错或者订阅状态一直是 PENDING。原因复制定义里的列和主库实际表结构对不上可能是类型改了、列加了、或者大小写不一致。解决用 sp_help_reptable 和 sp_help_repdef 对比逐列核对。改表结构后复制定义必须同步更新否则 RS 会拒绝转发。4.3 从库写入冲突现象从库报主键冲突或唯一索引冲突复制中断。原因从库被应用直接写入或者从库有触发器、约束导致 RS 的写入失败。解决从库原则上只读禁止应用直连写入。如果有触发器要确认它不会干扰复制。客票系统里我见过从库被报表程序写入结果和复制数据打架最后只能把报表程序迁走。4.4 网络抖动导致连接假死现象RS 显示连接正常但数据不动重启 RS 后恢复。原因网络抖动后 TCP 连接没断但 RS 和 ASE 之间的会话已经失效RS 没检测到。解决配置 RS 的心跳检测或者定期用 admin who 检查连接状态。生产环境我一般会加监控连接超过一定时间没活动就告警。4.5 大事务导致队列积压现象RS 队列暴涨从库延迟越来越大。原因主库执行了大批量更新或删除RepAgent 一次抽出的变更量太大RS 处理不过来。解决大事务拆小批量执行或者在业务低峰期做。RS 侧可以调大队列上限但治标不治本。客票系统里批量改签就是典型的大事务我一般会要求业务侧分批提交。5. 进阶技巧让复制链路在客票系统里跑得更稳链路跑通只是第一步客票系统这种 7x24 的场景稳定性比功能更重要。我自己的习惯是给复制链路加三层验证第一层是 RS 自身的 admin stats看队列深度和延迟第二层是主从数据比对定期抽样几张核心表用 checksum 或行数比对第三层是业务侧验证比如从库查到的订单数和主库对不上就告警。参数调优上有几个值我一般会动。RepAgent 的 scan timeout 从默认的 5 秒调到 1 秒让日志读取更及时RS 的 sqm_max_queue 适当调大防止高峰期队列溢出从库的 rep_agent 相关参数保持默认不要乱动。这些调整不是越多越好每次只动一个观察一天再动下一个。还有一个技巧是分区订阅。客票系统的订单表往往按时间分区如果从库只需要最近三个月的数据可以用带 where 条件的订阅减少传输量。但要注意带条件的订阅对主库的日志解析有额外要求不是所有版本都支持上之前先在测试环境验证。最后说个我自己的教训复制链路最怕的不是配置复杂而是没人管。我见过一条链路跑了两年没人看监控直到从库磁盘满了才发现。所以不管链路多稳定期巡检不能省。希望帮到你。本文还有配套的精品资源点击获取