OMS liboblog.enable_convert_timestamp_to_unix_timestamp 配置不生效问题

AntTech_ZUHSV7 · 2025 年5 月 13 日 17:55

【使用环境】测试环境
【 OB or 其他组件】OMS 4.2.7
【使用版本】OMS 4.2.7
【问题描述】我们发现数据同步至kafka，时间戳类型字段（timestamp(3)）都被转换成时间戳格式，请问如何调整为原数据的格式呢？

kafka输出的数据，

实际数据格式：

尝试调整liboblog.enable_convert_timestamp_to_unix_timestamp配置。

数据格式仍然不生效。
调整后，尝试新建组件的方式，创建新组件。

重新捕获数据，仍然：

另外，字段类型截图如下：

create_user_ bigint(20) DEFAULT NULL COMMENT ‘创建用户’,
create_date_ timestamp(3) NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT ‘创建时间’,
update_user_ bigint(20) DEFAULT NULL COMMENT ‘更新用户’,
update_date_ timestamp(3) NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT ‘更新日期’,

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

论坛小助手 · 2025 年5 月 13 日 17:56

根据您提供的信息，OMS 社区版在数据同步至 Kafka 时，时间戳类型字段（timestamp(3)）被转换成了 Unix 时间戳格式。您尝试通过调整 liboblog.enable_convert_timestamp_to_unix_timestamp 配置来解决此问题，但未见效果。

以下是针对该问题的分析和解决方案：

1. 配置项的作用

liboblog.enable_convert_timestamp_to_unix_timestamp 是 OMS 中的一个配置项，用于控制是否将 timestamp 类型字段转换为 Unix 时间戳格式。

如果设置为 true，则会将 timestamp 字段转换为 Unix 时间戳。
如果设置为 false，则保持原始的 timestamp 格式。

从您的描述来看，您希望保持原始的 timestamp 格式，因此需要确保该配置项设置为 false。

2. 配置不生效的原因

根据文档和实践经验，以下可能是导致配置不生效的原因：

(1) 配置未正确生效

确保在 OMS 的配置文件中正确设置了 liboblog.enable_convert_timestamp_to_unix_timestamp=false。
检查是否重新加载了配置或重启了相关服务以使更改生效。

(2) 版本限制

您使用的 OMS 版本为 4.2.7，需确认该版本是否支持 liboblog.enable_convert_timestamp_to_unix_timestamp 配置项。如果版本过低，可能需要升级到更高版本以支持该功能。

(3) 其他配置冲突

检查是否有其他配置项（如 liboblog.output_format 或 liboblog.timestamp_format）影响了时间戳的输出格式。
确保没有其他插件或脚本对时间戳进行了额外的转换。

3. 解决方案

以下是具体的排查和解决步骤：

(1) 检查配置项

登录 OMS 控制台或编辑配置文件，确认 liboblog.enable_convert_timestamp_to_unix_timestamp 是否已设置为 false。

示例配置：

{
  "liboblog.enable_convert_timestamp_to_unix_timestamp": "false"
}

(2) 验证配置生效

修改配置后，重启 OMS 服务以确保配置生效。

使用以下命令验证配置是否正确加载：

grep "liboblog.enable_convert_timestamp_to_unix_timestamp" /path/to/oms/config/file

(3) 检查输出格式

如果配置已正确设置但仍无效，可以尝试手动测试时间戳的输出格式：
```
SELECT create_time_, update_time_ FROM your_table;
```
确保数据库中的时间戳字段存储的是标准的 timestamp 格式。

(4) 升级 OMS 版本

如果当前版本不支持 liboblog.enable_convert_timestamp_to_unix_timestamp，建议升级到最新版本（如 4.3.x 或更高版本），以获得更好的兼容性和功能支持。

(5) 调试日志

启用调试日志，查看 OMS 在处理时间戳字段时的具体行为：
```
obdiag log collect --module oms --level debug
```

4. 参考文档

OMS 配置说明：请参考 OMS 官方文档中关于 liboblog 配置项的详细说明。
时间戳格式：参考文档片段 3 和片段 7，了解如何设置 nls_timestamp_format 和 nls_timestamp_tz_format 来控制时间戳的显示格式。

5. 总结

如果按照上述步骤操作后问题仍未解决，请提供以下信息以便进一步排查：

OMS 的完整配置文件内容。
数据库中时间戳字段的定义（如 create_time_ 和 update_time_）。
OMS 日志中与时间戳处理相关的部分。

希望以上信息能帮助您解决问题！如有其他疑问，请随时联系 OceanBase 技术支持团队。

具体信息可参考以下文档:

周雄 · 2025 年5 月 13 日 18:54

你是想把时间戳转为2024-09-14 18:13:07.897这样的格式吗，数据同步选的是什么序列化方式，如果是debezium方式，可以修改组件配置sink.dateConvertFormat来配置时间格式

AntTech_ZUHSV7 · 2025 年5 月 13 日 20:35

老师，

您好，我们用的是“Canal”的序列化方式。

组件已经调整：

但是，似乎还是不行。配置错了吗？还是因为序列化方式的问题呢？

输出结果：

论坛小助手 · 2025 年5 月 13 日 20:46

