...

This page is meant as a template for writing a KIP. To create a KIP choose Tools->Copy on this page and modify with your content and replace the heading with the next KIP number and a description of your issue. Replace anything in italics with your own description.

Status

Current state:  Under Discussion Completed

Discussion thread: here

JIRA: here KAFKA-5163 and KAFKA-5694

Released:  <Kafka Version>1.1.0

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

The idea is that user can send a ChangeReplicaDirRequest AlterReplicaDirRequest which tells broker to move topicPartition directory (which contains all log segments of the topicPartition replica) from the source log directory to a destination log directory. Broker can create a new directory with .move postfix on the destination log directory to hold all log segments of the replica. This allows broker to tell log segments of the replica on the destination log directory from log segments of the replica on the source log directory during broker startup. The broker can create new log segments for the replica on the destination log directory, push data from source log to the destination log, and replace source log with the destination log for this replica once the new log has caught up.

...

1. Initiate replica movement using ChangeReplicaDirRequestusing AlterReplicaDirRequest

User uses kafka-reassignemntreassignment-partitions.sh to send ChangeReplicaDirRequest AlterReplicaDirRequest to broker to initiate replica movement between its log directories. The flow graph below illustrates how broker handles ChangeReplicaDirRequest AlterReplicaDirRequest.

Notes:
- Broker will cancel existing movement of the replica if "any" is specified as destination log directory.
- If broker doesn't not have already replica created for the specified topicParition when it receives AlterReplicaDirRequest, it will reply ReplicaNotAvailableException AND remember (replica, destination log directory) pair in memory to create the replica in the specified log directory when it receives LeaderAndIsrRequest later.

2. Complete replica 2. Complete replica data movement

Here we describe how a broker moves a Log from source to destination log directory and swaps the Log.  This corresponds to the "Initiate replica data movement" box in the flow graph above. Note that the broker responds to ChangeReplicaDirRequest AlterReplicaDirRequest with MoveInProgress after step 1) described below.

...

3. Handle failure that happens when 3. Handle failure that happens broker is moving data or swapping replica

...

- If both the directory topicPartition and the directory topicPartition.move exist on good log directories, broker will start ReplicaMoveThread to copy data from topicPartition to topicPartition.move. The effect is the same as if broker has received ChangeReplicaDirRequest AlterReplicaDirRequest to move replica from topicPartition to topicPartition.move.
- If topicPartition.move exists but topicPartition doesn't exist on any good log directory, and if there is no bad log directory, then broker renames topicPartition.move to topicPartition.
- If topicPartition.move exists but topicPartition doesn't exist on any good log directory, and if there is bad log directory, then broker considers topicPartition as offline and would not touch topicPartition.move.
- If topicPartition.delete exists, the broker schedules topicParition.delete for asynchronous delete.

...

The idea is that user should be able to specify log directory when using kafka-reassign-partitions.sh to reassign partition. If user has specified log directory on the destination broker, the script should send ChangeReplicaDirRequest AlterReplicaDirRequest directly to the broker so that broker can start ReplicaMoveThread to move the replica. Finally, the script should send DescribeDirsRequest DescribeLogDirsRequest to broker to verify that the replica has been created/moved in the specified log directory when user requests to verify the assignment.

...

- User specifies a list of log directories, one log directory per replica, for each topic partition in the reassignment json file that is provided to kafka-reassignemntreassignment-partitions.sh. The log directory specified by user must be either "any", or absolute path which begins with '/'.  See Scripts section for the format of this json file.
- In addition to creating znode at /admin/reassign_partitions with the replica assignment, the script will also send ChangeReplicaDirRequest to the brokers of those replicas whose log directory path in the assignment is not "any". The script needs to retry up to a configured amount of time if ChangeReplicaDirResponse shows ReplicaNotAvailableException. This is needed to wait for controller to send LeaderAndIsrRequest to the broker to create the replica if the broker isn't already a leader or follower of the partition.
- Broker handles ChangeReplicaDirRequest as specified in the section "How to move replica between log directories on the same broker".

Here are the steps to verify partition assignment:

If "any" is specified as the log directory, the broker is free to choose any log directory to place the replica. Current broker implementation will select log directory using round-robin algorithm by default. See Scripts section for the format of this json file.
- The script sends AlterReplicaDirRequest to those brokers which need to move replicas to user-specified log directory. This step can be skipped if user has specified "any" as log directory for all replicas. The script exits with error if the broker to receive AlterReplicaDirRequest is offline or if the AlterReplicaDirResponse contains any error that is not ReplicaNotAvailableException.
- The script creates reassignment znode in zookeeper.
- The script retries AlterReplicaDirRequest to those brokers which have responded with ReplicaNotAvailableException in the AlterReplicaDirResponse previously. The script keeps retrying up to user-specified timeout. The timeout is 10 seconds by default. The script exits with error if the broker to receive AlterReplicaDirRequest is offline or if the AlterReplicaDirResponse contains any error that is not ReplicaNotAvailableException.
- The script returns result to user.

