You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 1, 2024. It is now read-only.
After all the work done for PIP-45 that was already included in 2.8 and 2.9
releases, it enabled the concept of re-acquirable resource locks and leader
election.
Another important change was to avoid doing any deferrable metadata operation
when we know that we are not currently connected to the metadata service.
Finally, that enabled to stabilize in 2.9 the configuration setting that allows
brokers to continue operating in a safe mode when the session with ZooKeeper
is expired.
The way it works is that, when we lose a ZooKeeper session, the data plane will
continue to work undisturbed, relying the BookKeeper fencing to avoid any
inconsistencies.
New topics are not be able to get started, but existing topics will see no
impact.
The original intention for shutting down the brokers was to ensure that we
would automatically go back to a consistent state, with respect to which
resources are "owned" in ZooKeeper by a given broker.
With the re-acquirable resource locks, that problem was solved and thoroughly
tested to be robust.
Proposed changes
In 2.10 release, for the setting:
# There are two policies to apply when broker metadata session expires: session expired happens, "shutdown" or "reconnect".# With "shutdown", the broker will be restarted.# With "reconnect", the broker will keep serving the topics, while attempting to recreate a new session.zookeeperSessionExpiredPolicy=shutdown
Change its default value to reconnect.
The text was updated successfully, but these errors were encountered:
Original Issue: apache#13304
Motivation
After all the work done for PIP-45 that was already included in 2.8 and 2.9
releases, it enabled the concept of re-acquirable resource locks and leader
election.
Another important change was to avoid doing any deferrable metadata operation
when we know that we are not currently connected to the metadata service.
Finally, that enabled to stabilize in 2.9 the configuration setting that allows
brokers to continue operating in a safe mode when the session with ZooKeeper
is expired.
The way it works is that, when we lose a ZooKeeper session, the data plane will
continue to work undisturbed, relying the BookKeeper fencing to avoid any
inconsistencies.
New topics are not be able to get started, but existing topics will see no
impact.
The original intention for shutting down the brokers was to ensure that we
would automatically go back to a consistent state, with respect to which
resources are "owned" in ZooKeeper by a given broker.
With the re-acquirable resource locks, that problem was solved and thoroughly
tested to be robust.
Proposed changes
In 2.10 release, for the setting:
Change its default value to
reconnect
.The text was updated successfully, but these errors were encountered: