Flink JOB_MANAGER_LEADER_PATH Znode 疑似泄漏问题

[林恬]

各位好：
    目前我使用的是Flink 1.9.2, HA使用ZK， 使用过程中发现ZK上的/leader/${job_id} 节点即使作业被Cancel了也不会被清理，导致运行久了之后，/leader/下有大量job_id的空ZNode，请问这块清理时机是什么时候呢？或者说这个没被清理的行为是否是1.9.2的bug呢？


 

[Roc Marshal]

Hi, 林恬.
首先，感谢你的反馈。
关于zk对应路径下的信息清理问题，你可以简单理解为，Flink对zk组件的依赖，仅在依赖其功能的范围内。并不会提供整个集群或者某个路径下和Flink job信息一致性的维护，即不会对其进行无效的信息清理，因为在HA的场景下，对无效路径的判定条件要复杂很多。




Best,
Roc Marshal.

















在 2020-06-28 09:12:41，"林恬" <[hidden email]> 写道：
>各位好：
>&nbsp; &nbsp; 目前我使用的是Flink 1.9.2, HA使用ZK， 使用过程中发现ZK上的/leader/${job_id} 节点即使作业被Cancel了也不会被清理，导致运行久了之后，/leader/下有大量job_id的空ZNode，请问这块清理时机是什么时候呢？或者说这个没被清理的行为是否是1.9.2的bug呢？
>
>
>&nbsp;

[林恬]

您的意思是，这些因为Cancel Job的遗留的空的leader/${job_id} ZNode是需要使用者自己定期清理么？




&nbsp;
&nbsp;
&nbsp;
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"Roc Marshal"<[hidden email]&gt;;
Date: &nbsp;Sun, Jun 28, 2020 10:07 AM
To: &nbsp;"FLINK中国"<[hidden email]&gt;;

Subject: &nbsp;Re:Flink JOB_MANAGER_LEADER_PATH Znode 疑似泄漏问题

&nbsp;

Hi, 林恬.
首先，感谢你的反馈。
关于zk对应路径下的信息清理问题，你可以简单理解为，Flink对zk组件的依赖，仅在依赖其功能的范围内。并不会提供整个集群或者某个路径下和Flink job信息一致性的维护，即不会对其进行无效的信息清理，因为在HA的场景下，对无效路径的判定条件要复杂很多。




Best,
Roc Marshal.

















在 2020-06-28 09:12:41，"林恬" <[hidden email]&gt; 写道：
&gt;各位好：
&gt;&amp;nbsp; &amp;nbsp; 目前我使用的是Flink 1.9.2, HA使用ZK， 使用过程中发现ZK上的/leader/${job_id} 节点即使作业被Cancel了也不会被清理，导致运行久了之后，/leader/下有大量job_id的空ZNode，请问这块清理时机是什么时候呢？或者说这个没被清理的行为是否是1.9.2的bug呢？
&gt;
&gt;
&gt;&amp;nbsp;

[Roc Marshal]

是的。


Best,
Roc Marshal.

















在 2020-06-28 10:10:20，"林恬" <[hidden email]> 写道：

>您的意思是，这些因为Cancel Job的遗留的空的leader/${job_id} ZNode是需要使用者自己定期清理么？
>
>
>
>
>&nbsp;
>&nbsp;
>&nbsp;
>------------------&nbsp;Original&nbsp;------------------
>From: &nbsp;"Roc Marshal"<[hidden email]&gt;;
>Date: &nbsp;Sun, Jun 28, 2020 10:07 AM
>To: &nbsp;"FLINK中国"<[hidden email]&gt;;
>
>Subject: &nbsp;Re:Flink JOB_MANAGER_LEADER_PATH Znode 疑似泄漏问题
>
>&nbsp;
>
>Hi, 林恬.
>首先，感谢你的反馈。
>关于zk对应路径下的信息清理问题，你可以简单理解为，Flink对zk组件的依赖，仅在依赖其功能的范围内。并不会提供整个集群或者某个路径下和Flink job信息一致性的维护，即不会对其进行无效的信息清理，因为在HA的场景下，对无效路径的判定条件要复杂很多。
>
>
>
>
>Best,
>Roc Marshal.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>在 2020-06-28 09:12:41，"林恬" <[hidden email]&gt; 写道：
>&gt;各位好：
>&gt;&amp;nbsp; &amp;nbsp; 目前我使用的是Flink 1.9.2, HA使用ZK， 使用过程中发现ZK上的/leader/${job_id} 节点即使作业被Cancel了也不会被清理，导致运行久了之后，/leader/下有大量job_id的空ZNode，请问这块清理时机是什么时候呢？或者说这个没被清理的行为是否是1.9.2的bug呢？
>&gt;
>&gt;
>&gt;&amp;nbsp;

[Ruguo Yu]

flink本身不提供cancel job后清理zookeeper上残留znode的功能或机制，包括hdfs上的部分数据，如果想清除的话，可手动操作或者自实现。














在 2020-06-28 09:12:41，"林恬" <[hidden email]> 写道：
>各位好：
>&nbsp; &nbsp; 目前我使用的是Flink 1.9.2, HA使用ZK， 使用过程中发现ZK上的/leader/${job_id} 节点即使作业被Cancel了也不会被清理，导致运行久了之后，/leader/下有大量job_id的空ZNode，请问这块清理时机是什么时候呢？或者说这个没被清理的行为是否是1.9.2的bug呢？
>
>
>&nbsp;

[Paul Lam]

Hi,

其实 HA 元数据没有自动清理是老问题了，可能要等到 ZK HA 的逻辑重构之后才可以解决，具体可以参考以下两个 ticket [1][2]。

不过即使 Flink 实现了自动清理，也没有办法处理外部原因导致作业退出而留下的元数据，所以还是要用户自己实现检测和清理的机制。

1. https://issues.apache.org/jira/browse/FLINK-6522 <https://issues.apache.org/jira/browse/FLINK-6522>
2. https://issues.apache.org/jira/browse/FLINK-10333 <https://issues.apache.org/jira/browse/FLINK-10333>

Best,
Paul Lam

> 2020年6月28日 12:29，于汝国 <[hidden email]> 写道：
>
>
>
>
> flink本身不提供cancel job后清理zookeeper上残留znode的功能或机制，包括hdfs上的部分数据，如果想清除的话，可手动操作或者自实现。
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 在 2020-06-28 09:12:41，"林恬" <[hidden email]> 写道：
>> 各位好：
>> &nbsp; &nbsp; 目前我使用的是Flink 1.9.2, HA使用ZK， 使用过程中发现ZK上的/leader/${job_id} 节点即使作业被Cancel了也不会被清理，导致运行久了之后，/leader/下有大量job_id的空ZNode，请问这块清理时机是什么时候呢？或者说这个没被清理的行为是否是1.9.2的bug呢？
>>
>>
>> &nbsp;