|
|
|
|
##
|
|
|
|
|
# Licensed to the Apache Software Foundation (ASF) under one or more
|
|
|
|
|
# contributor license agreements. See the NOTICE file distributed with
|
|
|
|
|
# this work for additional information regarding copyright ownership.
|
|
|
|
|
# The ASF licenses this file to You under the Apache License, Version 2.0
|
|
|
|
|
# (the "License"); you may not use this file except in compliance with
|
|
|
|
|
# the License. You may obtain a copy of the License at
|
|
|
|
|
#
|
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
#
|
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
|
# limitations under the License.
|
|
|
|
|
##
|
|
|
|
|
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
# This file contains some of the configurations for the Kafka Connect distributed worker. This file is intended
|
|
|
|
|
# to be used with the examples, and some settings may differ from those used in a production system, especially
|
|
|
|
|
# the `bootstrap.servers` and those specifying replication factors.
|
|
|
|
|
|
|
|
|
|
# A list of host/port pairs to use for establishing the initial connection to the Kafka cluster.
|
|
|
|
|
bootstrap.servers=localhost:9092
|
|
|
|
|
|
|
|
|
|
# unique name for the cluster, used in forming the Connect cluster group. Note that this must not conflict with consumer group IDs
|
|
|
|
|
group.id=connect-cluster
|
|
|
|
|
|
|
|
|
|
# The converters specify the format of data in Kafka and how to translate it into Connect data. Every Connect user will
|
|
|
|
|
# need to configure these based on the format they want their data in when loaded from or stored into Kafka
|
|
|
|
|
key.converter=org.apache.kafka.connect.json.JsonConverter
|
|
|
|
|
value.converter=org.apache.kafka.connect.json.JsonConverter
|
|
|
|
|
# Converter-specific settings can be passed in by prefixing the Converter's setting with the converter we want to apply
|
|
|
|
|
# it to
|
|
|
|
|
key.converter.schemas.enable=true
|
|
|
|
|
value.converter.schemas.enable=true
|
|
|
|
|
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
# The internal converter used for offsets, config, and status data is configurable and must be specified, but most users will
|
|
|
|
|
# always want to use the built-in default. Offset, config, and status data is never visible outside of Kafka Connect in this format.
|
|
|
|
|
internal.key.converter=org.apache.kafka.connect.json.JsonConverter
|
|
|
|
|
internal.value.converter=org.apache.kafka.connect.json.JsonConverter
|
|
|
|
|
internal.key.converter.schemas.enable=false
|
|
|
|
|
internal.value.converter.schemas.enable=false
|
|
|
|
|
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
# Topic to use for storing offsets. This topic should have many partitions and be replicated and compacted.
|
|
|
|
|
# Kafka Connect will attempt to create the topic automatically when needed, but you can always manually create
|
|
|
|
|
# the topic before starting Kafka Connect if a specific topic configuration is needed.
|
|
|
|
|
# Most users will want to use the built-in default replication factor of 3 or in some cases even specify a larger value.
|
|
|
|
|
# Since this means there must be at least as many brokers as the maximum replication factor used, we'd like to be able
|
|
|
|
|
# to run this example on a single-broker cluster and so here we instead set the replication factor to 1.
|
|
|
|
|
offset.storage.topic=connect-offsets
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
offset.storage.replication.factor=1
|
|
|
|
|
#offset.storage.partitions=25
|
|
|
|
|
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
# Topic to use for storing connector and task configurations; note that this should be a single partition, highly replicated,
|
|
|
|
|
# and compacted topic. Kafka Connect will attempt to create the topic automatically when needed, but you can always manually create
|
|
|
|
|
# the topic before starting Kafka Connect if a specific topic configuration is needed.
|
|
|
|
|
# Most users will want to use the built-in default replication factor of 3 or in some cases even specify a larger value.
|
|
|
|
|
# Since this means there must be at least as many brokers as the maximum replication factor used, we'd like to be able
|
|
|
|
|
# to run this example on a single-broker cluster and so here we instead set the replication factor to 1.
|
|
|
|
|
config.storage.topic=connect-configs
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
config.storage.replication.factor=1
|
|
|
|
|
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
# Topic to use for storing statuses. This topic can have multiple partitions and should be replicated and compacted.
|
|
|
|
|
# Kafka Connect will attempt to create the topic automatically when needed, but you can always manually create
|
|
|
|
|
# the topic before starting Kafka Connect if a specific topic configuration is needed.
|
|
|
|
|
# Most users will want to use the built-in default replication factor of 3 or in some cases even specify a larger value.
|
|
|
|
|
# Since this means there must be at least as many brokers as the maximum replication factor used, we'd like to be able
|
|
|
|
|
# to run this example on a single-broker cluster and so here we instead set the replication factor to 1.
|
|
|
|
|
status.storage.topic=connect-status
|
KAFKA-4667: Connect uses AdminClient to create internal topics when needed (KIP-154)
The backing store for offsets, status, and configs now attempts to use the new AdminClient to look up the internal topics and create them if they don’t yet exist. If the necessary APIs are not available in the connected broker, the stores fall back to the old behavior of relying upon auto-created topics. Kafka Connect requires a minimum of Apache Kafka 0.10.0.1-cp1, and the AdminClient can work with all versions since 0.10.0.0.
All three of Connect’s internal topics are created as compacted topics, and new distributed worker configuration properties control the replication factor for all three topics and the number of partitions for the offsets and status topics; the config topic requires a single partition and does not allow it to be set via configuration. All of these new configuration properties have sensible defaults, meaning users can upgrade without having to change any of the existing configurations. In most situations, existing Connect deployments will have already created the storage topics prior to upgrading.
The replication factor defaults to 3, so anyone running Kafka clusters with fewer nodes than 3 will receive an error unless they explicitly set the replication factor for the three internal topics. This is actually desired behavior, since it signals the users that they should be aware they are not using sufficient replication for production use.
The integration tests use a cluster with a single broker, so they were changed to explicitly specify a replication factor of 1 and a single partition.
The `KafkaAdminClientTest` was refactored to extract a utility for setting up a `KafkaAdminClient` with a `MockClient` for unit tests.
Author: Randall Hauch <rhauch@gmail.com>
Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>
Closes #2984 from rhauch/kafka-4667
8 years ago
|
|
|
status.storage.replication.factor=1
|
|
|
|
|
#status.storage.partitions=5
|
|
|
|
|
|
|
|
|
|
# Flush much faster than normal, which is useful for testing/debugging
|
|
|
|
|
offset.flush.interval.ms=10000
|
|
|
|
|
|
|
|
|
|
# These are provided to inform the user about the presence of the REST host and port configs
|
|
|
|
|
# Hostname & Port for the REST API to listen on. If this is set, it will bind to the interface used to listen to requests.
|
|
|
|
|
#rest.host.name=
|
|
|
|
|
#rest.port=8083
|
|
|
|
|
|
|
|
|
|
# The Hostname & Port that will be given out to other workers to connect to i.e. URLs that are routable from other servers.
|
|
|
|
|
#rest.advertised.host.name=
|
|
|
|
|
#rest.advertised.port=
|
|
|
|
|
|
|
|
|
|
# Set to a list of filesystem paths separated by commas (,) to enable class loading isolation for plugins
|
|
|
|
|
# (connectors, converters, transformations). The list should consist of top level directories that include
|
|
|
|
|
# any combination of:
|
|
|
|
|
# a) directories immediately containing jars with plugins and their dependencies
|
|
|
|
|
# b) uber-jars with plugins and their dependencies
|
|
|
|
|
# c) directories immediately containing the package directory structure of classes of plugins and their dependencies
|
|
|
|
|
# Examples:
|
|
|
|
|
# plugin.path=/usr/local/share/java,/usr/local/share/kafka/plugins,/opt/connectors,
|
|
|
|
|
#plugin.path=
|
