apache · clintropolis · Apr 24, 2026 · Apr 27, 2026 · Apr 27, 2026 · Apr 27, 2026
diff --git a/docs/api-reference/tasks-api.md b/docs/api-reference/tasks-api.md
@@ -1079,7 +1079,6 @@ Host: http://ROUTER_IP:ROUTER_PORT
     2023-07-03T22:11:18,009 INFO [main] org.eclipse.jetty.server.session - node0 Stopped scavenging
     2023-07-03T22:11:18,012 INFO [main] org.eclipse.jetty.server.handler.ContextHandler - Stopped o.e.j.s.ServletContextHandler@742aa00a{/,null,STOPPED}
     2023-07-03T22:11:18,014 INFO [main] org.apache.druid.java.util.common.lifecycle.Lifecycle - Stopping lifecycle [module] stage [NORMAL]
-    2023-07-03T22:11:18,014 INFO [main] org.apache.druid.server.coordination.ZkCoordinator - Stopping ZkCoordinator for [DruidServerMetadata{name='localhost:8100', hostAndPort='localhost:8100', hostAndTlsPort='null', maxSize=0, tier='_default_tier', type=indexer-executor, priority=0}]
     2023-07-03T22:11:18,014 INFO [main] org.apache.druid.server.coordination.SegmentLoadDropHandler - Stopping...
     2023-07-03T22:11:18,014 INFO [main] org.apache.druid.server.coordination.SegmentLoadDropHandler - Stopped.
     2023-07-03T22:11:18,014 INFO [main] org.apache.druid.indexing.overlord.SingleTaskBackgroundRunner - Starting graceful shutdown of task[index_kafka_social_media_0e905aa31037879_nommnaeg].

diff --git a/docs/configuration/index.md b/docs/configuration/index.md
@@ -154,9 +154,7 @@ Druid interacts with ZooKeeper through a set of standard path configurations. We
 |Property|Description|Default|
 |--------|-----------|-------|
 |`druid.zk.paths.base`|Base ZooKeeper path.|`/druid`|
-|`druid.zk.paths.propertiesPath`|ZooKeeper properties path.|`${druid.zk.paths.base}/properties`|
 |`druid.zk.paths.announcementsPath`|Druid service announcement path.|`${druid.zk.paths.base}/announcements`|
-|`druid.zk.paths.liveSegmentsPath`|Current path for where Druid services announce their segments.|`${druid.zk.paths.base}/segments`|
 |`druid.zk.paths.coordinatorPath`|Used by the Coordinator for leader election.|`${druid.zk.paths.base}/coordinator`|
 
 The indexing service also uses its own set of paths. These configs can be included in the common configuration.
@@ -648,27 +646,6 @@ This config is used to find the [Coordinator](../design/coordinator.md) using Cu
 |--------|-----------|-------|
 |`druid.selectors.coordinator.serviceName`|The druid.service name of the Coordinator service. To start the Coordinator with a different name, set it with this property. |druid/coordinator|
 
-### Announcing segments
-
-You can configure how to announce and unannounce Znodes in ZooKeeper (using Curator). For normal operations you do not need to override any of these configs.
-
-#### Batch data segment announcer
-
-In current Druid, multiple data segments may be announced under the same Znode.
-
-|Property|Description|Default|
-|--------|-----------|-------|
-|`druid.announcer.segmentsPerNode`|Each Znode contains info for up to this many segments.|50|
-|`druid.announcer.maxBytesPerNode`|Max byte size for Znode. Allowed range is [1024, 1048576].|524288|
-|`druid.announcer.skipDimensionsAndMetrics`|Skip Dimensions and Metrics list from segment announcements. NOTE: Enabling this will also remove the dimensions and metrics list from Coordinator and Broker endpoints.|false|
-|`druid.announcer.skipLoadSpec`|Skip segment LoadSpec from segment announcements. NOTE: Enabling this will also remove the loadspec from Coordinator and Broker endpoints.|false|
-
-If you want to turn off the batch data segment announcer, you can add a property to skip announcing segments. **You do not want to enable this config if you have any services using `batch` for `druid.serverview.type`**
-
-|Property|Description|Default|
-|--------|-----------|-------|
-|`druid.announcer.skipSegmentAnnouncementOnZk`|Skip announcing segments to ZooKeeper. Note that the batch server view will not work if this is set to true.|false|
-
 ### JavaScript
 
 Druid supports dynamic runtime extension through JavaScript functions. This functionality can be configured through
