Update configure-hybrid-cluster.md

TheovanKraay · web-flow · commit cb8bc9485f6c · 2022-07-12T15:54:32.000+01:00
diff --git a/articles/managed-instance-apache-cassandra/configure-hybrid-cluster.md b/articles/managed-instance-apache-cassandra/configure-hybrid-cluster.md
@@ -212,7 +212,7 @@ This quickstart demonstrates how to use the Azure CLI commands to configure a hy
    > ```azurecli-interactive
    >     az managed-cassandra cluster update --cluster-name --resource-group--repair-enabled false
    > ```
-   > Then run `nodetool repair --full` on all the nodes in your existing cluster's data center. You should run this **only after all of the prior steps have been taken**. This should ensure that all historical data is replicated to your new data centers in Azure Managed Instance for Apache Cassandra. If you have a very large amount of data in your existing cluster, it may be necessary to run the repairs at the keyspace or even table level - see [here](https://cassandra.apache.org/doc/latest/cassandra/operating/repair.html) for more details on running repairs in Cassandra. Prior to changing the replication settings, you should also make sure that any application code that connects to your existing Cassandra cluster is using LOCAL_QUORUM. You should leave it at this setting during the migration (it can be switched back afterwards if required). After these steps are completed, you can enable automatic repair again. 
+   > Then run `nodetool repair --full` on all the nodes in your existing cluster's data center. You should run this **only after all of the prior steps have been taken**. This should ensure that all historical data is replicated to your new data centers in Azure Managed Instance for Apache Cassandra. If you have a very large amount of data in your existing cluster, it may be necessary to run the repairs at the keyspace or even table level - see [here](https://cassandra.apache.org/doc/latest/cassandra/operating/repair.html) for more details on running repairs in Cassandra. Prior to changing the replication settings, you should also make sure that any application code that connects to your existing Cassandra cluster is using LOCAL_QUORUM. You should leave it at this setting during the migration (it can be switched back afterwards if required). After the migration is completed, you can enable automatic repair again, and point your application code to the new Cassandra Managed Instance data center's seed nodes (and revert the quorum settings if preferred).  
    > 
    > Finally, to decommission your old data center:
    > 

Original file line number	Diff line number	Diff line change
`@@ -212,7 +212,7 @@ This quickstart demonstrates how to use the Azure CLI commands to configure a hy`
`212`	`212`	> ```azurecli-interactive
`213`	`213`	`> az managed-cassandra cluster update --cluster-name --resource-group--repair-enabled false`
`214`	`214`	> ```
`215`		- > Then run `nodetool repair --full` on all the nodes in your existing cluster's data center. You should run this only after all of the prior steps have been taken. This should ensure that all historical data is replicated to your new data centers in Azure Managed Instance for Apache Cassandra. If you have a very large amount of data in your existing cluster, it may be necessary to run the repairs at the keyspace or even table level - see [here](https://cassandra.apache.org/doc/latest/cassandra/operating/repair.html) for more details on running repairs in Cassandra. Prior to changing the replication settings, you should also make sure that any application code that connects to your existing Cassandra cluster is using LOCAL_QUORUM. You should leave it at this setting during the migration (it can be switched back afterwards if required). After these steps are completed, you can enable automatic repair again.
	`215`	+ > Then run `nodetool repair --full` on all the nodes in your existing cluster's data center. You should run this only after all of the prior steps have been taken. This should ensure that all historical data is replicated to your new data centers in Azure Managed Instance for Apache Cassandra. If you have a very large amount of data in your existing cluster, it may be necessary to run the repairs at the keyspace or even table level - see [here](https://cassandra.apache.org/doc/latest/cassandra/operating/repair.html) for more details on running repairs in Cassandra. Prior to changing the replication settings, you should also make sure that any application code that connects to your existing Cassandra cluster is using LOCAL_QUORUM. You should leave it at this setting during the migration (it can be switched back afterwards if required). After the migration is completed, you can enable automatic repair again, and point your application code to the new Cassandra Managed Instance data center's seed nodes (and revert the quorum settings if preferred).
`216`	`216`	`>`
`217`	`217`	`> Finally, to decommission your old data center:`
`218`	`218`	`>`