使用 TapData,化繁为简,摆脱手动搭建、维护数据管道的诸多烦扰,轻量替代 OGG, Kettle 等同步工具,以及基于 Kafka 的 ETL 解决方案,「CDC + 流处理 + 数据集成」组合拳,加速仓内数据流转,帮助企业将真正具有业务价值的数据作用到实处,将“实时数仓”方法论落进现实。
TapData 持续迭代产品能力,优化用户体验的同时,也在不断探索各行各业数据需求的底层逻辑,力求为行业用户提供更加简洁、更具针对性的解题思路。本期内容便是我们在公共卫生领域做出的实践以及展望。
案例速览:
客户:某政务体系下的公共卫生机构
需求:SAP Sybase → PostgreSQL 的数据迁移
挑战:Sybase CDC(变更数据捕获)能力,数据源与目标间的持续、无缝同步
在数据库技术的发展史上,Sybase 无疑是一个重要的名字。作为最早的商业关系型数据库管理系统之一,Sybase 自 20 世纪 80 年代问世以来,在金融、通信等多个领域都得到了广泛应用。其高性能、高可靠性和强大的事务处理能力,使其在过去的几十年中成为众多关键业务系统的核心支柱。
然而,在 2010 年被 SAP 收购后,其发展轨迹发生了变化。收购后,SAP 逐渐将其重点转向自身的旗舰产品 SAP HANA,这直接导致了 Sybase 数据库的迭代节奏放缓。根据官方生命周期文档等现有信息显示,SAP 计划在 2025 年结束对 Sybase ASE(Adaptive Server Enterprise)16.0 版本的主流维护支持。
对于许多仍然依赖 Sybase 的组织而言,这一计划背后无疑是巨大的挑战。尽管 Sybase 依然是一款现代化程度很高的数据库,具备大多数业务数据库所需的特性和能力,但维护终止的风险意味着这些组织必须为未来做好准备,以避免潜在的安全漏洞和技术支持中断。
某公共卫生机构(以下简称“该机构”)也是众多受影响的组织之一。多年来,该机构的关键业务数据一直存储在 Sybase 数据库中,且系统运行稳定。但随着停止维护计划的临近,该机构开始着手为未来做出战略调整。为了确保业务的持续性和系统的安全性,决定将现有的 Sybase 数据库迁移到 PostgreSQL 这一同样现代化且社区支持强大的数据库平台上。
因此,这一迁移决定并非轻率之举,而是基于对长期发展与风险管理的深思熟虑。对于该机构而言,选择 PostgreSQL 一方面是为了获得长期的技术支持,另一方面也是希望利用一个能够随着业务发展而扩展的灵活平台。但迁移任务也并非易事,该机构需要面对的不仅仅是数据迁移的技术复杂性,还包括在迁移过程中如何保持数据的一致性和系统的连续性。
其次,可用性和性能问题日益凸显。随着时间的推移,旧有的Sybase系统在面对现代化应用的需求时,表现出明显的性能瓶颈。数据库响应速度变慢、查询效率下降,严重影响了业务的正常运作。同时,由于缺乏有效的技术支持,系统故障的修复时间也显著增加,给机构的日常运营带来了巨大的不确定性。
此外,随着时间的推移,数据库管理和维护的难度也会增加。缺乏更新的数据库系统可能无法适应新的业务需求和技术环境,导致整体系统的灵活性下降。这种情况将给机构的 IT 团队带来巨大的压力,并可能影响其业务的持续性和扩展性。
数据库迁移本身是一项复杂且充满挑战的任务。该机构在多个 Sybase 数据库中存储了大量关键的业务数据和历史记录。迁移的过程中,必须确保数据的完整性和一致性,任何数据的丢失或错误都会对机构的业务运营产生不可估量的影响。
特别是在涉及实时数据处理的场景中,该机构的业务系统需要在整个迁移过程中保持不间断的运行,这就要求迁移方案不仅要考虑如何将历史数据顺利迁移到新的 PostgreSQL 平台上,还要确保在迁移过程中,迁移期间,Sybase数据库和PostgreSQL数据库必须能够同时运行,所有的数据变化能够实时捕捉和同步,以避免数据不一致的问题。迁移过程中需要灵活应对各种潜在的技术挑战。
由于该机构的业务是连续运行的,即使在迁移过程中,数据也在不断变化。因此,实时捕获并同步数据变化成为了迁移过程中的关键环节。如果不能有效实现CDC,数据的不一致和延迟将直接影响到迁移的成功与否,并可能对业务运作造成无法挽回的损害。
鉴于上述种种迁移的紧迫性和复杂性。在保障数据安全、提升系统性能的同时,如何在不影响业务连续性的前提下,顺利完成这场大规模的数据库迁移,成为了机构决策层最为关注的问题。面对这一系列难题,选择一个强大的迁移工具和合作伙伴至关重要。正是在这种背景下,TapData 凭借其出色的 CDC 技术优势和丰富的行业经验,成为了该机构重点评估的合作对象。
Sybase 将数据库的存储内容分为了数据区与日志区两部分,在创建数据库时, 可以将两个部分分别分配到不同的设备中,如下命令:
1 # 创建一个设备, 名字为 s1_data, 存储在 /opt/sybase/data/s1_data.dat 文件中, 大小为 1G
2 DISK INIT name='s1_data', physname='/opt/sybase/data/s1_data.dat', size='1G';
3
4 # 创建一个设备, 名字为 s1_log, 存储在 /opt/sybase/data/s1_log.dat 文件中, 大小为 1G
5 DISK INIT name='s1_log', physname='/opt/sybase/data/s1_log.dat', size='1G';
6
7 # 创建一个数据库, 数据部分在 s1_data 上, 日志部分在 s1_log 上
8 Create Database s1 on s1_data='1G' log on s1_log='1G';
执行 sp_helpdb $db 命令,可以看到设置的结果:
在使用数据库进行增删改时,数据部分会以 db/schema/table/record 为组织层级进行记录。
日志部分会以 page/row 为组织层级进行记录。
数据部分可以使用 jTds 驱动进行读取, 与其他数据库并没有明显的差别。
关于日志部分,Sybase 并没有像 MySQL 或者 Oracle 一样,提供比较完善的读取和解析接口, 也没有任何可用的文档可供参考,这为实时事务的变更获取带来了极大的难度。
在对 Sybase ASE 进行实时数据变更获取之前,需要了解一系列这个数据库的的运行机制,这包括:
日志清理机制: 数据库的日志保留机制一般包括固定大小与固定时长两种,这两个方式容易理解,但是在遇到短时间批量事务,或者极长未提交事务等场景,都会出现日志丢失导致的错误恢复困难,与 PG 类似, Sybase 采用了第三种方案:标记防止清理,一个事务开始时,将会在数据库中放置一个标记位,这个标记位旨在告诉数据库,请不要清理标记位之前的日志信息,标记位往往随着事务的提交或者回滚消失,在进行日志读取时,合理设置与更新标记非常重要,如果错误设置标记位,除了会导致来不及读取的日志被清理之外,还会导致 Sybase 自身的内部异常,长期积累以后,Sybase 有可能终止服务。
日志满异常:在正常情况下,Sybase 会维护自身的日志使用情况,在日志空间被用光时,对数据库的任何写操作都会被阻塞,直到日志空间被释放为止,在异常情况下,Sybase 对自身日志的使用情况会出现计数错误,这会让数据库对自身的保护失效,新的写入会使数据库崩溃。
日志读取限制:Sybase 日志以 DB 为基本存储单位,一个 DB 内所有的 schema,以及所有的 table 都记录在同一块区域内,对同一个 DB 的日志获取进程只能同时存在一个。
基于此,就可以逐步开始进行事务日志的读取与解析,并解决以下问题:
对读取到的事件进行尝试解析,识别出关键的 DDL / DML 数据,并抓取所需数据, 完成 DEMO。
了解数据库的日志换页机制,保证可以逐步推进日志读取进度,开始调试。
了解在线/归档日志的概念,避免读取在线日志时的数据丢失, 得到基本工作的 V1 版本。
了解长时间未提交事务,部分提交事务,日志序号回退,日志序号重用等问题,得到数据准确的 V2 版本。
了解 Sybase 623 错误,sp_configure
命令,config_admin
命令,了解 aux 描述符,事务描述符等概念,了解 tablealloc,dbrepair 等指令,得到可长时间工作,数据准确,且尽可能最小影响 Sybase 数据库的 V3 版本。
处理不可避免的事件重复,了解日志块重新分配概念,得到 V4 版本。
了解字符编码,了解 Text/Binary 等 Lob 数据,了解 Sybase 存储 Lob 原理,了解 TimeStamp 类型是什么,得到可以处理 Lob/Timestamp 以及多字符编码的 CDC 的 V5 版本。
改造 TPCC 工具,适配 Sybase SQL,进行数周的长时间测试,处理连接复用,自动清理日志等问题,得到更加稳定的 V6 版本。
到此为止,一个可以线上使用的 Sybase CDC 实时事务变更获取功能就基本完成了,效果如下:
TapData 的 Sybase CDC 连接器允许实时捕捉 Sybase 能够高效捕捉并同步 Sybase 数据库中的数据变更,并将这些变更实时传输到包含 PostgreSQL 在内的各类目标数据库。这一功能确保了在整个迁移过程中,数据的一致性得到了可靠保障,同时避免了数据延迟或丢失带来的业务中断风险。
不仅如此,可视化的操作界面,以及极简的拖拉拽操作模式,也是 TapData 的一大优势。不同于传统的大规模数据库迁移通常涉及的复杂步骤,有效减少了人工干预的需求,降低了人为错误的风险。这使得整个迁移过程更加流畅,节省了大量的时间和资源。
在 TapData 的支持下,该机构顺利推进了 Sybase 数据库到 PostgreSQL 数据库的持续迁移同步,帮助机构在复杂的技术环境中实现了业务的平稳过渡与持续发展。该迁移方案的实施,一方面预防了 Sybase 停止维护可能带来的风险,顺利实现了数据库的现代化转型。另一方面,顺利突破了以 Sybase 为数据源的实时数据同步场景的技术挑战,为未来的业务发展提供数据层面的便利。
在本次合作中,TapData 在高效性、可靠性、易用性,以及技术支持与协作等方面,得到了该机构的充分认可。在整个项目期间,TapData 团队始终与该机构的 IT 团队紧密合作,提供了全程的技术支持和指导。无论是前期的 CDC 难点攻克,还是后续的持续优化与维需求,TapData 团队都做出了积极支持与响应,并最终提供有效的解决方案。
在回顾整个项目时,该机构总结了从挑战到成功的几个关键因素:
明确的迁移策略:在正式着手前,机构制定了详细的迁移计划,确保了每个步骤都经过充分的测试与验证。这种严谨的策略规划,是项目成功的关键所在。
实时数据同步的保障:TapData 的 Sybase CDC 能力,在项目中发挥了至关重要的作用。通过实时捕捉并同步数据变化,机构确保了迁移过程中数据的一致性和业务的连续性。
技术支持与团队协作:与相关供应商的紧密合作,是项目顺利实施的另一个关键因素。从前期的方案制定,到实际的技术实施,内外部的共同支持贯穿了整个项目周期,确保了迁移的成功。
随着业务的不断扩展与新增,越来越多的企业和机构将面临类似的数据库迁移和升级需求。TapData 在此过程中所展现出的灵活性、可靠性和高效性,使其成为应对这些挑战的理想合作伙伴。无论是处理实时数据同步、跨平台数据集成,还是确保数据的安全和一致性,TapData 都能够提供强有力的支持,帮助客户实现其数字化转型目标。
Sybase 数据库已经进入“生命倒计时”,作为业务核心选型之一的数据库系统,不应该再考虑使用这个数据库,已经使用这个数据库的场景,应该考虑尽快开始 Sybase 的淘汰与替换计划。
由于业务使用的复杂性,数据库的替换往往是一个极为长期,循序渐进的过程,一般会分为几个步骤:
新业务使用新的数据库。
旧的业务逐渐替换。
所有业务完成替换后,旧数据库下线。
在步骤 2 的过程中,在新旧数据库之间,一般情况下会存在一个较长时间的数据同步架构,如下图所示:
由于 Sybase 是闭源数据库,且没有足够的文档来说明实时数据同步的工作原理,能够稳定运行 Sybase 到其他数据库实时同步的数据集成产品,相比 Mysql 或者 Oracle / PG 等数据库来讲就相对少很多。
如果您有 Sybase 数据库替换的场景需要使用数据实时集成工具,TapData 会是个合适的选择。如果想要试用,欢迎点击文末「阅读原文」通过获取企业版来获取体验。
【推荐阅读】