Update and rename kafka-mirroraker-2-0-guide.md to kafka-mirrormaker-2-0-guide.md

Author: sreekzz

articles/hdinsight/kafka/kafka-mirroraker-2-0-guide.md renamed to articles/hdinsight/kafka/kafka-mirrormaker-2-0-guide.md

@@ -1,19 +1,19 @@
 ---
-title: Apache Kafka MirrorMaker 2.0 Guide - Azure HDInsight
+title: Apache Kafka MirrorMaker 2.0 guide - Azure HDInsight
 description: How to to use Kafka MirrorMaker 2.0 in data migration/replication and the use-cases.
 ms.service: hdinsight
 ms.topic: how-to
 ms.custom: hdinsightactive
 ms.date: 05/20/2022
 ---
 
-# How to use Kafka MirrorMaker 2.0 in data migration, replication and the use-cases.
+# How to use Kafka MirrorMaker 2.0 in data migration, replication and the use-cases
 
 MirrorMaker 2 (MM2) is designed to make it easier to mirror or replicate topics from one Kafka cluster to another. It uses the Kafka Connect framework to simplify configuration and scaling. It dynamically detects changes to topics and ensures source and target topic properties are synchronized, including offsets and partitions.
 
 In this article, you'll learn how to use Kafka MirrorMaker 2.0 in data migration/replication and the use-cases.
 
-## Pre-requisites
+## Prerequisites
 
 * Environment with at least two HDI Kafka clusters.
 * Kafka version higher than 2.4 (HDI 4.0) 
@@ -29,31 +29,30 @@ Simulation of MirrorMaker 2.0 to replicate data points/offsets between two Kafka
 
 The Mirrormaker2 tool is composed of different connectors. These connectors are standard Kafka Connect connectors, which can be used directly with Kafka Connect in standalone or distributed mode.
 
-
 The summary of the broker setup process is as follows:
 
-1. MirrorSourceConnector :
+**MirrorSourceConnector :**
 
-    1. Replicates remote topics, topic ACLs & configs of a single source cluster.
-    1. Emits offset-syncs to an internal topic.
+  1. Replicates remote topics, topic ACLs & configs of a single source cluster.
+  1. Emits offset-syncs to an internal topic.
 
-1. MirrorSinkConnector:
+**MirrorSinkConnector:**
 
-    1. Consumes from the primary cluster and replicate topics to a single target cluster.
+  1. Consumes from the primary cluster and replicate topics to a single target cluster.
 
-1. MirrorCheckpointConnector:
+**MirrorCheckpointConnector:**
 
-    1. Consumes offset-syncsr.
-    1.Emits checkpoints to enable failover points.
-   
- 1. MirrorHeartBeatConnector:
+   1.Consumes offset-syncsr.
+   1.Emits checkpoints to enable failover points.
+  
+**MirrorHeartBeatConnector:**
 
-    1. Emits heartbeats to remote clusters, enabling monitoring of replication process.
+  1. Emits heartbeats to remote clusters, enabling monitoring of replication process.
 
 ### Deployment
 
 1. Connect-mirror-maker.sh script bundled with the Kafka library implements a distributed MM2 cluster, which manages the Connect workers internally based on a config file. Internally Mirrormaker driver creates and handles pairs of each connector – MirrorSourceConnector, MirrorSinkConnector, MirrorCheckpoint connector and MirrorHeartbeatConnector.
-1. Start the Mirormaker2.
+1. Start the Mirormaker 2.
 
 ```
 ./bin/connect-mirror-maker.sh ./config/mirror-maker.properties    
@@ -149,21 +148,21 @@ destination.sasl.mechanism=GSSAPI
 
 **How will the consumers behave on migration, if that the destination cluster may have a different offset mapping to data points?**
 
-  Mirrormaker2’s MirrorCheckpointConnector automatically stores consumer group offset checkpoints for consumer groups on the source cluster. Each checkpoint  contains a mapping of the last committed offset for each group in the source cluster to the equivalent offset in destination cluster. So on migration the consumers that start consuming from same topic on the destination cluster will be able to resume receiving messages from the last offset they committed on the source cluster. 
+  Mirrormaker 2’s MirrorCheckpointConnector automatically stores consumer group offset checkpoints for consumer groups on the source cluster. Each checkpoint  contains a mapping of the last committed offset for each group in the source cluster to the equivalent offset in destination cluster. So on migration the consumers that start consuming from same topic on the destination cluster will be able to resume receiving messages from the last offset they committed on the source cluster. 
 
 **How can we retain the exact topic name in destination cluster, as the source alias is prefixed with all the topics replicated?**
 
-  This is the default behavior in Mirrormaker2.0 to avoid data overriding in complex mirroring topologies. Customization of this needd to be done carefully in terms of replication flow design and topic management to avoid data loss. This can be done by using a custom replication policy class against “replication.policy.class”.
+  This is the default behavior in Mirrormaker2.0 to avoid data overriding in complex mirroring topologies. Customization of this needs to be done carefully in terms of replication flow design and topic management to avoid data loss. This can be done by using a custom replication policy class against “replication.policy.class”.
 
 **Why do we see new internal topics created in my source and destination Kafka?**
 
-  Mirrormaker2 internal topics are created by the Connectors to keep track of the replication process, monitoring, offset mapping and checkpointing.
+  Mirrormaker 2 internal topics are created by the Connectors to keep track of the replication process, monitoring, offset mapping and checkpointing.
 
 **Why does the mirrormaker creates only two replicas of the topic in the destination cluster while the source has more?**
 
-  Mirrormaker2 doesn’t replicate the replication factor of topics to target clusters. This can be controlled from MM2 config, by specifying the required number of “replication.factor”. The default value for the same is two.
+  Mirrormaker 2 doesn’t replicate the replication factor of topics to target clusters. This can be controlled from MM2 config, by specifying the required number of “replication.factor”. The default value for the same is two.
 
-**How to use custom replication policy in Mirrormaker2?**
+**How to use custom replication policy in Mirrormaker 2?**
 
   Custom Replication Policy can be created by implementing the interface below.