暂无搜索历史
系列第 13 篇。前一篇聊了 ASM 上的 I/O,这一篇聊一个更让人纠结的问题:明明备库闲着,为什么采不了?
接 Oracle CDC,大家的注意力一般都在工具上:选 Debezium 还是 Flink CDC,怎么配、快不快。
这是上个月一个客户的对话。他们为了 CDC 专门升级了存储,结果延迟几乎没动。钱花出去了,效果没出来。
前九篇,我们聊了表名长度、数据类型、前镜像后镜像、物理日志和逻辑日志、单线程、堆实例、大事务 OOM、长事务回滚、SCN 追不上。
前面聊了性能、内存、数据类型这些“看得见”的问题。今天聊一个更隐蔽、但后果更严重的坑——长事务和回滚导致的数据一致性问题。
这不是第一次了。上次也是批量任务,堆内存加到960MiB,撑过去了。这次加到1.5GiB,又撑过去了。但下次呢?业务数据量还在涨,总有一天加内存也扛不住。
前面聊了单线程限制——LogMiner解析速度上限就在1万到1.5万条/秒,日志量越大性能越差。
聊了表名限制、数据类型、前镜像后镜像、物理日志和逻辑日志的区别。这些是“能不能用”的问题。
Oracle的redo log被归为“物理日志”,MySQL的binlog被归为“逻辑日志”。很多人知道这个分类,但真要说清楚“物理”和“逻辑”到底差在哪、对C...
但问题在于——这两个东西在redo log里到底是怎么存的?CDC解析的时候到底该用哪个?
客户端发了一个COMMIT,Oracle在redo log里写一条“提交”记录,完事。
30字符表名限制只是LogMiner众多坑里的一个。今天说第二个——数据类型支持。
前阵子帮一个团队排查问题,他们说数据同步任务跑了几个月,一直好好的,突然发现有几张表的数据没同步过来。查了半天,日志里有一行警告:
聊Oracle CDC的时候,很多人会问一个问题:从redo log到最终的数据变更,中间到底经历了什么?
第一次接触的时候,很多人会搞混。它们都跟“位置”有关,但“位置”的含义完全不同。把这三个东西搞清楚了,redo log的解析逻辑基本就通了一大半。
聊Oracle的redo log,Change Vector(改变向量)是一个绕不开的核心概念。
x聊到Oracle的redo log,很多DBA都能说出个大概——记录数据变更、用于恢复、归档日志……但再往下问,能答上来的人就不多了。
聊到数据库日志解析,很多人第一反应就是Oracle那套复杂的redo log体系。但如果你同时要处理MySQL、PostgreSQL或者国产数据库,会发现每个库...
项目刚开始的时候,需求看起来很简单:把Oracle的增量数据实时采集出来,推给下游。
上个月跟一个做数据平台的朋友吃饭,他跟我说他们团队最近刚完成一个事儿——把跑了大半年的Debezium Oracle增量采集链路,全部换掉了。
暂未填写个人简介
暂未填写技能专长
暂未填写学校和专业