S3 Sink连接器rotate.schedule.interval.ms配置异常及暂停影响咨询

一、为什么rotate.schedule.interval.ms未触发每日自动刷新 #

你遇到的问题核心是混淆了rotate.schedule.interval.ms与flush.interval.ms的作用：

• rotate.schedule.interval.ms：仅控制文件滚动的时间间隔，但它不会主动触发flush动作——只有当有新消息写入，或者达到flush.size/flush.interval.ms阈值时，连接器才会检查是否满足rotate条件。如果主题长时间无新消息，且未配置flush.interval.ms，连接器不会主动触发flush和rotate。
• flush.interval.ms：这才是控制“即使未达到flush.size，也定期强制flush”的参数。若要实现每日强制刷新，必须同时配置flush.interval.ms=86400000（1天），配合rotate.schedule.interval.ms使用，才能确保到点就flush并滚动文件，无论消息量多少。

另外，需确认你使用的分区器：如果用了TimeBasedPartitioner，需保证partition.duration.ms与rotate.schedule.interval.ms匹配，否则可能出现分区时间与滚动时间不一致的情况。

二、连接器暂停对rotate.schedule.interval.ms的影响 #

连接器暂停期间，所有消费、处理、flush/rotate检查都会完全停止，不会推进任何计时逻辑：

1. 暂停时间不计入有效计时：rotate.schedule.interval.ms是基于**墙钟时间（实际物理时间）**判断的，但只有当连接器处于运行状态时，才会执行rotate条件检查。
2. 恢复后的触发逻辑：当连接器恢复运行后，若当前时间与最后一次rotate的时间差已经超过rotate.schedule.interval.ms设置的1天，那么在处理第一条消息时，会立即触发rotate操作；如果没有新消息，仍需依赖flush.interval.ms来触发强制flush。
3. 连接器不会“补偿”暂停时间：连接器不会将暂停的时间计入rotate.schedule.interval.ms的累计时长，仅以实际物理时间差作为判断依据。

总结建议 #

• 新增flush.interval.ms=86400000配置，确保每日强制flush，配合rotate.schedule.interval.ms实现预期的每日文件滚动。
• 检查连接器暂停的原因（如资源不足、Kafka集群压力大等），尽量减少不必要的暂停，避免刷新逻辑被频繁中断。

内容的提问来源于stack exchange，提问作者fahadhub