跳到主要内容

数据实时同步典型问答(一)

简介​

在数据实时同步领域深耕多年，我们常常会被问到或者遇到一些重复的问题，有些回答随着我们经历的业务场景增多有所变化，但大部分都经得起推敲。我们将整理常见问题，并持续分享。

本期问题目录：

  • 数据库官方工具与第三方工具如何选择？
  • 业务能依赖实时同步工具的延迟吗？
  • 数据库实时同步工具为业务带来的真正价值是什么？
  • 同步工具能保持长期稳定和不丢数据吗？

数据库官方工具与第三方工具如何选择？​

一般成熟的数据库厂商会自带数据迁移、冷/热备份工具，甚至有一些厂商会提供完整的数据同步解决方案。

经过大量实践验证，我们总结出以下关键点：

官方工具优势：

  • 相对来说具备最好的迁移同步性能。
  • 能规避数据库自身的特定缺陷。
  • 支持第三方工具难以实现的特殊场景（如 Oracle GoldenGate 解析 Redo 日志）。

官方工具局限：

  • 对其他数据库支持有限或缺失。
  • 面向通用场景，特殊需求支持不足。
  • User Lock-in 倾向，数据进出难度不对等。

选型建议：

推荐按照场景来选择：

  • 涉及数据库本身运维的场景，如冷/热备份、同构迁移同步，推荐用官方工具。
  • 涉及异构数据迁移同步的场景，如关系型数据库到数据仓库/消息中间件/缓存/搜索引擎等，推荐用第三方工具。
  • 涉及特殊场景，如对数据进行过滤、计算，推荐用第三方工具。
  • 官方工具不支持但第三方工具支持的场景，推荐用第三方工具。

业务能依赖实时同步工具的延迟么？​

简单来说，非分布式事务保障的数据同步，都有延迟的风险。而分布式事务也不是没有代价，一般通过复制冗余和牺牲业务写入延迟（或中断）确保一致性。

数据同步的延迟分为 故障性延迟 和 业务性延迟，以下通过例子简要进行说明。

故障性延迟

  • 同步工具自身问题，包括内存紧张、逻辑 bug 等。
  • 源端或者对端数据库故障，前者拉不到数据，后者写入不了数据或者写入慢。
  • 对端数据存在约束冲突，写入报错。
  • 对端数据结构不完整，写入报错。

业务性延迟

  • 源端数据库导入数据或订正数据，导致流量增大。
  • 业务高峰流量超出同步工具处理能力。

虽然通过 任务调优、数据库资源规划、数据库变更规范 等措施可以降低延迟概率，但完全杜绝延迟并不现实。

业务能否依赖同步延迟，关键在于上述情况发生时，能否通过应急预案（如 业务主动降级）等方式进行规避。

数据库实时同步工具为业务带来的真正价值是什么？​

数据库实时同步工具第一价值是 增量，也就是新产生的变更能够复制到对端执行。相比传统 ETL ，有三大优势：

  • 实时性：增量是实时前提，实时是满足风控等特定场景的必要条件。
  • 高效性：增量仅同步变更数据，大幅节省带宽。如 10 亿数据一天变更 100 条，增量只需同步这 100 条变更数据，无需扫描整个数据集，更不需要重新搬迁 10 亿数据。
  • 完整性：增量可同步删除、结构变更操作，而 ETL 往往需要元数据服务进行辅助。

数据库实时同步工具第二价值是 实时。在源端数据源上新产生的数据，可以亚秒级或者秒级到目标数据源。

业务系统的数据库往往分工明确，这既是因为当前数据库技术存在局限，也因为业务对数据有多样的需求。同步工具通过实时同步弥合了这个需求和能力的差异，典型场景如既要保证事务读写，又要对数据做复杂检索分析。

同步工具能保持长期稳定和不丢数据么？​

同步工具的不稳定大部分是因为 数据结构变更、业务流量变化 和 数据库网络环境 三因素引起，控制或规划这些风险因素能够最大限度降低不稳定的发生概率。

数据结构变更 包括：

  • 变更方式和同步任务能力或配置不匹配，如原生数据库 DDL、pt-osc、gh-ost 等 Online DDL 工具。
  • 变更语法范围较大，同步工具可能支持不全，导致 DDL 变更错误或源表和目标表结构不一致。
  • 下游数据源结构改动或数据写入，未顾及同步任务，导致写入数据和目标结构不匹配或约束冲突。

业务流量变化 包括：

  • 业务造成突发峰值流量，同步任务未为此调优性能，导致内存紧张，同步不正常。
  • 数据库数据运维造成流量激增，如大范围数据订正，同步任务未为此调优性能，导致内存紧张，同步不正常。

数据库网络环境 包括：

  • 数据库白名单未加入同步节点，任务调度到此类节点后无法连接数据库。
  • 跨地域网络延迟较高，导致数据读取或写入困难。

这些风险点，通常可以通过 数据库变更规范、任务峰值流量演练、资源上线检查 等措施大幅度缓解。

数据丢失的问题，从我们的经验来看，主要是由于 并行策略不匹配 导致乱序、对端数据写入 导致数据冲突、延迟过大没有及时处理 导致源端增量日志被删除。

  • 并行策略不匹配 场景较偏，一般是由唯一键字段值级联更新或重用造成。需要在同步工具中降级为更大粒度（比如表级）进行同步，不过往往事后发现，需要辅助用校验订正做处理。
  • 对端数据写入 导致同步工具写入数据冲突，一般通过回收业务账号写入权限，规范对端数据库使用方式进行解决。
  • 延迟过大没有及时处理 则需要在同步工具中设置并验证告警，并且加长源端数据库保留日志的时间，一般建议大于等于24小时。

通过以上措施，可大幅提升同步系统的稳定性和数据可靠性，为业务提供坚实的数据基础保障。