diff --git a/docs/ops.html b/docs/ops.html index ecfd294291dc4..e283cbc456f57 100644 --- a/docs/ops.html +++ b/docs/ops.html @@ -596,9 +596,9 @@

MirrorMakerConfig, MirrorConnectorConfig -
  • DefaultTopicFilter for topics, DefaultGroupFilter for consumer groups
    • -
  • Example configuration settings in connect-mirror-maker.properties, KIP-382: MirrorMaker 2.0
    • +
  • MirrorMakerConfig, MirrorConnectorConfig
    • +
  • DefaultTopicFilter for topics, DefaultGroupFilter for consumer groups
    • +
  • Example configuration settings in connect-mirror-maker.properties, KIP-382: MirrorMaker 2.0

    • Configuration File Syntax
    @@ -681,28 +681,28 @@
    us-east.exactly.once.source.support = enabled - +

    For existing MirrorMaker clusters, a two-step upgrade is necessary. Instead of immediately setting the exactly.once.source.support property to enabled, first set it to preparing on all nodes in the cluster. Once this is complete, it can be set to enabled on all nodes in the cluster, in a second round of restarts.

    - +

    In either case, it is also necessary to enable intra-cluster communication between the MirrorMaker nodes, as described in KIP-710. To do this, the dedicated.mode.enable.internal.rest property must be set to true. In addition, many of the REST-related configuration properties available for Kafka Connect can be specified the MirrorMaker config. For example, to enable intra-cluster communication in MirrorMaker cluster with each node listening on port 8080 of their local machine, the following should be added to the MirrorMaker config file: 

    dedicated.mode.enable.internal.rest = true
 listeners = http://localhost:8080
    - +

    Note that, if intra-cluster communication is enabled in production environments, it is highly recommended to secure the REST servers brought up by each MirrorMaker node. See the configuration properties for Kafka Connect for information on how this can be accomplished.

    - +

    It is also recommended to filter records from aborted transactions out from replicated data when running MirrorMaker. To do this, ensure that the consumer used to read from source clusters is configured with isolation.level set to read_committed. If replicating data from cluster us-west, this can be done for all replication flows that read from that cluster by adding the following to the MirrorMaker config file:

    @@ -1934,12 +1934,12 @@

    RemoteLogManager Avg Broker Fetch Throttle Time The average time in millis remote fetches was throttled by a broker - kafka.server:type=RemoteLogManager, name=remote-fetch-throttle-time-avg + kafka.server:type=RemoteLogManager, name=remote-fetch-throttle-time-avg RemoteLogManager Max Broker Fetch Throttle Time The max time in millis remote fetches was throttled by a broker - kafka.server:type=RemoteLogManager, name=remote-fetch-throttle-time-max + kafka.server:type=RemoteLogManager, name=remote-fetch-throttle-time-max RemoteLogManager Avg Broker Copy Throttle Time @@ -2055,7 +2055,7 @@
    < Latest Metadata Snapshot Age - The interval in milliseconds since the latest snapshot that the node has generated. + The interval in milliseconds since the latest snapshot that the node has generated. If none have been generated yet, this is approximately the time delta since the process was started. kafka.server:type=SnapshotEmitter,name=LatestSnapshotGeneratedAgeMs @@ -2160,7 +2160,7 @@
    Counts the number of times this node has seen a new controller elected. A transition to the "no leader" state is not counted here. If the same controller as before becomes active, that still counts. kafka.controller:type=KafkaController,name=NewActiveControllersCount @@ -3723,7 +3723,7 @@

    6.9

    Stable version

    The current stable branch is 3.8. Kafka is regularly updated to include the latest release in the 3.8 series. - +

    ZooKeeper Deprecation

    With the release of Apache Kafka 3.5, Zookeeper is now marked deprecated. Removal of ZooKeeper is planned in the next major release of Apache Kafka (version 4.0), which is scheduled to happen no sooner than April 2024. During the deprecation phase, ZooKeeper is still supported for metadata management of Kafka clusters, @@ -3732,10 +3732,10 @@

    Migration

    Users are recommended to begin planning for migration to KRaft and also begin testing to provide any feedback. Refer to ZooKeeper to KRaft Migration for details on how to perform a live migration from ZooKeeper to KRaft and current limitations.

    - +
    3.x and ZooKeeper Support

    The final 3.x minor release, that supports ZooKeeper mode, will receive critical bug fixes and security fixes for 12 months after its release.

    - +

    Operationalizing ZooKeeper

    Operationally, we do the following for a healthy ZooKeeper installation: