This is an automated email from the ASF dual-hosted git repository.
cmccabe pushed a commit to branch 3.9
in repository https://gitbox.apache.org/repos/asf/kafka.git
The following commit(s) were added to refs/heads/3.9 by this push:
new 6cec93a2411 KAFKA-18070: Update kafka-metadata-quorum.sh output in
docs to match KIP-853 (#17921)
6cec93a2411 is described below
commit 6cec93a2411aee6b01b2b8343d1c48f148f4bb33
Author: Kuan-Po Tseng <[email protected]>
AuthorDate: Mon Dec 2 19:58:00 2024 +0800
KAFKA-18070: Update kafka-metadata-quorum.sh output in docs to match
KIP-853 (#17921)
Reviewers: Ziming Deng <[email protected]>.
---
docs/ops.html | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/docs/ops.html b/docs/ops.html
index 29ed483db12..9c7d2bc9e27 100644
--- a/docs/ops.html
+++ b/docs/ops.html
@@ -1367,8 +1367,9 @@ queued.max.requests=[number of concurrent
requests]</code></pre>
<p>If the data in the cluster metadata directory is lost either because of
hardware failure or the hardware needs to be replaced, care should be taken
when provisioning the new controller node. The new controller node should not
be formatted and started until the majority of the controllers have all of the
committed data. To determine if the majority of the controllers have the
committed data, run the <code>kafka-metadata-quorum.sh</code> tool to describe
the replication status:</p>
<pre><code class="language-bash">$ bin/kafka-metadata-quorum.sh
--bootstrap-server localhost:9092 describe --replication
-NodeId LogEndOffset Lag LastFetchTimestamp LastCaughtUpTimestamp
Status
-1 25806 0 1662500992757 1662500992757
Leader
+NodeId DirectoryId LogEndOffset Lag LastFetchTimestamp
LastCaughtUpTimestamp Status
+1 dDo1k_pRSD-VmReEpu383g 966 0 1732367153528
1732367153528 Leader
+2 wQWaQMJYpcifUPMBGeRHqg 966 0 1732367153304
1732367153304 Observer
... ... ... ... ...
...</code></pre>
<p>Check and wait until the <code>Lag</code> is small for a majority of the
controllers. If the leader's end offset is not increasing, you can wait until
the lag is 0 for a majority; otherwise, you can pick the latest leader end
offset and wait until all replicas have reached it. Check and wait until the
<code>LastFetchTimestamp</code> and <code>LastCaughtUpTimestamp</code> are
close to each other for the majority of the controllers. At this point it is
safer to format the controller's [...]
