【 使用环境 】生产环境
【 OB or 其他组件 】obbinlogV4.0.1 OceanBase 4.2.5.1 OBProxy4.3.2
【 使用版本 】社区版
【问题描述】使用binlog服务同步数据，同步任务中有一张表的数据来源于多张表 业务SQL如下：insert into A select * from B join C ，表A的数据来源于表B和表C。当表B里的数据记录修改后，下游是可以查到的，同步正常，但是表A的数据里的记录仍然是原记录。查看binlog实例的libcdc日志中没有 EDIAG 与 ERROR记录，全是INFO，obbinlog支持这种形式的同步吗
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
根因分析场景: SQL 执行出错
根因分析命令: obdiag rca run --scene=sql_execution_error
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”
为了更好地诊断此问题，请您按照上述命令进行日志采集，并将生成的日志压缩包提供给我们。这些日志将帮助我们确认 binlog 同步过程中可能存在的问题。
另外，为了确定具体的问题，在此需要您提供一些信息：
INSERT INTO A SELECT * FROM B JOIN C 时设置了特定的事务参数（如隔离级别）？附上敏捷诊断工具 obdiag 使用帮助链接
根据您提供的 libcdc 日志内容，频繁出现的告警信息中包含 ret=-4169 和 ret=-4152 的错误代码。这些错误可能与 OceanBase 内部模块的日志解析或数据获取有关。以下是具体分析和建议：
ret=-4169:
根据日志中的上下文，该错误通常表示未能找到子模块（sub_mod）或无法解析日志级别（log level）。这可能是由于配置文件中某些模块的名称或参数设置不正确导致的。
ret=-4152:
该错误出现在 get_uint 函数调用中，表示在尝试从 MySQL 结果集中获取值时失败。这可能与 binlog 数据的序列化或反序列化过程有关。
结合您的问题描述和日志内容，以下是一些可能的原因：
binlog 同步机制限制：
OceanBase 的 binlog 服务目前主要支持基于行变更的同步。对于复杂的 SQL 操作（如 INSERT INTO A SELECT * FROM B JOIN C），binlog 可能无法完全捕获所有依赖表的数据变更。因此，当表 B 的数据修改后，表 A 的记录未更新可能是由于 binlog 未正确记录相关依赖关系。
日志解析问题：
日志中频繁出现的 ret=-4169 错误可能表明 libcdc 在解析某些模块的日志时遇到了问题。这可能与 OceanBase 集群的版本兼容性或配置有关。
数据类型不匹配：
如果表 A 的字段类型与表 B 和表 C 的字段类型不完全一致，可能会导致 binlog 同步过程中数据丢失或异常。
检查 binlog 配置：
确保 binlog 配置正确，特别是 binlog_row_image 参数是否设置为 FULL。可以通过以下命令查看当前配置：
SHOW VARIABLES LIKE 'binlog_row_image';
如果不是 FULL，可以尝试将其设置为 FULL：
SET GLOBAL binlog_row_image = 'FULL';
验证表结构一致性：
确保表 A 的字段类型、数量等与表 B 和表 C 完全一致。如果不一致，可以尝试调整表结构以避免同步问题。
重启 binlog 服务：
如果日志中频繁出现 ret=-4169 或 ret=-4152 错误，可以尝试重启 binlog 服务以清除潜在的缓存问题。
升级版本：
当前使用的 OceanBase 社区版 4.2.5.1 和 obbinlog V4.0.1 属于较新的版本，但仍可能存在一些已知问题。建议关注官方发布的补丁或新版本，及时升级以修复潜在的 bug。
使用 OMS 工具：
如果条件允许，可以考虑使用 OceanBase Migration Service (OMS) 替代 obbinlog 进行数据同步。OMS 提供了更强大的数据复制功能，能够更好地处理复杂 SQL 场景。
调整业务逻辑：
如果 binlog 同步确实无法满足需求，可以考虑调整业务逻辑，将复杂的 SQL 操作拆分为多个简单操作，确保每一步都能被 binlog 正确记录。
如果上述方法仍无法解决问题，建议按照以下步骤进行进一步排查：
采集诊断日志：
使用 obdiag 工具采集详细的诊断日志，包括 observer 和 libcdc 的日志：
obdiag gather scene run --scene=observer.perf_sql --env "{db_connect='-h127.0.0.1 -P2881 -utest@test -p****** -Dtest', trace_id='Yxx'}"
联系技术支持：
将采集到的日志压缩包提交给 OceanBase 技术支持团队，以便进一步分析问题根因。
根据现有信息，OceanBase 的 binlog 服务可能无法完全支持复杂的多表关联操作（如 INSERT INTO A SELECT * FROM B JOIN C）。建议先检查 binlog 配置和表结构一致性，并尝试重启服务或升级版本。如果问题仍未解决，可以使用 OMS 工具或调整业务逻辑作为替代方案。
如果您需要更多帮助，请随时提供更多信息或日志内容，我们将尽力为您解答！
详情请参考:
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
按照理解 是操作问题吧 但是这个操作应该不符合事务吧 如果你直接修改A表的数据 应该是可以的吧
不支持是吧。我让业务改一下
还有就是我们数据同步不全，目标端跟源端数据有差距，libcdc里重复报这些告警信息
把这四个日志信息发一下吧 具体看看什么问题
binlog_instance.log
libobcdc.log
logproxy.log
obproxy.log
不用了，数据量不一致的原排查出来了
好的 下次再有问题 可以把上面的日志 直接提供好一下 方便排查