简介面向数据库运维人员与技术人员的Sybase复制服务器使用技巧文档聚焦分布式环境下数据复制与同步的常见问题包内仅有1个docx文档整体约68KB内容紧凑侧重实操经验。文档详细讲解了复制分区应设为数据流量的6倍、最大线程数需大于连接数的两倍加3、复制内存适当加大等配置优化原则同时强调创建专用sa用户、确保RSSD_prim拥有sa权限、配置RSM客户端ID_SERVER等注意事项。迁移篇按断开复制代理、静止队列、删除分区、迁移数据库与RSSD、归零第二截断点、重建队列等步骤给出完整流程故障处理部分针对DSI线程异常与队列阻塞介绍了连续执行resume connection跳过阻塞事务、使用admin who与sqt检查队列号并清空问题队列等方法。常用命令方面整理有admin health、admin who_is_down、rs_config、sp_configure等执行示例。已有58人学习下载适合需要自主排查复制故障的运维人员参考。1. Sybase Replication Server 使用技巧先从一次生产事故说起Sybase Replication Server 常用来做主从库数据同步但很多人第一次真正重视它是从事故开始的。有一次值班复制服务器的 DSI 线程忽然 down 掉备库数据停在两小时前队列积压持续上涨业务侧对账全是差异。重启复制服务器没用因为问题出在队列里的一条坏事务上。真正能救场的是按固定顺序处理跳过阻塞事务、恢复 DSI、必要时清队列、重建分区。这份整理把 Sybase Replication Server 的常用配置、迁移步骤、故障处理和命令速查串成了一份可以直接照着操作的笔记适合刚接手 ASE 复制链路的新人也适合老 DBA 在做迁移或故障恢复前核对步骤避免漏掉某一环导致复制长期中断。2. 配置优化与权限注意事项分区、线程数、内存和两个 rs 用户坑2.1 复制分区大小设为数据流量的六倍按峰值验证复制分区是复制服务器存放待投递事务的存储区域主库日志被抽取线程读出来后先落进分区再由 DSI 线程读取并写入目标库。分区的本质是一个缓冲区容量太小流量高峰时直接写满DSI 读不到数据主库第二截断点也压不下去最后整个复制链路卡死。容量太大又浪费磁盘而且清空队列时扫描时间会变长。材料里给的经验值是“分区大小应为数据流量的 6 倍一般可以设为 2G”这个数字不是拍脑袋定的是基于峰值时段日志产生量的估算。我一般会先在复制服务器上执行admin disk_space看历史占用曲线再按每小时最大日志量的六倍去算2G 作为一个起步参考值。分区建好后不是一劳永逸要定期看占用率。分区使用率长期超过 70%就要考虑追加分区或者提前触发队列清理。追加分区的命令格式如下add partition partition_name on device_name with size size gopartition_name是分区名device_name是复制服务器所在设备的逻辑名size要按设备块大小换算不是直接写字节数。常见做法是取当前分区占用峰值的两倍作为新分区大小避免刚加完又撑满。注意分区删除是危险操作执行drop partition partition_name前必须确认队列已经静止否则积压事务会全部丢失。2.2 最大线程数按连接数倒推别用默认值复制服务器的线程模型是每个连接在入站和出站两侧各占用一个工作线程外加管理线程、定时任务线程等。默认配置在连接数多的时候会明显不够表现是短期内大量连接处于等待状态复制延迟飙升。材料里给的公式是“最大线程数应该大于连接数数据库和复制服务器乘以 2 加 3”也就是把每个连接按两条线程算再留三个线程给管理和健康检查。这里说的连接数不是当前实时连接数而是峰值期主库、目标库、RSSD、RSM 等所有连接的总和。修改位置在rs_config的 max threads 参数改完后要重启复制服务器才生效。有一个容易踩的坑是线程数调大后操作系统文件描述符上限没跟着调启动时复制服务器直接报无法创建线程。所以调大线程数时要把操作系统的 max processes、max files 一并检查。调完用admin who查看线程列表确认每个数据服务器的 DSI、RSI 线程都正常起来了。2.3 _RSSD_prim 缺少 sa 权限RSM 连不上配置的黑匣子_RSD_prim 账号是复制服务器操作 RSSD 数据库用的账号如果它在 ASE 里没有 sa 权限RSM 客户端打开复制服务器配置时会报“无法访问复制服务器的配置”但复制数据本身可能一切正常。这个现象很有迷惑性因为它不影响数据同步只影响管理面。解决方法是到 ASE 里给该账号授权grant sa to _RSSD_prim go另外ASE 要建立一个专门用于复制的 sa 用户而且账号密码要和复制服务器完全一致。复制服务器在启动和连接时用的是这个账号如果 ASE 端修改了密码而复制服务器配置没同步改复制代理会反复重试连接错误日志里全是连接失败记录。RSM 客户端则要配置 ID_SERVER 及其数据库地址ID_SERVER 填错或者地址只配了本机客户端就找不到真正的复制服务器。这三个配置是复制链路管理面的基础建议在部署脚本里固化下来不要靠手工维护。3. 迁移复制服务器从断代理到重建队列的九步操作顺序3.1 前三步断开复制代理、静止队列、删除分区迁移复制服务器最忌讳顺序混乱比如先迁移数据库再断复制代理主库还在写日志旧机器停机后新事务日志就断了复制链路永久性中断。正确的第一步是断开复制代理让主库停止向复制服务器输送日志。ASE 和复制服务器两侧都可以操作-- ASE 侧停止指定库的复制代理 sp_stop_rep_agent db_name go如果有多库复制也可以从复制服务器侧统一挂起日志传输等价语法是suspend log transfer from data_server.database all。这一步做完后再执行admin quiesce force_rsi等待所有已接收事务回放完成并用admin quiesce_check确认状态。force_rsi的作用是强制 RSI入站接口把队列中的事务全部处理完只有返回值显示所有数据服务器都 quiet才能进入下一步。最后执行drop partition partition_name删除正在使用的复制分区把迁移时可能残留的队列文件句柄释放掉。3.2 中间三步挂起路由、迁移数据库、归零第二截断点分区删除后要挂起到方向路由避免迁移过程中路由配置被其他会话修改。suspend route to replication_server go然后开始迁移数据库本体包括复制数据库和 RSSD 数据库。这里有几个硬性要求服务器名称要和以前完全一致因为复制服务器配置里存的是逻辑服务器名不认 IP迁移后要重新建立 ASE 复制用户并修改连接配置文件。如果是跨机器迁移接口文件里的端口和服务名是重灾区稍有不一致复制服务器就找不到目标库。数据库迁移完成后接着做第二截断点归零。这是一套固定组合命令use db_name go sp_stop_rep_agent db_name go dbcc settrunc(ltm,ignore) go use RSSD_db_name go rs_zeroltm data_server, database go use db_name go dbcc settrunc(ltm,valid) godbcc settrunc(ltm,ignore)是临时忽略第二截断点对日志截断的限制rs_zeroltm把 RSSD 中记录的最后事务时间归零让新的复制起点从当前日志位置开始。顺序不能错先停复制代理再忽略截断点最后归零。如果先执行rs_zeroltmRSSD 侧已经清零但 ASE 侧日志还挂着旧截断点之后恢复复制代理时可能出现日志空间被撑满的问题。3.3 后三步加分区、重建队列、恢复复制代理截断点归零后重新建立复制分区add partition partition_name on device_name with size size go然后重建队列让复制服务器按新的分区配置生成入站和出站队列Rebuild queues goRebuild queues会读取 RSSD 中的发布、订阅、路由配置重新生成队列结构。这一步结束后用admin health和admin who, sqm确认队列状态正常再看rs_helproute确认路由已挂起的状态已恢复。最后启动复制代理sp_start_rep_agent db_name go启动后不要急着离开观察至少 30 分钟。常见情况是代理启动成功但 DSI 线程仍然 down原因是目标库上某个表结构和订阅定义不一致这种问题迁移前没暴露迁移后就只能通过resume connection逐步处理。所以迁移后的健康检查至少要覆盖健康状态、队列占用、DSI 线程三部分。4. 常用命令速查admin who 系列与代理恢复、挂起4.1 状态类命令先学会读输出再动手复制服务器的状态命令集中在admin系列每次排障都绕不开。最基础的是admin health返回 OK 表示主进程正常。admin who列出当前所有线程包含线程类型、所属数据服务器、状态。更细一点的是admin who_is_down和admin who_is_up直接筛选出断线和在线的线程清单省去在完整线程列表里翻找的功夫。队列监控要用admin who, sqm它的输出里有几个关键列First Seg. block、Last Seg. block、Next read。这三个数值越接近说明队列越空差值拉大说明积压。admin who, sqt则是看队列事务线程重点是 inf 列形如******x:yx位置是队列号如果显示为负数说明该队列中的事务状态异常这个队列已经不可正常处理了。磁盘占用则用admin disk_space查看判断分区是否要扩容。4.2 配置查询命令rs_help 家族一页纸配置查询命令主要面向 RSSD 中的系统表常用的有这些命令用途rs_config查看复制服务器整体配置含线程数、内存等参数rs_helpdb查看参与复制的数据库及同步状态rs_helperror查看错误处理类配置rs_helppub/rs_helppubsub查看发布与订阅关系rs_helpsub查看订阅定义rs_helprep查看复制服务器本身的复制关系rs_helprepdb查看被复制数据库信息rs_helpreptable查看被复制的表rs_helproute查看路由配置这些命令在 RSM 客户端和 isql 里都可以执行。实际排障时我一般先跑rs_helproute确认路由方向有没有乱再跑rs_helpdb看复制库状态最后才决定要不要动队列。配置查询命令不会修改数据可以放心反复执行。4.3 恢复与挂起命令resume connection 的两个参数要分清DSI 线程 down 后恢复命令是resume connection有两个可选参数含义完全不同-- 跳过当前阻塞事务 resume connection to data_server.database skip transaction go -- 重新执行当前事务 resume connection to data_server.database execute transaction goskip transaction是跳过当前事务继续投递后面的数据适合目标库已经存在相同记录、无法再插入的场景execute transaction是让 DSI 重新执行该事务适合 DSI 因网络抖动或锁超时误判失败的情况。选错参数会放大故障目标库数据冲突时选 execute transactionDSI 会反复执行失败事务队列越积越多。复制代理的启停则是 ASE 侧操作-- 启动复制代理 sp_configure enable rep agent threads, 1 sp_config_rep_agent enable sp_start_rep_agent db_name go -- 停止复制代理 sp_configure enable rep agent threads, 0 sp_config_rep_agent disable sp_stop_rep_agent db_name go注意sp_configure和sp_config_rep_agent在 ASE 不同版本里作用域有差异低版本只认sp_configure高版本推荐用sp_config_rep_agent。恢复代理后一定要用admin who确认线程真正起来了而不是只在配置层面置为 enable。4.4 用户权限命令最小化复制专用账号复制服务器的用户管理一般遵循最小权限原则create user user_name set password passwd null go grant sa to user_name goset password后面的null表示不设置登录有效期限制适合长期运行的复制账号。grant sa是授予系统管理员权限注意复制服务账号不像业务账号需要大量表权限sa 权限已经覆盖了对 RSSD 系统表的访问。删除账号用drop user user_name。这里有一个容易忽略的点如果复制服务器和 ASE 之间已经建立了连接直接 drop user 会导致正在运行的复制链路断开应该先停复制代理再删账号。5. 故障排查与避坑队列阻塞、负数队列、截断点不归零5.1 DSI 线程 down备库延迟持续拉大现象admin who中 DSI 线程状态为 downadmin who, sqm显示队列占用不断上涨备库数据时间戳停留在很久以前业务查询已经能感知到延迟。原因目标库执行复制事务失败最常见的是主键冲突或唯一索引冲突。DSI 线程重试若干次后进入挂起状态后续所有事务都堵在队列里形成一个越积越大的阻塞点。解决先到复制错误日志里定位是哪个表、哪条事务失败然后连续执行resume connection to data_server.database skip transaction每执行一次跳过一个阻塞事务重复执行直到 DSI 恢复工作。如果队列里坏事务很多可以连续多执行几次而不是只执行一次。跳过的事务要记录时间点和表名之后单独补数。5.2 admin who, sqt 输出队里列号为负数现象admin who, sqt输出中 inf 列形如******x:y其中x位置是负数。原因这个队列中的事务标记异常队列扫描线程无法按正常顺序读取和分发可能由强制断电、复制服务器进程被杀或者磁盘写满导致。解决用admin who, sqm查到这个队列对应的q_number确认q_type是出站0还是入站1然后执行sysadmin sqm_purge_queue q_number, q_type将该队列的数据清空。清空后该队列所有未投递事务都会丢失需要重建队列并从主库重新抽取。这在操作前一定要知会业务方不能只当技术操作直接执行。5.3 队列正常但日志截断不了现象复制状态显示正常但执行dump tran xxx with truncate_only报错或者日志空间一直不释放复制数据库的第二截断点长时间停在旧位置。原因RSSD 中记录的最后事务时间没有归零ASE 认为复制代理还需要保留这部分日志。这种情况常见于复制代理异常停止后又被强行拉起的场景或者迁移过程中漏掉了rs_zeroltm步骤。解决按迁移章节的顺序处理先sp_stop_rep_agent db_name再dbcc settrunc(ltm,ignore)然后到 RSSD 执行rs_zeroltm data_server, database最后dbcc settrunc(ltm,valid)恢复。归零前要评估丢失复制起点的风险如果主库日志已经因为空间压力被截断过归零后需要全量重新同步。5.4 RSM 无法访问复制服务器配置现象RSM 客户端能连接主库但打开复制服务器配置时报权限错误或找不到配置对象。原因_RSSD_prim账号在 ASE 中缺少 sa 权限无法读取 RSSD 里的配置表。另一个常见原因是 RSM 客户端配置里 ID_SERVER 的数据库地址指向了错误的服务器。解决在 ASE 中执行grant sa to _RSSD_prim然后在 RSM 客户端重新连接。如果授权后仍报错检查 ID_SERVER 配置是否指向正确的主机和端口必要时删除客户端缓存重新配置。这类问题不影响数据复制本身容易被人忽略但会在你需要改配置时卡住整个操作窗口。6. 一个进阶技巧独立模式清空队列后的数据再同步复制状态正常但队列不断增长或者确认某个队列里的事务已经损坏靠resume connection已经救不回来时就要考虑清空队列。先把复制服务器停掉用独立模式启动。独立模式是在启动批处理里加-M参数这样复制服务器只加载 RSSD 配置不连接主库和目标库避免清队列过程中新的日志不断进入。# 原启动脚本基础上加 -M进入独立模式 startserver -f RS_APP.cfg -M然后用 SQL Advantage 连接 RSSD先执行admin who, sqm拿到队列号和类型admin who, sqm go记录输出中的队列号q_number和类型q_type0 表示出站队列1 表示入站队列然后逐条清空sysadmin sqm_purge_queue q_number, q_type go执行后admin disk_space会看到队列空间被释放。但清空队列等于丢掉了所有未投递事务所有参与复制的表已经不同步必须重新做一次全量同步。常见做法是把主库的表bcp out出来再bcp in到目标库同时检查复制错误日志里最初导致队列卡住的原因通常逃不开主键约束或唯一索引冲突。有一次我清完队列急着恢复业务忘了把出站队列的q_number记下来结果连着把入站队列也清了回放起点彻底丢失只能全量重灌。从那以后我每次做队列清理都强制先导出一份队列清单和待同步表的 bcp 快照再执行任何破坏性操作。希望帮到你。本文还有配套的精品资源点击获取