kafka节点故障恢复原理

Kafka的LEO和HW

LEO

LEO是Topic每一个副本的最后的偏移量offset+1

HW(高水位线)

High WaterMark是所有副本中,最小的LEO

Follower副本所在节点宕机

由于数据同步的时候数据是先写入Leader,然后Follower副本向Leader同步
只要Leader和其他的Follower副本继续往前存储数据,挂掉的节点在replica.lag.time.max.ms之内没有追上,就会掉出ISR从ISR集合中剔除,如果此时挂掉的Follower又重启了,他会从上次挂掉的时候的HW开始向Follower同步数据,直到追上最新的数据,就会重新回到ISR集合

注:replica.lag.time.max.ms的真正含义不是Follower副本在replica.lag.time.max.ms向Leader拉取过数据,而是在replica.lag.time.max.ms内已经追上过Leader的数据了,比较的数据是副本管理器(ReplicaManager)对于已经追上过Leader副本的Follower副本打上的lastCaughtUpTimeMs标识,会计算当前时间和lastCaughtUpTimeMs的差值

Leader副本所在节点宕机

(1)情况1:Leader副本宕机时存在同步的Follower副本

如果存在同步Follower副本,此时就保障了在故障时的数据完整性,会被Controller选举为新的Leader副本(如果是多个完全同步的Follower副本,需看谁在ISR集合里靠前),为保证多个副本之间的数据一致性,其余Follower副本会将各自log文件中高于HW的部分截掉,然后从新的Leader副本同步数据;此时宕机的Leader副本重启后会从宕机前的HW开始向新的Leader副本拉取同步数据,直到追上最新的数据,就会回到ISR集合中

(2)情况2:Leader副本宕机时不存在同步的Follower副本

如果不存在同步的Follower副本,此时由Broker的配置来决定unclean.leader.election.enable
unclean.leader.election.enable参数如果设置为false,就是指Leader副本所在的节点宕机时ISR集合里为空,不允许进行Leader副本的副本,如果设置为true表示不存在完整的Follower副本也可以参与Leader副本的选举,这时候会选举出一个新的Leader副本,为保证多个副本之间的数据一致性,其余Follower副本会将各自log文件中高于HW的部分截掉,然后从新的Leader副本同步数据;

注意:这种情况一定会导致数据的丢失,为了保障数据的可靠性和一致性,可以考虑ACK应答机制
相关参数为offsets.commit.required.acks,设置为-1,这是最可靠的模式,则表示在Leader副本和Follower副本都确认成功写入消息后,生产者才会收到确认,缺点是会导致更长的延迟

posted @ 2024-02-29 15:18  付同學  阅读(61)  评论(0编辑  收藏  举报