Here are the steps to verify partition assignment:

- kafka-reassignment-partitions.sh will verify partition assignment - kafka-reassignemnt-partitions.sh will verify partition assignment across brokers as it does now. 
- For those replicas with destination log directory != "any", kafka-reassignemntreassignment-partitions.sh groups those replicas according to their brokers and and sends DescribeDirsRequest DescribeLogDirsRequest to those brokers. The DescribeDirsRequest DescribeLogDirsRequest should provide the log directories and partitions specified in the expected assignment.
- Broker replies with DescribeDirsResponseDescribeLogDirsResponse which shows the current log directory for each partition specified in the DescribeDirsRequest DescribeLogDirsRequest.
- kafka-reassignemntreassignment-partitions.sh determines whether the replica has been moved to the specified log directory based on the DescribeDirsResponseDescribeLogDirsResponse.

3) How to retrieve information to determine the new replica assignment across log directories

...

In order to optimize replica assignment across log directories, user would need to figure out the list partitions per log directory, the size of each partition. As of now Kafka doesn't expose this information via any RPC and user would need to either query the JMX metrics of the broker, or use external tools to log onto each machine to get this information. While it is possible to retrieve these information via JMX, users would have to manage JMX port and related credentials. It is better if Kafka can expose this information via RPC.

Solution:

We introduce DescribeDirsRequest DescribeLogDirsRequest and DescribeDirsResponseDescribeLogDirsResponse. When a broker receives DescribeDirsRequestDescribeLogDirsRequest with empty list of log directories, it will respond with a DescribeDirsResponseDescribeLogDirsResponse which shows the size of each partition and lists of partitions per log directory for all log directories. If user has specified a list of log directories in the DescribeDirsRequestDescribeLogDirsRequest, the broker will provide the above information for only log directories specified by the user. If user has specified an empty list of topics in the DescribeDirsRequestDescribeLogDirsRequest, all topics will be queried and included in the response. Otherwise, only those topics specified in the DescribeDirsRequest DescribeLogDirsRequest will be queried. Non-zero error code will be specified in the DescribeDirsResponseDescribeLogDirsResponse for each log directory that is either offline or not found by the broker.

...

Public interface

Protocol

Create ChangeReplicaDirRequestAlterReplicaDirRequest

ChangeReplicaDirRequestAlterReplicaDirRequest => topics
  topics => [ChangeReplicaDirRequestTopicAlterReplicaDirRequestTopic]
 
ChangeReplicaDirRequestTopicAlterReplicaDirRequestTopic => topic partitions
  topic => str
  partitions => [ChangeReplicaDirRequestPartitionAlterReplicaDirRequestPartition]

ChangeReplicaDirRequestPartitionAlterReplicaDirRequestPartition => partition log_dir
  partition => int32
  log_dir => str

ChangeReplicaDirResponseAlterReplicaDirResponse => topics
  topics => [ChangeReplicaDirResponseTopicAlterReplicaDirResponseTopic]
 
ChangeReplicaDirResponseTopicAlterReplicaDirResponseTopic => topic partitions
  topic => str
  partitions => [ChangeReplicaDirResponsePartitionAlterReplicaDirResponsePartition]
 
ChangeReplicaDirResponsePartitionAlterReplicaDirResponsePartition => partition error_code
  partition => int32
  error_code => int16

DescribeDirsRequestDescribeLogDirsRequest => log_dirs topics
  log_dirstopics => [str]DescribeLogDirsRequestTopic  // If this is nullempty, then all log directoriestopics will be queried
 
DescribeLogDirsRequestTopic  topics=> topic partitions
  topic => [str]
 // Ifpartitions this is null, all topics will be queried=> [int32]

DescribeDirsResponseDescribeLogDirsResponse => log_dirs
  log_dirs => [DescribeDirsResponseDirMetadataDescribeLogDirsResponseDirMetadata]

DescribeDirsResponseDirMetadataDescribeLogDirsResponseDirMetadata => error_code path topics
  error_code => int16
  path => str
  topics => [DescribeDirsResponseTopicDescribeLogDirsResponseTopic]
 
DescribeDirsResponseTopicDescribeLogDirsResponseTopic => topic partitions
  topic => str
  partitions => [DescribeDirsResponsePartitionDescribeLogDirsResponsePartition]
  
