按照我在工作中经验,有过几次需要重启zk集群,我是单个zk节点逐个重启。结论是导致了flink集群中任务的全部自动重启(基于最近一次的ckpt)。这对任务还是有一定影响的,因为ckpt是10分钟一次,会导致瞬间压力变高。
问下这个合理嘛,还是我配置的有问题or操作有问题。 |
哈哈, 我的也是, flink和ZK断开连接的话, 任务会全部重启, 这边测试了各种场景, 比如部署HA方案, 部署多个jobmanager都测试过, 任务都是会重启的, 同样不知道如何解决.
在 2020-11-16 18:39:29,"赵一旦" <[hidden email]> 写道: >按照我在工作中经验,有过几次需要重启zk集群,我是单个zk节点逐个重启。结论是导致了flink集群中任务的全部自动重启(基于最近一次的ckpt)。这对任务还是有一定影响的,因为ckpt是10分钟一次,会导致瞬间压力变高。 > >问下这个合理嘛,还是我配置的有问题or操作有问题。 |
又石沉大海了,有没有懂的人出来解释下。
RS <[hidden email]> 于2020年11月17日周二 上午9:35写道: > 哈哈, 我的也是, flink和ZK断开连接的话, 任务会全部重启, 这边测试了各种场景, 比如部署HA方案, > 部署多个jobmanager都测试过, 任务都是会重启的, 同样不知道如何解决. > > > > > > > > > > > > > > > > > > 在 2020-11-16 18:39:29,"赵一旦" <[hidden email]> 写道: > > >按照我在工作中经验,有过几次需要重启zk集群,我是单个zk节点逐个重启。结论是导致了flink集群中任务的全部自动重启(基于最近一次的ckpt)。这对任务还是有一定影响的,因为ckpt是10分钟一次,会导致瞬间压力变高。 > > > >问下这个合理嘛,还是我配置的有问题or操作有问题。 > |
Flink是利用Curator Framework来进行Leader Election和Retrieval,当时Curator的State
变成Suspended或者Lost的时候都会触发leader的revoke,进而导致需要Cancel掉之前的job 等待新的leader出现再重新调度 你可以提供一下JobManager的log或者自己观察一下JobManager的log是不是有Curator Connection State的变化 进而导致了Failover Best, Yang 赵一旦 <[hidden email]> 于2020年12月1日周二 下午7:13写道: > 又石沉大海了,有没有懂的人出来解释下。 > > RS <[hidden email]> 于2020年11月17日周二 上午9:35写道: > > > 哈哈, 我的也是, flink和ZK断开连接的话, 任务会全部重启, 这边测试了各种场景, 比如部署HA方案, > > 部署多个jobmanager都测试过, 任务都是会重启的, 同样不知道如何解决. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 在 2020-11-16 18:39:29,"赵一旦" <[hidden email]> 写道: > > > > > >按照我在工作中经验,有过几次需要重启zk集群,我是单个zk节点逐个重启。结论是导致了flink集群中任务的全部自动重启(基于最近一次的ckpt)。这对任务还是有一定影响的,因为ckpt是10分钟一次,会导致瞬间压力变高。 > > > > > >问下这个合理嘛,还是我配置的有问题or操作有问题。 > > > |
那Curator的state为什么会变成suspended或lost呢?我重启zk一般都是一台一台重启,而且我最近才刚刚又试过一次,我是先重启了follower
zk节点,结果刚刚kill一瞬间flink任务全部出问题了。 Yang Wang <[hidden email]> 于2020年12月1日周二 下午8:18写道: > Flink是利用Curator Framework来进行Leader Election和Retrieval,当时Curator的State > 变成Suspended或者Lost的时候都会触发leader的revoke,进而导致需要Cancel掉之前的job > 等待新的leader出现再重新调度 > > 你可以提供一下JobManager的log或者自己观察一下JobManager的log是不是有Curator Connection State的变化 > 进而导致了Failover > > > Best, > Yang > > 赵一旦 <[hidden email]> 于2020年12月1日周二 下午7:13写道: > > > 又石沉大海了,有没有懂的人出来解释下。 > > > > RS <[hidden email]> 于2020年11月17日周二 上午9:35写道: > > > > > 哈哈, 我的也是, flink和ZK断开连接的话, 任务会全部重启, 这边测试了各种场景, 比如部署HA方案, > > > 部署多个jobmanager都测试过, 任务都是会重启的, 同样不知道如何解决. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 在 2020-11-16 18:39:29,"赵一旦" <[hidden email]> 写道: > > > > > > > > > >按照我在工作中经验,有过几次需要重启zk集群,我是单个zk节点逐个重启。结论是导致了flink集群中任务的全部自动重启(基于最近一次的ckpt)。这对任务还是有一定影响的,因为ckpt是10分钟一次,会导致瞬间压力变高。 > > > > > > > >问下这个合理嘛,还是我配置的有问题or操作有问题。 > > > > > > |
我理解Curator和ZooKeeper的各个节点(包括Leader, Followers)之间都是长连接
如果你重启了ZK节点的其中一个,应该会导致和这个节点连着的Curator Client都Suspend, 进而导致相应的JobManager丢掉leader ship,所以会cancel掉当前任务然后重新运行 你可以验证一下是不是重启一个ZK节点只是特定的连到这台上面的Flink任务Failover,而不是全部的 最后,这个问题目前应该是没有办法通过Flink配置直接解决,除非是Curator#LeaderLatch对Suspend的状态处理可以进行改进 同时Flink里也需要在LeaderRetrieval中对Suspend状态的处理进行改进,不是直接notify一个empty leader Best, Yang 赵一旦 <[hidden email]> 于2020年12月3日周四 上午10:28写道: > > 那Curator的state为什么会变成suspended或lost呢?我重启zk一般都是一台一台重启,而且我最近才刚刚又试过一次,我是先重启了follower > zk节点,结果刚刚kill一瞬间flink任务全部出问题了。 > > Yang Wang <[hidden email]> 于2020年12月1日周二 下午8:18写道: > > > Flink是利用Curator Framework来进行Leader Election和Retrieval,当时Curator的State > > 变成Suspended或者Lost的时候都会触发leader的revoke,进而导致需要Cancel掉之前的job > > 等待新的leader出现再重新调度 > > > > 你可以提供一下JobManager的log或者自己观察一下JobManager的log是不是有Curator Connection > State的变化 > > 进而导致了Failover > > > > > > Best, > > Yang > > > > 赵一旦 <[hidden email]> 于2020年12月1日周二 下午7:13写道: > > > > > 又石沉大海了,有没有懂的人出来解释下。 > > > > > > RS <[hidden email]> 于2020年11月17日周二 上午9:35写道: > > > > > > > 哈哈, 我的也是, flink和ZK断开连接的话, 任务会全部重启, 这边测试了各种场景, 比如部署HA方案, > > > > 部署多个jobmanager都测试过, 任务都是会重启的, 同样不知道如何解决. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 在 2020-11-16 18:39:29,"赵一旦" <[hidden email]> 写道: > > > > > > > > > > > > > > >按照我在工作中经验,有过几次需要重启zk集群,我是单个zk节点逐个重启。结论是导致了flink集群中任务的全部自动重启(基于最近一次的ckpt)。这对任务还是有一定影响的,因为ckpt是10分钟一次,会导致瞬间压力变高。 > > > > > > > > > >问下这个合理嘛,还是我配置的有问题or操作有问题。 > > > > > > > > > > |
我查了一下,社区目前已经有相关的ticket和PR了,你可以关注一下
https://issues.apache.org/jira/browse/FLINK-10052 https://github.com/apache/flink/pull/11338 Best, Yang Yang Wang <[hidden email]> 于2020年12月3日周四 下午4:52写道: > 我理解Curator和ZooKeeper的各个节点(包括Leader, Followers)之间都是长连接 > 如果你重启了ZK节点的其中一个,应该会导致和这个节点连着的Curator Client都Suspend, > 进而导致相应的JobManager丢掉leader ship,所以会cancel掉当前任务然后重新运行 > > 你可以验证一下是不是重启一个ZK节点只是特定的连到这台上面的Flink任务Failover,而不是全部的 > > 最后,这个问题目前应该是没有办法通过Flink配置直接解决,除非是Curator#LeaderLatch对Suspend的状态处理可以进行改进 > 同时Flink里也需要在LeaderRetrieval中对Suspend状态的处理进行改进,不是直接notify一个empty leader > > > Best, > Yang > > 赵一旦 <[hidden email]> 于2020年12月3日周四 上午10:28写道: > >> >> 那Curator的state为什么会变成suspended或lost呢?我重启zk一般都是一台一台重启,而且我最近才刚刚又试过一次,我是先重启了follower >> zk节点,结果刚刚kill一瞬间flink任务全部出问题了。 >> >> Yang Wang <[hidden email]> 于2020年12月1日周二 下午8:18写道: >> >> > Flink是利用Curator Framework来进行Leader Election和Retrieval,当时Curator的State >> > 变成Suspended或者Lost的时候都会触发leader的revoke,进而导致需要Cancel掉之前的job >> > 等待新的leader出现再重新调度 >> > >> > 你可以提供一下JobManager的log或者自己观察一下JobManager的log是不是有Curator Connection >> State的变化 >> > 进而导致了Failover >> > >> > >> > Best, >> > Yang >> > >> > 赵一旦 <[hidden email]> 于2020年12月1日周二 下午7:13写道: >> > >> > > 又石沉大海了,有没有懂的人出来解释下。 >> > > >> > > RS <[hidden email]> 于2020年11月17日周二 上午9:35写道: >> > > >> > > > 哈哈, 我的也是, flink和ZK断开连接的话, 任务会全部重启, 这边测试了各种场景, 比如部署HA方案, >> > > > 部署多个jobmanager都测试过, 任务都是会重启的, 同样不知道如何解决. >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > 在 2020-11-16 18:39:29,"赵一旦" <[hidden email]> 写道: >> > > > >> > > > >> > > >> > >> >按照我在工作中经验,有过几次需要重启zk集群,我是单个zk节点逐个重启。结论是导致了flink集群中任务的全部自动重启(基于最近一次的ckpt)。这对任务还是有一定影响的,因为ckpt是10分钟一次,会导致瞬间压力变高。 >> > > > > >> > > > >问下这个合理嘛,还是我配置的有问题or操作有问题。 >> > > > >> > > >> > >> > |
Free forum by Nabble | Edit this page |