You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by yidan zhao <hi...@gmail.com> on 2022/03/11 03:50:47 UTC
Flink1.13 standalone基于zk进行HA，经常出现重启后无限leader选举的情况
如题，大家知道为啥吗。
一般如果集群没任务。重启问题出现概率低。
但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。
Re: Flink1.13 standalone基于zk进行HA，经常出现重启后无限leader选举的情况
Posted by yidan zhao <hi...@gmail.com>.
这个问题今天再另外一个场景遇到了，经过仔细对比日志，观察ZK节点信息，目前定位到问题。
因为这个问题历史遇到太多次，不好说是否都是这个原因，但起码有一大部分是这个原因。
这个主要是因为部分场景可能人工重启了JM进程，不是基于 bin/start-cluster.sh 脚本启，而是基于
./bin/jobmanager.sh start 这样启动的。
假设有5个机器，JM1、JM2、JM3，TM1-TM5，前3跑JM，5台都跑TM。
JM123之间选举，但是JM123上报到zk的信息存在localhost，导致集群无法正常启动。
如果碰巧没问题的JM（未手动重启）成为leader还好说，集群就正常了。但如果JM1和JM3被手动重启，zk中出现了localhost。
则所有TM都向本地注册。导致出现3个集群，JM1一个，JM2一个，JM3一个，并且都是具有1个Tm，机器4和5则因为连接不到JM导致tm会失败。
所以解决方法，要么别手动启动，或者启动方式为：./bin/jobmanager.sh start host
ip，此处host一定要加，ip可不加。如果host不加就会用localhost。
胡伟华 <hu...@gmail.com> 于2022年3月16日周三 22:02写道：
> Hi, yidan
>
> 建议排查下 Leader 频繁选举时 JobManager 是否存在频繁 GC 的情况。
> 如果不是还可以通过 jobmanager.log 查看是否存在其他异常。
>
>
> > 2022年3月11日 下午4:34，yidan zhao <hi...@gmail.com> 写道：
> >
> > 我指的选举主要是flink的选举，就是访问web ui后，显示正处于选举过程中。然后我一直等，一直处于选举过程中。
> >
> > Biao Geng <bi...@gmail.com> 于2022年3月11日周五 13:00写道：
> >
> >> Hi yidian，
> >>
> >>
> 如果我没理解错的话，你提到集群没有flink作业时，zk也会有较低概率发生leader选举（你说的“重启”应该是指leader选举？）。这本身就是可能有问题的。你可以先去看看zk的日志判断一下zk重启的原因。
> >>
> >> Best，
> >> Biao
> >>
> >> yidan zhao <hi...@gmail.com>于2022年3月11日 周五12:17写道：
> >>
> >>> 我zk主要就flink和kafka用，还有kafka-manager，应该用的不是不多。至少zk的磁盘IO很低。
> >>> 除非说是zk所在机器本身压力高勉强可能，但是zk本身压力不会高。
> >>>
> >>>
> >>> Biao Geng <bi...@gmail.com> 于2022年3月11日周五 12:06写道：
> >>>
> >>>> Hi yidian,
> >>>>
> >>>> 你说的应该是ZK
> >>>>
> >>>>
> >>>
> >>
> leader频繁选举？你可以看下ZK的日志，看看有没有更具体的原因。一般是因为ZK存储用量过大(znode数目过多)，导致ZK的leader和follower数据同步失败，触发选举。
> >>>> Flink HA任务数目不多的话，一般在ZK侧压力不大。你可以看看有没有其他应用也使用了ZK服务。
> >>>>
> >>>> Best,
> >>>> Biao
> >>>>
> >>>> yidan zhao <hi...@gmail.com>于2022年3月11日 周五11:51写道：
> >>>>
> >>>>> 如题，大家知道为啥吗。
> >>>>> 一般如果集群没任务。重启问题出现概率低。
> >>>>> 但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。
> >>>>>
> >>>>
> >>>
> >>
>
>
Re: Flink1.13 standalone基于zk进行HA，经常出现重启后无限leader选举的情况
Posted by 胡伟华 <hu...@gmail.com>.
Hi, yidan
建议排查下 Leader 频繁选举时 JobManager 是否存在频繁 GC 的情况。
如果不是还可以通过 jobmanager.log 查看是否存在其他异常。
> 2022年3月11日 下午4:34，yidan zhao <hi...@gmail.com> 写道：
>
> 我指的选举主要是flink的选举，就是访问web ui后，显示正处于选举过程中。然后我一直等，一直处于选举过程中。
>
> Biao Geng <bi...@gmail.com> 于2022年3月11日周五 13:00写道：
>
>> Hi yidian，
>>
>> 如果我没理解错的话，你提到集群没有flink作业时，zk也会有较低概率发生leader选举（你说的“重启”应该是指leader选举？）。这本身就是可能有问题的。你可以先去看看zk的日志判断一下zk重启的原因。
>>
>> Best，
>> Biao
>>
>> yidan zhao <hi...@gmail.com>于2022年3月11日 周五12:17写道：
>>
>>> 我zk主要就flink和kafka用，还有kafka-manager，应该用的不是不多。至少zk的磁盘IO很低。
>>> 除非说是zk所在机器本身压力高勉强可能，但是zk本身压力不会高。
>>>
>>>
>>> Biao Geng <bi...@gmail.com> 于2022年3月11日周五 12:06写道：
>>>
>>>> Hi yidian,
>>>>
>>>> 你说的应该是ZK
>>>>
>>>>
>>>
>> leader频繁选举？你可以看下ZK的日志，看看有没有更具体的原因。一般是因为ZK存储用量过大(znode数目过多)，导致ZK的leader和follower数据同步失败，触发选举。
>>>> Flink HA任务数目不多的话，一般在ZK侧压力不大。你可以看看有没有其他应用也使用了ZK服务。
>>>>
>>>> Best,
>>>> Biao
>>>>
>>>> yidan zhao <hi...@gmail.com>于2022年3月11日 周五11:51写道：
>>>>
>>>>> 如题，大家知道为啥吗。
>>>>> 一般如果集群没任务。重启问题出现概率低。
>>>>> 但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。
>>>>>
>>>>
>>>
>>
Re: Flink1.13 standalone基于zk进行HA，经常出现重启后无限leader选举的情况
Posted by yidan zhao <hi...@gmail.com>.
我指的选举主要是flink的选举，就是访问web ui后，显示正处于选举过程中。然后我一直等，一直处于选举过程中。
Biao Geng <bi...@gmail.com> 于2022年3月11日周五 13:00写道：
> Hi yidian，
>
> 如果我没理解错的话，你提到集群没有flink作业时，zk也会有较低概率发生leader选举（你说的“重启”应该是指leader选举？）。这本身就是可能有问题的。你可以先去看看zk的日志判断一下zk重启的原因。
>
> Best，
> Biao
>
> yidan zhao <hi...@gmail.com>于2022年3月11日 周五12:17写道：
>
> > 我zk主要就flink和kafka用，还有kafka-manager，应该用的不是不多。至少zk的磁盘IO很低。
> > 除非说是zk所在机器本身压力高勉强可能，但是zk本身压力不会高。
> >
> >
> > Biao Geng <bi...@gmail.com> 于2022年3月11日周五 12:06写道：
> >
> > > Hi yidian,
> > >
> > > 你说的应该是ZK
> > >
> > >
> >
> leader频繁选举？你可以看下ZK的日志，看看有没有更具体的原因。一般是因为ZK存储用量过大(znode数目过多)，导致ZK的leader和follower数据同步失败，触发选举。
> > > Flink HA任务数目不多的话，一般在ZK侧压力不大。你可以看看有没有其他应用也使用了ZK服务。
> > >
> > > Best,
> > > Biao
> > >
> > > yidan zhao <hi...@gmail.com>于2022年3月11日 周五11:51写道：
> > >
> > > > 如题，大家知道为啥吗。
> > > > 一般如果集群没任务。重启问题出现概率低。
> > > > 但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。
> > > >
> > >
> >
>
Re: Flink1.13 standalone基于zk进行HA，经常出现重启后无限leader选举的情况
Posted by Biao Geng <bi...@gmail.com>.
Hi yidian，
如果我没理解错的话，你提到集群没有flink作业时，zk也会有较低概率发生leader选举（你说的“重启”应该是指leader选举？）。这本身就是可能有问题的。你可以先去看看zk的日志判断一下zk重启的原因。
Best，
Biao
yidan zhao <hi...@gmail.com>于2022年3月11日 周五12:17写道：
> 我zk主要就flink和kafka用，还有kafka-manager，应该用的不是不多。至少zk的磁盘IO很低。
> 除非说是zk所在机器本身压力高勉强可能，但是zk本身压力不会高。
>
>
> Biao Geng <bi...@gmail.com> 于2022年3月11日周五 12:06写道：
>
> > Hi yidian,
> >
> > 你说的应该是ZK
> >
> >
> leader频繁选举？你可以看下ZK的日志，看看有没有更具体的原因。一般是因为ZK存储用量过大(znode数目过多)，导致ZK的leader和follower数据同步失败，触发选举。
> > Flink HA任务数目不多的话，一般在ZK侧压力不大。你可以看看有没有其他应用也使用了ZK服务。
> >
> > Best,
> > Biao
> >
> > yidan zhao <hi...@gmail.com>于2022年3月11日 周五11:51写道：
> >
> > > 如题，大家知道为啥吗。
> > > 一般如果集群没任务。重启问题出现概率低。
> > > 但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。
> > >
> >
>
Re: Flink1.13 standalone基于zk进行HA，经常出现重启后无限leader选举的情况
Posted by yidan zhao <hi...@gmail.com>.
我zk主要就flink和kafka用，还有kafka-manager，应该用的不是不多。至少zk的磁盘IO很低。
除非说是zk所在机器本身压力高勉强可能，但是zk本身压力不会高。
Biao Geng <bi...@gmail.com> 于2022年3月11日周五 12:06写道：
> Hi yidian,
>
> 你说的应该是ZK
>
> leader频繁选举？你可以看下ZK的日志，看看有没有更具体的原因。一般是因为ZK存储用量过大(znode数目过多)，导致ZK的leader和follower数据同步失败，触发选举。
> Flink HA任务数目不多的话，一般在ZK侧压力不大。你可以看看有没有其他应用也使用了ZK服务。
>
> Best,
> Biao
>
> yidan zhao <hi...@gmail.com>于2022年3月11日 周五11:51写道：
>
> > 如题，大家知道为啥吗。
> > 一般如果集群没任务。重启问题出现概率低。
> > 但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。
> >
>
Re: Flink1.13 standalone基于zk进行HA，经常出现重启后无限leader选举的情况
Posted by Biao Geng <bi...@gmail.com>.
Hi yidian,
你说的应该是ZK
leader频繁选举？你可以看下ZK的日志，看看有没有更具体的原因。一般是因为ZK存储用量过大(znode数目过多)，导致ZK的leader和follower数据同步失败，触发选举。
Flink HA任务数目不多的话，一般在ZK侧压力不大。你可以看看有没有其他应用也使用了ZK服务。
Best,
Biao
yidan zhao <hi...@gmail.com>于2022年3月11日 周五11:51写道：
> 如题，大家知道为啥吗。
> 一般如果集群没任务。重启问题出现概率低。
> 但如果集群本身任务多，重启后有任务恢复，很容易出现无限重启。
>