DescribeDirsResponsePartitionDescribeLogDirsResponsePartition => partition size logoffset_end_offsetlag is_temporary
  partition => int32
  size => int64
  logoffset_end_offsetlag => int64
  is_temporary => boolean  // True if replica is // If this is not a temporary replica, then offset_lag = max(0, HW - LEO). Otherwise, offset_lag = primary Replica's LEO - temporary Replica's LEO
  is_temporary => boolean  // True if replica is *.move

Scripts

Scripts

1) Add kafka-log-dirs.sh which allows 1) Add kafka-log-dirs.sh which allows user to get list of replicas per log directory on a broker.

...

{

{
  "version" : 1,
  "log_dirs" : [
    {
      "is_live" : boolean,
      "path" : str,
      "partitions": [
        {
          "topic" : str, 
          "partition" : int32, 
          "size" : int64,
          "offset_lag" : in64,
          "is_temporary" : boolean
        },
        ...
      ]
    },

    ...
  ]
}

{
  "version" : int,
  "partitions" : [
    {
      "topic" : str,
      "partition" : int,
      "replicas" : [int],
      "log_dirs" : [str]    <-- NEW. A log directory can be either "any", or a valid absolute path that begins with '/'
. This is  }an optional filed. It is treated as an array of "any" if this field is not explicitly specified in the json file.
    },
    ...
  ]
}

Note: the quota specified by the argument `–throttle` will be applied to only inter-broker replica reassignment. It does not affect the quota for replica movement between log directories.

3) Add optional argument --timeout to kafka-reassignment3) Add optional argument --timeout to kafka-reassignemnt-partitions.sh. This is because kafka-reassignemntreassignment-partitions.sh may need to re-send ChangeReplicaDirRequest AlterReplicaDirRequest to broker if replica hasn't already been created there. The timeout is set to 10 seconds by default.

Changes in Operational Procedures

In this section we describe the expected changes in operational procedures in order to run Kafka with JBOD. Administrators of Kafka cluster need to be aware of these changes before switching from RAID-10 to JBOD.

- Need to load balance across log directories

When running Kafka with RAID-10, we only need to take care of load imbalance across brokers. Administrator can balance load across brokers using the script kafka-reassign-partitions.sh. After switching from RAID-10 to JBOD, we will start to see load imbalance across log directories. In order to address this problem, administrator needs to get the partition assignment and their size per log directory using kafka-log-dirs.sh, determine the reassignment of replicas per log directory per broker, and provide partition to (broker, log_directory) mapping as input to kafka-reassign-partitions.sh to execute the new assignment.

Administrator also needs to be prepared that the need to rebalance across log directories will probably be much more frequent than the need to rebalance across brokers since the capacity of individual disk is likely much smaller than the capacity of existing RAID-10 setup.

Compatibility, Deprecation, and Migration Plan

This KIP is a pure addition. So there is no backward compatibility concern.

The KIP changes the inter-broker protocol. Therefore the migration requires two rolling bounce. In the first rolling bounce we will deploy the new code but broker will still communicate using the existing protocol. In the second rolling bounce we will change the config so that broker will start to communicate with each other using the new protocol.

Test Plan

The new features will be tested through unit, integration, and system tests. In the following we explain the system tests only. 

AdminClient

The following methods and classes are added.

public interface AdminClient extends AutoCloseable { 
    /**
     * Query the log directory information for the specified log directories on the given brokers.
     * All log directories on a broker are queried if an empty collection of log directories is specified for this broker
     *
     * This operation is supported by brokers with version 0.11.1.0 or higher.
     *
     * @param logDirsByBroker     A list of log dirs per broker
     * @param options             The options to use when querying log dir info
     * @return                    The DescribeLogDirsResult
     */
    public abstract DescribeLogDirsResult describeLogDirs(Map<Integer, Collection<String>> logDirsByBroker, DescribeLogDirsOptions options);
 
    /**
     * Query the replica directory information for the specified replicas.
     *
     * This operation is supported by brokers with version 0.11.1.0 or higher.
     *
     * @param replicas      The replicas to query
     * @param options       The options to use when querying replica dir info
     * @return              The DescribeReplicaLogDirsResult
     */
    public abstract DescribeReplicaLogDirsResult describeReplicaLogDirs(Collection<TopicPartitionReplica> replicas, DescribeReplicaLogDirsOptions options);
}
 
 
public class KafkaAdminClient extends AdminClient {
    /**
     * Alter the log directory for the specified replicas.
     *
     * Updates are not transactional so they may succeed for some resources while fail for others. The log directory for
     * a particular replica is updated atomically.
     *
     * This operation is supported by brokers with version 0.11.1.0 or higher.
     *
     * @param replicaAssignment  The replicas with their log directory absolute path
     * @param options            The options to use when changing replica dir
     * @return                   The AlterReplicaDirResult
     */
    public AlterReplicaDirResult alterReplicaDir(Map<TopicPartitionReplica, String> replicaAssignment, AlterReplicaDirOptions options);
 
}


