[GitHub] [kafka] jsancio commented on a diff in pull request #12597: KAFKA-14205; Document how to replace the disk for the KRaft Controller

[GitBox <gi...@apache.org>]

jsancio commented on code in PR #12597:
URL: https://github.com/apache/kafka/pull/12597#discussion_r967490851


##########
docs/ops.html:
##########
@@ -1373,6 +1373,27 @@ <h5 class="anchor-heading"><a id="ext4" class="anchor-link"></a><a href="#ext4">
     <li>delalloc: Delayed allocation means that the filesystem avoid allocating any blocks until the physical write occurs. This allows ext4 to allocate a large extent instead of smaller pages and helps ensure the data is written sequentially. This feature is great for throughput. It does seem to involve some locking in the filesystem which adds a bit of latency variance.
   </ul>
 
+  <h4 class="anchor-heading"><a id="replace_disk" class="anchor-link"></a><a href="#replaced_disk">Replace KRaft Controller Disk</a></h4>
+  <p>When Kafka is configured to use KRaft instead of ZooKeeper, the controllers stores the cluster metadata in the directory specified in <code>metadata.log.dir</code>, <code>log.dir</code> or <code>log.dirs</code>. See the documentation for <code>metadata.log.dir</code> for details.</p>

Review Comment:
   Done. Thanks for the suggestion.



##########
docs/ops.html:
##########
@@ -1373,6 +1373,27 @@ <h5 class="anchor-heading"><a id="ext4" class="anchor-link"></a><a href="#ext4">
     <li>delalloc: Delayed allocation means that the filesystem avoid allocating any blocks until the physical write occurs. This allows ext4 to allocate a large extent instead of smaller pages and helps ensure the data is written sequentially. This feature is great for throughput. It does seem to involve some locking in the filesystem which adds a bit of latency variance.
   </ul>
 
+  <h4 class="anchor-heading"><a id="replace_disk" class="anchor-link"></a><a href="#replaced_disk">Replace KRaft Controller Disk</a></h4>
+  <p>When Kafka is configured to use KRaft instead of ZooKeeper, the controllers stores the cluster metadata in the directory specified in <code>metadata.log.dir</code>, <code>log.dir</code> or <code>log.dirs</code>. See the documentation for <code>metadata.log.dir</code> for details.</p>
+
+  <p>If the data in the cluster metdata directory (disk) is lost either because of hardware failure or the hardware needs to be replace, 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:

Review Comment:
   Done.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org