根据您提供的信息，您在使用 OMS 社区版时选择了 CANAL 序列化方式，但时间戳字段仍然被转换为 Unix 时间戳格式。以下是针对该问题的分析和解决方案：

1. 问题分析

(1) 序列化方式的作用

在 OMS 中，序列化方式决定了数据从源端同步到目标端时的消息格式。
您选择的 CANAL 序列化方式是基于阿里巴巴 Canal 的协议，通常会将 timestamp 类型字段转换为 Unix 时间戳格式。

(2) 配置是否正确

根据您提供的配置截图和 OCR 提取的内容，serializerType 已设置为 CANAL，这表明序列化方式已正确配置。
然而，CANAL 序列化方式本身的设计可能会导致时间戳字段以 Unix 时间戳形式输出。

(3) 可能的原因

序列化方式限制：CANAL 序列化方式默认将 timestamp 转换为 Unix 时间戳，这是其设计的一部分。
其他配置影响：即使序列化方式正确，其他配置（如 dateConvertFormat 或 dateTimezone）可能会影响时间戳的输出格式。

2. 解决方案

以下是具体的排查和解决步骤：

(1) 确认序列化方式的行为

CANAL 序列化方式的设计可能导致时间戳字段始终以 Unix 时间戳形式输出。
如果需要保持原始的 timestamp 格式，可以尝试更换为其他序列化方式，例如 DEFAULT 或 DEFAULT_WITH_SCHEMA。

(2) 更换序列化方式

修改配置文件中的 serializerType，将其更改为 DEFAULT 或 DEFAULT_WITH_SCHEMA：
```
{
  "sink": {
    "serializerType": "DEFAULT"
  }
}
```
重新加载配置并重启 OMS 服务以使更改生效。

(3) 验证输出格式

更改序列化方式后，重新测试数据同步至 Kafka 的输出结果，确认时间戳字段是否保持原始格式。

(4) 调整时间戳格式

如果必须使用 CANAL 序列化方式，可以通过下游消费端（如 Kafka 消费者）对时间戳字段进行转换，将 Unix 时间戳还原为标准的 timestamp 格式。

(5) 检查其他配置

确保 dateConvertFormat 和 dateTimezone 配置未对时间戳格式产生额外影响：

{
  "sink": {
    "dateConvertFormat": "yyyy-MM-dd HH:mm:ss.SSS",
    "dateTimezone": "+00:00"
  }
}

3. 参考文档

序列化方式说明：参考文档片段 7 和片段 8，了解 OMS 社区版支持的序列化方式及其行为。
时间戳格式控制：参考文档片段 6，了解如何通过 nls_timestamp_format 和 nls_timestamp_tz_format 控制时间戳的显示格式。

4. 总结

如果按照上述步骤操作后问题仍未解决，请提供以下信息以便进一步排查：

完整的 OMS 配置文件内容。
数据库中时间戳字段的定义（如 create_date_ 和 update_date_）。
OMS 日志中与序列化方式和时间戳处理相关的部分。

希望以上信息能帮助您解决问题！如有其他疑问，请随时联系 OceanBase 技术支持团队。

具体信息可参考以下文档:

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

周雄 · 2025 年5 月 14 日 09:34

目前只有debezium序列化方式支持这样配置

AntTech_ZUHSV7 · 2025 年5 月 14 日 13:53

如果Canal呢，有法子吗？

AntTech_ZUHSV7 · 2025 年5 月 14 日 14:07

也就是说，其实

liboblog.enable_convert_timestamp_to_unix_timestamp 需要搭配 “dateConvertFormat”: “yyyy-MM-dd HH:mm:ss.SSS” 一并使用，

而只有序列化方式为：debezium，liboblog.enable_convert_timestamp_to_unix_timestamp 和 sink.dateConvertFormat 才会生效，是这么理解吗？

周雄 · 2025 年5 月 14 日 14:14

目前只有debezium方式支持dateConvertFormat配置，其他方式配置dateConvertFormat是不生效的，liboblog.enable_convert_timestamp_to_unix_timestamp跟序列化方式没有关系。后续我们会增加其他序列化方式的支持

AntTech_ZUHSV7 · 2025 年5 月 14 日 15:34

嗯嗯，那我想咨询一下，Canal的序列化方式，

源端字段类型为：
create_date_ timestamp(3) NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT ‘创建时间’,
update_date_ timestamp(3) NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT ‘更新日期’,

并且源端数据显示为：yyyy-MM-dd HH:mm:ss:SSS

通过OMS，写入到kafka，不管如何配置，肯定就会转换为如下时间戳格式吗？

周雄 · 2025 年5 月 14 日 16:42

是的，这个目前没办法更改。写入到kafka到数据格式可以参考这个文档https://www.oceanbase.com/docs/community-oms-cn-1000000002947346#10-title-%E6%95%B0%E6%8D%AE%E5%BA%93%E4%BC%A0%E8%BE%93%E5%88%B0%E6%96%87%E6%9C%AC%E5%8D%8F%E8%AE%AE%E7%9A%84%E6%A0%BC%E5%BC%8F%E8%AF%B4%E6%98%8E

AntTech_ZUHSV7 · 2025 年5 月 14 日 18:02

好的，谢谢了呢。

我们确认没法通过配置行为处理就行，我们这边进行数据适配就好。麻烦老师了呢。