Page History

...

BrokerHeartbeatRequest will include the following new field:

{ "name": "LogDirsOfflinedOfflineLogDirs", "type":  "[]uuid", "versions": "1+", "taggedVersions": "1+", "tag": "0",
  "about": "Log directories that failed and went offline." }

...

When one or more log directories become offline, the broker will communicate this change using the new field LogDirsOfflined OfflineLogDirs  in the BrokerHeartbeat  request — indicating the UUIDs of the new offline log directories. The UUIDs for the newly failed log directories are included in the BrokerHeartbeat  request until the broker receives a successful responsesees them correctly identified as offline in a BrokerRegistrationChangeRecord.

Because the broker is proactive in communicating any log directory assignment changes to the controller, the metadata should be up to date and correct when the controller is notified of a failed log directory. However, the consequences of some partition assignment being incorrect – due to some error or race condition - can be quite damaging, as the controller might not know to update leadership for that partition, leaving it unavailable for an indefinite amount of time. So, as a fallback mechanism, when handling a runtime directory failure, the broker must verify the assignments for the newly failed partitions against the latest metadata, and for any incorrect assignments, the broker will use AlterReplicaLogDirs  to rectify them so that the controller can update leadership and ISR.

...

When a controller receives a BrokerHeartbeat request from a broker that indicates any UUIDs under the new LogDirsOfflined field OfflineLogDirs field, it will:

• Persist a BrokerRegistrationChange record, with the new list of online and offline log directories
• Update the Leader and ISR for all the replicas assigned to the failed log directories, persisting PartitionChangeRecords, in similar way to how leadership and ISR is updated when a broker becomes fenced, unregistered or shuts down.

...