@@ -796,7 +773,6 @@ These Coordinator static configurations can be defined in the `coordinator/runti
 
 |Property|Possible values|Description|Default|
 |--------|---------------|-----------|-------|
-|`druid.serverview.type`|batch or http|Segment discovery method to use. "http" enables discovering segments using HTTP instead of ZooKeeper.|http|
 |`druid.coordinator.segment.awaitInitializationOnStart`|true or false|Whether the Coordinator will wait for its view of segments to fully initialize before starting up. If set to 'true', the Coordinator's HTTP server will not start up, and the Coordinator will not announce itself as available, until the server view is initialized.|true|
 
 ##### Metadata retrieval
@@ -1931,7 +1907,6 @@ See [cache configuration](#cache-configuration) for how to configure cache setti
 
 |Property|Possible Values|Description|Default|
 |--------|---------------|-----------|-------|
-|`druid.serverview.type`|batch or http|Segment discovery method to use. "http" enables discovering segments using HTTP instead of ZooKeeper.|http|
 |`druid.broker.segment.watchedTiers`|List of strings|The Broker watches segment announcements from processes that serve segments to build a cache to relate each process to the segments it serves. This configuration allows the Broker to only consider segments being served from a list of tiers. By default, Broker considers all tiers. This can be used to partition your dataSources in specific Historical tiers and configure brokers in partitions so that they are only queryable for specific dataSources. This config is mutually exclusive from `druid.broker.segment.ignoredTiers` and at most one of these can be configured on a Broker.|none|
 |`druid.broker.segment.ignoredTiers`|List of strings|The Broker watches segment announcements from processes that serve segments to build a cache to relate each process to the segments it serves. This configuration allows the Broker to ignore the segments being served from a list of tiers. By default, Broker considers all tiers. This config is mutually exclusive from `druid.broker.segment.watchedTiers` and at most one of these can be configured on a Broker.|none|
 |`druid.broker.segment.watchedDataSources`|List of strings|Broker watches the segment announcements from processes serving segments to build cache of which process is serving which segments, this configuration allows to only consider segments being served from a whitelist of dataSources. By default, Broker would consider all datasources. This can be used to configure brokers in partitions so that they are only queryable for specific dataSources.|none|

diff --git a/docs/configuration/logging.md b/docs/configuration/logging.md
@@ -133,38 +133,3 @@ Java runtime itself.
 This file is not rotated, but it is generally small due to the low volume of messages.
 If necessary, you can truncate it using the Linux command `truncate --size 0 log/historical.stdout.log`.
 
-## Set the logs to asynchronously write
-
-If your logs are really chatty, you can set them to write asynchronously.
-The following example shows a `log4j2.xml` that configures some of the more chatty classes to write asynchronously:
-
-```
-<?xml version="1.0" encoding="UTF-8" ?>
-<Configuration status="WARN">
-  <Appenders>
-    <Console name="Console" target="SYSTEM_OUT">
-      <PatternLayout pattern="%d{ISO8601} %p [%t] %c -%notEmpty{ [%markerSimpleName]} %m%n"/>
-    </Console>
-  </Appenders>
-
-<Loggers>
-    <!-- AsyncLogger instead of Logger -->
-    <AsyncLogger name="org.apache.druid.curator.inventory.CuratorInventoryManager" level="debug" additivity="false">
-      <AppenderRef ref="Console"/>
-    </AsyncLogger>
-    <AsyncLogger name="org.apache.druid.client.BatchServerInventoryView" level="debug" additivity="false">
-      <AppenderRef ref="Console"/>
-    </AsyncLogger>
-    <!-- Make extra sure nobody adds logs in a bad way that can hurt performance -->
-    <AsyncLogger name="org.apache.druid.client.ServerInventoryView" level="debug" additivity="false">
-      <AppenderRef ref="Console"/>
-    </AsyncLogger>
-    <AsyncLogger name ="org.apache.druid.java.util.http.client.pool.ChannelResourceFactory" level="info" additivity="false">
-      <AppenderRef ref="Console"/>
-    </AsyncLogger>
-    <Root level="info">
-      <AppenderRef ref="Console"/>
-    </Root>
-  </Loggers>
-</Configuration>
-```
diff --git a/docs/design/broker.md b/docs/design/broker.md
@@ -24,7 +24,7 @@ sidebar_label: "Broker"
   -->
 
 
-The Broker service routes queries in a distributed cluster setup. It interprets the metadata published to ZooKeeper about segment distribution across services and routes queries accordingly. Additionally, the Broker service consolidates result sets from individual services.
+The Broker service routes queries in a distributed cluster setup. It discovers data-serving services via ZooKeeper, polls each one over HTTP for the segments it is serving, and routes queries accordingly. Additionally, the Broker service consolidates result sets from individual services.
 
 ## Configuration
 
@@ -46,7 +46,7 @@ org.apache.druid.cli.Main server broker
 
 Most Druid queries contain an interval object that indicates a span of time for which data is requested. Similarly, Druid partitions [segments](../design/segments.md) to contain data for some interval of time and distributes the segments across a cluster. Consider a simple datasource with seven segments where each segment contains data for a given day of the week. Any query issued to the datasource for more than one day of data will hit more than one segment. These segments will likely be distributed across multiple services, and hence, the query will likely hit multiple services.
 
-To determine which services to forward queries to, the Broker service first builds a view of the world from information in ZooKeeper. ZooKeeper maintains information about [Historical](../design/historical.md) and streaming ingestion [Peon](../design/peons.md) services and the segments they are serving. For every datasource in ZooKeeper, the Broker service builds a timeline of segments and the services that serve them. When queries are received for a specific datasource and interval, the Broker service performs a lookup into the timeline associated with the query datasource for the query interval and retrieves the services that contain data for the query. The Broker service then forwards down the query to the selected services.
+To determine which services to forward queries to, the Broker service first builds a view of the world from the cluster. It uses ZooKeeper to discover [Historical](../design/historical.md) and streaming ingestion [Peon](../design/peons.md) services, then polls each one over HTTP to learn the segments it is serving. For every datasource, the Broker service builds a timeline of segments and the services that serve them. When queries are received for a specific datasource and interval, the Broker service performs a lookup into the timeline associated with the query datasource for the query interval and retrieves the services that contain data for the query. The Broker service then forwards the query to the selected services.
 
 ## Caching
 

diff --git a/docs/design/coordinator.md b/docs/design/coordinator.md
@@ -30,16 +30,16 @@ Coordinator service communicates to Historical services to load or drop segments
 
 The Coordinator runs its duties periodically and the time between each run is a configurable parameter. On each
 run, the Coordinator assesses the current state of the cluster before deciding on the appropriate actions to take.
-Similar to the Broker and Historical services, the Coordinator maintains a connection to a ZooKeeper cluster for
-current cluster information. The Coordinator also maintains a connection to a database containing information about
-"used" segments (that is, the segments that *should* be loaded in the cluster) and the loading rules.
+The Coordinator uses ZooKeeper for leader election and to discover other Druid services, and polls each Historical
+service over HTTP for the current set of segments it is serving. The Coordinator also maintains a connection to a
+database containing information about "used" segments (that is, the segments that *should* be loaded in the cluster)
+and the loading rules.
 
 Before any unassigned segments are serviced by Historical services, the Historical services for each tier are first
 sorted in terms of capacity, with least capacity servers having the highest priority. Unassigned segments are always
-assigned to the services with least capacity to maintain a level of balance between services. The Coordinator does not
-directly communicate with a Historical service when assigning it a new segment; instead the Coordinator creates some
-temporary information about the new segment under load queue path of the Historical service. Once this request is seen,
-the Historical service loads the segment and begins servicing it.
+assigned to the services with least capacity to maintain a level of balance between services. The Coordinator sends
+segment load and drop requests to each Historical service over HTTP. Once this request is received, the Historical
+service loads the segment and begins servicing it.
 
 ## Configuration
 

diff --git a/docs/design/historical.md b/docs/design/historical.md
@@ -47,13 +47,13 @@ org.apache.druid.cli.Main server historical
 Each Historical service copies or pulls segment files from deep storage to local disk in an area called the segment cache. To configure the size and location of the segment cache on each Historical service, set the `druid.segmentCache.locations`.
 For more information, see [Segment cache size](../operations/basic-cluster-tuning.md#segment-cache-size).
 
-The [Coordinator](../design/coordinator.md) controls the assignment of segments to Historicals and the balance of segments between Historicals. Historical services do not communicate directly with each other, nor do they communicate directly with the Coordinator. Instead, the Coordinator creates ephemeral entries in ZooKeeper in a [load queue path](../configuration/index.md#path-configuration). Each Historical service maintains a connection to ZooKeeper, watching those paths for segment information.
+The [Coordinator](../design/coordinator.md) controls the assignment of segments to Historicals and the balance of segments between Historicals. Historical services do not communicate directly with each other. The Coordinator sends segment load and drop requests to each Historical over HTTP, and each Historical exposes an HTTP endpoint for the Coordinator to poll for the current state of its segment assignments.
 
-When a Historical service detects a new entry in the ZooKeeper load queue, it checks its own segment cache. If no information about the segment exists there, the Historical service first retrieves metadata from ZooKeeper about the segment, including where the segment is located in deep storage and how it needs to decompress and process it.
+When a Historical service receives a load request, it checks its own segment cache. If no information about the segment exists there, the Historical uses the segment metadata included in the request — including where the segment is located in deep storage and how to decompress and process it — to pull the segment from deep storage.
 
 For more information about segment metadata and Druid segments in general, see [Segments](../design/segments.md).
 
-After a Historical service pulls down and processes a segment from deep storage, Druid advertises the segment as being available for queries from the Broker. This announcement by the Historical is made via ZooKeeper, in a [served segments path](../configuration/index.md#path-configuration).
+After a Historical service pulls down and processes a segment from deep storage, Druid advertises the segment as being available for queries from the Broker. The Historical exposes its current set of served segments via an HTTP endpoint (`/druid-internal/v1/segments`), which the Broker polls to learn what data each Historical is serving.
 
 For more information about how the Broker determines what data is available for queries, see [Broker](broker.md).
 

diff --git a/docs/design/zookeeper.md b/docs/design/zookeeper.md
@@ -29,43 +29,45 @@ Apache Druid uses [Apache ZooKeeper](http://zookeeper.apache.org/) (ZK) for mana
 
 Apache Druid supports all stable versions of ZooKeeper. For information about ZooKeeper's stable version, see [ZooKeeper releases](https://zookeeper.apache.org/releases.html).
 
-## ZooKeeper Operations
+## ZooKeeper operations
 
-The operations that happen over ZK are
+The operations that happen over ZK are:
 
-1.  [Coordinator](../design/coordinator.md) leader election
-2.  Segment "publishing" protocol from [Historical](../design/historical.md)
-3.  [Overlord](../design/overlord.md) leader election
-4.  [Overlord](../design/overlord.md) and [Middle Manager](../design/middlemanager.md) task management
+1. [Coordinator](../design/coordinator.md) leader election
+2. [Overlord](../design/overlord.md) leader election
+3. Service (node) announcement and discovery — services announce their presence so other services can find them
+4. [Overlord](../design/overlord.md) and [Middle Manager](../design/middlemanager.md) task management
 
-## Coordinator Leader Election
+Segment loading, dropping, and discovery no longer use ZooKeeper — they are served over HTTP.
 
-We use the Curator [LeaderLatch](https://curator.apache.org/docs/recipes-leader-latch) recipe to perform leader election at path
+## Coordinator leader election
+
+Druid uses the Curator [LeaderLatch](https://curator.apache.org/docs/recipes-leader-latch) recipe to perform leader election at path
 
 ```
 ${druid.zk.paths.coordinatorPath}/_COORDINATOR
 ```
 
-## Segment "publishing" protocol from Historical and Realtime
-
-The `announcementsPath` and `liveSegmentsPath` are used for this.
+## Overlord leader election
 
-All [Historical](../design/historical.md) processes publish themselves on the `announcementsPath`, specifically, they will create an ephemeral znode at
+Druid uses the same [LeaderLatch](https://curator.apache.org/docs/recipes-leader-latch) recipe for Overlord leader election at path
 
 ```
-${druid.zk.paths.announcementsPath}/${druid.host}
+${druid.zk.paths.overlordPath}/_OVERLORD
 ```
 
-Which signifies that they exist. They will also subsequently create a permanent znode at
+## Service announcement and discovery
+
+All Druid services publish their presence by creating an ephemeral znode at
 
 ```
-${druid.zk.paths.liveSegmentsPath}/${druid.host}
+${druid.zk.paths.announcementsPath}/${druid.host}
 ```
 
-And as they load up segments, they will attach ephemeral znodes that look like
+In addition, each service announces a richer `DruidNode` record (host, port, role, services) under the internal-discovery path, so that other services can enumerate cluster members by role:
 
 ```
-${druid.zk.paths.liveSegmentsPath}/${druid.host}/_segment_identifier_
+${druid.zk.paths.base}/internal-discovery/${nodeRole}/${druid.host}
 ```
 
-Processes like the [Coordinator](../design/coordinator.md) and [Broker](../design/broker.md) can then watch these paths to see which processes are currently serving which segments.
+Brokers and Coordinators use this internal-discovery path to find Historicals, Peons, and Indexers. They then poll each discovered service's HTTP `/druid-internal/v1/segments` endpoint to get its current set of served segments.