/**
  * Options for the alterReplicaDir call.
  */
class AlterReplicaDirOptions {
    private Integer timeoutMs = null;
    public AlterReplicaDirOptions timeoutMs(Integer timeoutMs);
    public Integer timeoutMs();
}
 
/**
  * The result of the alterReplicaDir call.
  */
class AlterReplicaDirResult {
    /**
     * Return a map from replica to futures, which can be used to check the status of individual replica movement.
     */
    public Map<TopicPartitionReplica, KafkaFuture<Void>> values();

    /**
     * Return a future which succeeds if all the replica movement have succeeded
     */
    public KafkaFuture<Void> all();
}
 
/**
  * Options for the describeDirs call.
  */
class DescribeLogDirsOptions {
    private Integer timeoutMs = null;
    public DescribeLogDirsOptions timeoutMs(Integer timeoutMs);
    public Integer timeoutMs();
}
 
/**
  * The result of the describeDirs call.
  */
class DescribeLogDirsResult {
    /**
     * Return a map from brokerId to futures which can be used to check the information of partitions on each individual broker
     */
    public Map<Integer, KafkaFuture<Map<String, LogDirInfo>>> values();

    /**
     * Return a future which succeeds only if all the brokers have responded without error
     */
    public KafkaFuture<Map<Integer, Map<String, LogDirInfo>>> all();
}
 
/**
  * Description of a log directory
  */
class LogDirInfo {
    public final Errors error;
    public final Map<TopicPartition, ReplicaInfo> replicaInfos;
}
 
/**
  * Description of a replica
  */
public class ReplicaInfo {
    public final long size;
    public final long logEndOffset;
    public final boolean isTemporary;
}
 
/**
  * Options for the describeReplicaDir call.
  */
class DescribeReplicaLogDirsOptions {
    private Integer timeoutMs = null;
    public DescribeReplicaLogDirsOptions timeoutMs(Integer timeoutMs);
    public Integer timeoutMs();
}
 
/**
  * The result of the describeReplicaDir call.
  */
class DescribeReplicaLogDirsResult {
    /**
     * Return a map from replica to futures which can be used to check the log directory information of individual replicas
     */
    public Map<TopicPartitionReplica, KafkaFuture<ReplicaDirInfo>> values();

    /**
     * Return a future which succeeds if log directory information of all replicas are available
     */
    public KafkaFuture<Map<TopicPartitionReplica, ReplicaDirInfo>> all();
}

/**
  * Log directory information of a given replica and its intra-broker movement progress
  */
class ReplicaDirInfo {
    public String currentReplicaDir;
    public String temporaryReplicaDir;
    public long temporaryReplicaOffsetLag;
}

Changes in Operational Procedures

In this section we describe the expected changes in operational procedures in order to run Kafka with JBOD. Administrators of Kafka cluster need to be aware of these changes before switching from RAID-10 to JBOD.

- Need to load balance across log directories

When running Kafka with RAID-10, we only need to take care of load imbalance across brokers. Administrator can balance load across brokers using the script kafka-reassign-partitions.sh. After switching from RAID-10 to JBOD, we will start to see load imbalance across log directories. In order to address this problem, administrator needs to get the partition assignment and their size per log directory using kafka-log-dirs.sh, determine the reassignment of replicas per log directory per broker, and provide partition to (broker, log_directory) mapping as input to kafka-reassign-partitions.sh to execute the new assignment.

Administrator also needs to be prepared that the need to rebalance across log directories will probably be much more frequent than the need to rebalance across brokers since the capacity of individual disk is likely much smaller than the capacity of existing RAID-10 setup.

Compatibility, Deprecation, and Migration Plan

This KIP is a pure addition. So there is no backward compatibility concern.

The KIP changes the inter-broker protocol. Therefore the migration requires two rolling bounce. In the first rolling bounce we will deploy the new code but broker will still communicate using the existing protocol. In the second rolling bounce we will change the config so that broker will start to communicate with each other using the new protocol.

Test Plan

The new features will be tested through unit, integration, and system tests. In the following we explain the system tests only. 

Rejected Alternatives

...

Rejected Alternatives