1. 为什么11g最新版这个限定词值得单独拎出来说先把场景摆清楚。Oracle 11g 到 Kafka 的增量实时同步这个需求在数据集成圈子里出现频率极高但真正落地时你会发现网上能搜到的方案大多默认你用的是 12c 及以上版本因为那些版本有可插拔数据库、有更完善的 LogMiner 视图、有开箱即用的 GoldenGate 适配。而 11g 这个版本尤其是 11.2.0.4 这个被大量存量系统沿用的最新版坑位密度完全不是一个量级。我接触过的几个项目里源端清一色是跑了七八年的 11g 库业务方既不敢升级也不敢停机但下游的实时数仓、风控引擎、消息推送又急需这张表的变更流。这时候 OGGOracle GoldenGate就成了绕不开的选项——它对源库侵入小、支持事务级一致性、能直接投递到 Kafka。但能跑通和跑得稳之间隔着至少十几个配置细节。这篇内容我打算按真实落地的顺序来写先讲清楚 OGG 在 11g 上的能力边界和版本匹配逻辑再拆解抽取端、投递端的核心配置然后重点讲 Kafka 侧的消息格式与幂等处理最后把我踩过的几个典型坑完整复盘一遍。适合正在做异构同步、CDC 采集、实时数仓入湖的同行参考也适合刚接触 OGG 但被 11g 环境卡住的朋友。提示本文所有配置示例基于 Oracle 11.2.0.4 OGG 12.3.0.1 Kafka 2.x 的常见组合不同小版本间参数名可能有细微差异落地前务必以官方文档为准。2. OGG 在 11g 环境下的能力边界与版本匹配逻辑2.1 11g 到底缺了什么导致方案要绕路很多人一上来就问OGG 支不支持 11g 到 Kafka答案是支持但支持的姿势和 12c 完全不同。核心差异集中在三个地方。第一是LogMiner 的补充日志要求。11g 的 LogMiner 在解析 UPDATE 语句时如果没开足够的 supplemental logging拿到的前像before image是不完整的OGG 抽取出来的变更记录里那些未修改字段会是 null。这在同步到 Kafka 后做宽表拼接时是致命的——下游拿到的是一条残缺的变更。12c 之后有 schema-level 的强制补充日志配置粒度更细11g 只能靠 database-level 的ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS兜底代价是 redo 日志量膨胀。第二是集成抽取模式Integrated Extract的可用性。11g 虽然从 11.2.0.2 开始支持集成抽取但早期版本 bug 较多很多团队最终退回经典抽取模式Classic Extract。经典模式直接读 online redo 和 archive log对源库压力更可控但要求 OGG 的抽取进程必须能访问到所有归档路径。第三是字符集与 NLS 参数。11g 库如果建库时用的是 ZHS16GBK而 Kafka 侧消费端默认按 UTF-8 解析中文乱码几乎是必然的。这个问题在 12c 的多租户架构下反而更容易通过 PDB 级别参数隔离解决。2.2 版本组合的选型逻辑版本匹配这件事我的经验是就低不就高。OGG 的版本必须和源端 Oracle 的版本兼容同时还要和 Kafka 的 Connect API 版本对齐。下面这张表是我实际验证过的组合供参考。组件推荐版本选型理由Oracle 源库11.2.0.411g 最后一个稳定版补丁最全OGG12.3.0.1对 11g 兼容性好自带 Kafka HandlerKafka2.4 及以上支持幂等生产者和事务JDK1.8OGG 12.3 对高版本 JDK 支持不稳这里要特别说明为什么不用 OGG 19c。19c 的 OGG 虽然功能更强但它对源库的最低要求是 11.2.0.4 且需要额外打补丁而且它的 Kafka Handler 配置语法和 12.3 有较大差异网上能参考的 11g 案例几乎都是基于 12.3 的。选 12.3.0.1 不是因为它最好而是因为它在 11g 场景下的确定性最高。2.3 经典抽取 vs 集成抽取的取舍这个选择直接决定了后续的运维复杂度。经典抽取模式下OGG 的 Extract 进程以独立进程运行通过读取 redo 日志来捕获变更不依赖源库的 LogMiner 视图。它的优点是部署简单、对源库版本要求低缺点是当源库发生归档日志切换频繁时抽取延迟会波动。集成抽取模式则把抽取逻辑下推到数据库内部利用 LogMiner 的 API延迟更稳定但要求源库开启ENABLE_GOLDENGATE_REPLICATION参数且对 11g 的补丁级别有要求。我的建议是如果源库是 11.2.0.4 且已经打了最新 PSU可以尝试集成抽取如果是更早的 11.2.0.1 到 11.2.0.3老老实实用经典抽取别折腾。经典抽取在 11g 上的稳定性是经过大量生产验证的虽然配置稍繁琐但出问题时排查路径清晰。3. 抽取端配置从补充日志到 Extract 进程的完整链路3.1 补充日志的开启策略与代价评估补充日志是 OGG 能拿到完整变更的前提这一步没做对后面全白搭。11g 下需要开启两个级别。数据库级最小补充日志ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;表级全列补充日志针对需要同步的表ALTER TABLE schema_name.table_name ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;这里有个关键权衡ALL COLUMNS会让每次 UPDATE 都把整行所有字段写进 redoredo 生成量可能翻倍甚至更多。如果源库磁盘 IO 本来就紧张这个操作要慎重。我的做法是先用PRIMARY KEY级别的补充日志跑一段时间观察下游是否能接受前像缺失如果业务上确实需要完整前像再逐表切换到ALL COLUMNS。注意补充日志的开启是即时生效的但只对开启之后的 DML 生效。已经产生的 redo 日志里没有补充信息所以 OGG 抽取的起点必须设置在开启补充日志之后的时间点。3.2 Extract 进程的参数配置详解Extract 进程的配置文件通常放在 OGG 安装目录的dirprm下命名如ext_kafka.prm。核心参数如下EXTRACT ext_kafka SETENV (NLS_LANG AMERICAN_AMERICA.AL32UTF8) USERIDALIAS ogg_user DOMAIN OracleGoldenGate EXTTRAIL ./dirdat/ek TABLE schema_name.table_name, TARGET schema_name.table_name;逐行解释一下。SETENV设置 NLS_LANG 是为了让 OGG 进程在读取源库数据时按 UTF-8 编码处理避免中文乱码。这里有个细节源库的字符集如果是 GBKOGG 进程的 NLS_LANG 应该设置为AMERICAN_AMERICA.ZHS16GBK然后在投递到 Kafka 时再做转换。我见过太多人在这里搞反了导致抽取出来的数据在 Kafka 里是乱码。USERIDALIAS是 12.3 推荐的认证方式需要先在credentialstore里注册用户。如果用的是老式的USERID明文方式虽然也能跑但安全性差不建议在生产环境使用。EXTTRAIL指定本地 trail 文件路径这是 OGG 抽取和投递之间的缓冲。trail 文件的大小和滚动策略会影响延迟默认配置下每个 trail 文件 10MB滚动频繁时 IO 压力较大可以通过TRANLOGOPTIONS调整。3.3 抽取性能调优的几个关键参数Extract 进程的性能瓶颈通常不在 OGG 本身而在源库的 redo 生成速度和 OGG 读取归档日志的 IO 能力。几个实测有效的调优参数TRANLOGOPTIONS DBLOGREADER使用数据库的 LogMiner 读取器比直接读文件更稳定但会增加源库负载。TRANLOGOPTIONS CONVERTUCS2CLOBS处理 CLOB 字段时避免乱码。PASSTHRU在不需要做数据转换时开启减少 OGG 进程的 CPU 开销。还有一个容易被忽略的点Extract 进程的CHECKPOINTTABLE必须配置否则进程重启后无法准确恢复抽取位点可能导致数据重复或丢失。这个表建议放在独立的表空间避免和业务表争抢资源。4. 投递端配置Replicat 如何把变更写进 Kafka4.1 Kafka Handler 的工作机制OGG 投递到 Kafka 有两种方式一种是通过 Replicat 进程配合 Kafka Handler另一种是通过 OGG 的 Big Data 适配器。11g 场景下我推荐前者因为配置更直观出问题也容易定位。Kafka Handler 本质上是一个 Java 类Replicat 进程把变更记录交给它它再按照配置的格式序列化后发送到 Kafka 的指定 Topic。它的核心配置在 Replicat 的参数文件里通过TARGETDB和MAP语句指定。一个典型的 Replicat 配置REPLICAT rep_kafka TARGETDB LIBFILE libggjava.so SET propertydirprm/kafka.props GROUPTRANSOPS 1000 MAXTRANSOPS 10000 MAP schema_name.table_name, TARGET schema_name.table_name;GROUPTRANSOPS控制每多少条操作提交一次这个值直接影响 Kafka 的吞吐和延迟。设太小Kafka 里全是小批量消息吞吐上不去设太大延迟增加且一旦 Replicat 崩溃重复消息的量会很大。我的经验值是 1000 到 5000 之间具体看单条消息的大小。4.2 kafka.props 的关键配置项kafka.props是 Kafka Handler 的核心配置文件决定了消息怎么发、发到哪、发成什么样。几个必须关注的配置gg.handlerlistkafkahandler gg.handler.kafkahandler.KafkaProducerConfigFileproducer.properties gg.handler.kafkahandler.TopicMappingTemplateogg_${tableName} gg.handler.kafkahandler.formatjson gg.handler.kafkahandler.modeopTopicMappingTemplate决定了消息投递到哪个 Topic。${tableName}是动态变量会替换成实际的表名。这样每张表的变更会进入独立的 Topic下游消费时按表订阅逻辑清晰。如果所有表都投到一个 Topic消费端需要自己做过滤容易出问题。format支持json、avro、delimited等。JSON 最通用但体积大Avro 需要 Schema Registry但压缩率高、Schema 演进友好。11g 场景下如果下游是 Flink 或 Spark StreamingJSON 足够用如果是长期的数据湖入仓建议上 Avro。modeop表示按操作类型投递即 INSERT、UPDATE、DELETE 分别作为独立消息。还有一种modetx是按事务投递把同一个事务的所有操作打包成一条消息。这个选择取决于下游是否需要事务边界。风控场景通常需要事务边界用tx单纯的宽表同步用op更灵活。4.3 消息格式设计与下游消费约定消息格式这件事必须在项目初期就和下游团队对齐否则后期改格式的成本极高。我推荐在 JSON 里至少包含以下字段{ table: ORDERS, op_type: UPDATE, op_ts: 2024-01-15 10:23:45.123456, pos: 00000000000000001234, before: {ORDER_ID: 1001, STATUS: PENDING}, after: {ORDER_ID: 1001, STATUS: PAID} }op_ts是操作时间戳pos是 OGG 的位点信息这两个字段在排查数据延迟和重复时非常有用。before和after分别对应变更前后的值下游可以根据op_type决定怎么处理。这里有个坑如果源库没开ALL COLUMNS补充日志before里只有主键字段其他字段是 null。下游如果直接用before做数据回滚或比对会出错。所以格式设计时一定要和补充日志的配置联动考虑。5. 增量同步的幂等性与一致性保障5.1 为什么至少一次是常态精确一次要额外设计OGG 到 Kafka 的投递默认语义是至少一次。也就是说在 Replicat 进程崩溃重启、Kafka 生产者重试等情况下同一条变更可能被投递多次。这不是 OGG 的缺陷而是分布式系统的基本约束。要实现精确一次需要在消费端做幂等处理。常见的做法是用op_ts pos作为唯一键消费端维护一个已处理位点的缓存比如 Redis 或 Kafka 的 compacted topic遇到重复位点直接跳过。但这里有个陷阱op_ts的精度是微秒理论上同一微秒内同一张表可能有多个操作所以op_ts单独做唯一键不够必须加上pos。而pos在 OGG 重启后可能会重置所以更稳妥的方案是用源库的主键 操作类型 操作时间做联合唯一键。5.2 事务一致性的保障手段如果下游需要严格的事务一致性比如金融场景的账务同步modeop就不够了。这时候要用modetx让 OGG 把同一个事务的所有操作打包成一条消息。Kafka 的消息本身是原子的一条消息要么全成功要么全失败这样就保证了事务边界。但modetx有个限制大事务会导致消息体积过大可能超过 Kafka 的max.request.size限制。我遇到过一个大事务包含上万条 DML打包后消息超过 10MB直接发送失败。解决办法是在 OGG 侧配置gg.handler.kafkahandler.MaxGroupSize做拆分但拆分后就失去了事务原子性。所以大事务场景下事务一致性和消息大小需要权衡。5.3 位点管理与断点续传OGG 的位点管理依赖CHECKPOINTTABLEReplicat 进程每次提交后会把位点写入这个表。进程重启时会从上次的位点继续不会从头开始。这个机制在正常运维下没问题但在以下场景会出问题源库做了闪回或时间点恢复redo 日志位点变了OGG 的位点失效。Kafka Topic 被删除重建Replicat 的位点还在但消息已经丢了。这两种情况都需要手动干预重置 OGG 的位点。我的做法是定期备份CHECKPOINTTABLE并在 Kafka 侧保留足够长的消息retention.ms至少 7 天这样即使 OGG 位点丢失也能从 Kafka 的历史消息里恢复。6. 实战踩坑复盘那些文档里不会写的细节6.1 中文乱码的三层排查路径中文乱码是我遇到最多的报障。排查路径应该是从源到目标逐层检查第一层源库字符集。用SELECT * FROM nls_database_parameters WHERE parameter NLS_CHARACTERSET;确认。如果是ZHS16GBKOGG 的 Extract 进程SETENV要设成AMERICAN_AMERICA.ZHS16GBK。第二层OGG 进程的 NLS_LANG。这个在dirprm的参数文件里设置也可以通过操作系统的环境变量设置。两者冲突时参数文件里的优先。第三层Kafka Handler 的编码。kafka.props里要确保gg.handler.kafkahandler.format对应的编码是 UTF-8。如果是 JSON 格式默认就是 UTF-8但 Avro 格式需要额外指定。三层都对齐后中文乱码基本能解决。如果还有问题就要检查 Kafka 消费端的反序列化配置了。6.2 Replicat 进程频繁重启的根因定位Replicat 进程频繁重启日志里通常会有OGG-xxxxx的错误码。几个高频原因OGG-01296Kafka 连接超时。检查 Kafka 的advertised.listeners配置确保 OGG 所在主机能正确解析。OGG-01163消息格式错误。通常是TopicMappingTemplate里的变量名写错了或者表名包含特殊字符。OGG-01027位点冲突。多个 Replicat 进程用了同一个CHECKPOINTTABLE或者位点被手动修改过。排查时建议先把 Replicat 的日志级别调到DEBUG观察具体的错误上下文。但要注意DEBUG级别日志量极大排查完要记得调回INFO否则磁盘很快会被写满。6.3 源库 DDL 变更导致同步中断的处理OGG 默认不捕获 DDL所以源库加字段、改字段类型时OGG 的抽取和投递不会自动适配。如果源库加了字段OGG 的 trail 文件里还是旧的结构投递到 Kafka 的消息里不会有新字段。处理方式有两种一是停机窗口内同步修改 OGG 配置并重启进程二是用 OGG 的 DDL 同步功能但这需要额外配置DDL参数和GGSCHEMA复杂度较高。我的建议是在项目初期就和业务方约定DDL 变更必须提前通知走变更流程。技术上可以在 OGG 侧配置DDL INCLUDE MAPPED来捕获部分 DDL但 11g 下这个功能的稳定性一般不建议在生产环境依赖。6.4 性能瓶颈的快速定位方法同步延迟突然增大时按以下顺序排查看 Extract 进程的Lag at Chkpt如果这个值在增长说明抽取端跟不上源库的 redo 生成速度。看 Replicat 进程的Lag at Chkpt如果这个值在增长说明投递端跟不上抽取端。看 Kafka 的consumer lag如果这个值在增长说明下游消费端跟不上。三个 lag 分别对应三个环节定位到具体环节后再深入排查。Extract 慢通常是源库 IO 瓶颈Replicat 慢通常是 Kafka 网络或 Broker 负载问题消费端慢则是业务逻辑处理耗时。7. 几个能直接抄的配置模板与运维脚本7.1 完整的 Extract 参数模板EXTRACT ext_kafka SETENV (NLS_LANG AMERICAN_AMERICA.AL32UTF8) SETENV (ORACLE_HOME /u01/app/oracle/product/11.2.0/dbhome_1) SETENV (LD_LIBRARY_PATH /u01/app/oracle/product/11.2.0/dbhome_1/lib) USERIDALIAS ogg_user DOMAIN OracleGoldenGate EXTTRAIL ./dirdat/ek TRANLOGOPTIONS DBLOGREADER TRANLOGOPTIONS CONVERTUCS2CLOBS GETTRUNCATES WARNLONGTRANS 1h, CHECKINTERVAL 5m TABLE schema_name.table_name, TARGET schema_name.table_name;WARNLONGTRANS是长事务告警超过 1 小时的事务会记录警告每 5 分钟检查一次。这个参数在排查大事务导致的延迟时非常有用。7.2 Replicat 与 Kafka Handler 的联动配置REPLICAT rep_kafka TARGETDB LIBFILE libggjava.so SET propertydirprm/kafka.props GROUPTRANSOPS 2000 MAXTRANSOPS 10000 REPERROR (DEFAULT, DISCARD) MAP schema_name.table_name, TARGET schema_name.table_name;REPERROR (DEFAULT, DISCARD)表示遇到错误时把消息丢弃到 discard 文件而不是让进程崩溃。这个配置在生产环境很关键能避免单条脏数据导致整个同步链路中断。但 discard 文件要定期检查否则脏数据会一直堆积。7.3 日常巡检的几条命令# 查看 Extract 进程状态 ggsci info extract ext_kafka, detail # 查看 Replicat 进程状态 ggsci info replicat rep_kafka, detail # 查看 trail 文件使用情况 ggsci info extract ext_kafka, showch # 查看统计信息 ggsci stats extract ext_kafka, total这几条命令建议做成定时任务每小时执行一次输出到日志文件。一旦发现 lag 持续增长或进程状态异常及时告警。8. 写在最后的一点个人体会这套方案我在几个不同规模的 11g 环境里都落地过最大的感受是OGG 的配置本身不难难的是对源库行为的理解和上下游的协同。补充日志开多大、消息格式怎么定、幂等在哪一层做这些决策没有标准答案取决于业务对延迟、一致性、成本的容忍度。如果让我给一个最实用的建议那就是在正式同步之前先用一张小表跑通全链路把中文、大事务、DDL 变更、进程重启这几个场景都模拟一遍。这比看十篇文档都管用。很多坑只有在实际跑的时候才会暴露提前踩一遍总比上线后半夜被叫起来强。另外11g 毕竟是老版本OGG 的很多新特性用不上遇到问题时能参考的资料也少。建议在项目初期就建立自己的配置基线把每次变更都记录下来形成团队内部的避坑手册。这东西的价值随着时间推移会越来越高。
