[
https://issues.apache.org/jira/browse/KAFKA-13827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522714#comment-17522714
]
Sharad Garg commented on KAFKA-13827:
-------------------------------------
[~mumrah] I am sharing the diff of server.properties below-
{code:java}
############################# Server Basics #############################
# The id of the broker. This must be set to a unique integer for each broker.
+process.roles=broker,controller
broker.id=1
+controller.quorum.voters=1@myhost1:9098
############################# Socket Server Settings
#############################
# listeners = listener_name://host_name:port
# EXAMPLE:
# listeners = PLAINTEXT://your.host.name:9096
-listeners=SASL_PLAINTEXT://0.0.0.0:9096,SASL_SSL://myhost1:9097
-
-security.inter.broker.protocol=SASL_SSL
+listeners=SASL_PLAINTEXT://0.0.0.0:9096,SASL_SSL://myhost1:9097,CONTROLLER://myhost1:9098
+inter.broker.listener.name=SASL_SSL
+#security.inter.broker.protocol=SASL_SSL
sasl.mechanism.inter.broker.protocol=GSSAPI
sasl.enabled.mechanisms=GSSAPI
sasl.kerberos.service.name=kafka
@@ -41,6 +43,10 @@ sasl.kerberos.service.name=kafka
# returned from java.net.InetAddress.getCanonicalHostName().
#advertised.listeners=PLAINTEXT://your.host.name:9096
advertised.listeners=SASL_PLAINTEXT://myhost1:9096,SASL_SSL://myhost1:9097
+controller.listener.names=CONTROLLER
+
+# Maps listener names to security protocols, the default is for them to be the
same. See the config documentation for more details
+listener.security.protocol.map=CONTROLLER:SASL_PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
-authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
+authorizer.class.name=kafka.security.authorizer.AclAuthorizer
{code}
[~mumrah] ...by "v2.8/v3.1", do you mean you were running IBP 2.8 on Kafka 3.1?
No. These are two separate instances. Explanation below-
# I started my brokers to use Kafka v2.8. (Binary picked from
[https://archive.apache.org/dist/kafka/2.8.1/kafka_2.13-2.8.1.tgz)]
# Created a topic with 10 messages here.
# Stopped the brokers.
# Started brokers on same node to use Kafka v3.1 in normal mode that is non
KRAFT. (Binary picked from
[https://www.apache.org/dyn/closer.cgi?path=/kafka/3.1.0/kafka_2.13-3.1.0.tgz)]
# Here the old 10 messages persisted and I was also able to publish new
messages to the topic.
# Stopped the brokers.
# Started brokers on same node to use Kafka v3.1 KRAFT mode + ZK also running
to support ACLs.
# Here the topic persisted but was empty, all data was deleted.
Are we supporting to upgrade existing clusters running in non KRAFT mode to
migrate to KRAFT mode? If yes, then could you please suggest what I might be
missing here.
> Data Loss on moving to KRAFT mode from v3.1
> -------------------------------------------
>
> Key: KAFKA-13827
> URL: https://issues.apache.org/jira/browse/KAFKA-13827
> Project: Kafka
> Issue Type: Bug
> Components: kraft
> Reporter: Sharad Garg
> Priority: Major
>
> * Topics created in v2.8/v3.1 that have data are empty (data is deleted) in
> KRAFT mode. These topics are recreated in KRAFT mode and take some time to
> show up in listTopics (~90s) after the brokers are up. Below logs are seen in
> server.logs-
> {code:java}
> [2022-04-07 23:58:49,771] INFO [Controller 1] Created topic
> kafkaalpha.gargsha.test5 with topic ID APdVTk-9S-uf2q_bm9NpzQ.{nolookups}
> (org.apache.kafka.controller.ReplicationControlManager)
> [2022-04-07 23:58:49,771] INFO [Controller 1] Created partition
> kafkaalpha.gargsha.test5-0 with topic ID APdVTk-9S-uf2q_bm9NpzQ and
> PartitionRegistration(replicas=[2], isr=[2], removingReplicas=[],
> addingReplicas
> =[], leader=2, leaderEpoch=0, partitionEpoch=0).{nolookups}
> (org.apache.kafka.controller.ReplicationControlManager){code}
> * Topic configurations altered in v2.8/v3.1 are not persisted in KRAFT mode.
> * Topics with no data in v2.8 are deleted when migrated to KRAFT v3.1.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
