Update concerns

Author: Josipmrden

pages/clustering/high-availability/best-practices.mdx

@@ -175,7 +175,6 @@ have precedence over command line arguments**, and any set environment variable
 ## Coordinator settings
 
 ### enabled reads on main
-
 There is a configuration option for specifying whether reads from the main are enabled. The configuration value is by
 default false but can be changed in run-time using the following query:
 
@@ -184,22 +183,28 @@ SET COORDINATOR SETTING 'enabled_reads_on_main' TO 'true'/'false' ;
 ```
 
 ### sync failover only
-
-Users can also choose whether failover to the async replica is allowed by using the following query:
+Users can also choose whether failover to the ASYNC REPLICA is allowed by using the following query:
 
 ```
 SET COORDINATOR SETTING 'sync_failover_only' TO 'true'/'false' ;
 ```
 
-### max failover replica lag
+By default, the value is `true`, which means that only SYNC REPLICAs are candidates in the election. When the value is set to
+`false`, the ASYNC REPLICA is also considered, but there is an additional risk of experiencing data loss. 
+
+In extreme cases, failover to an ASYNC REPLICA may be necessary when other SYNC REPLICAs are down and you want to
+manually perform a failover.
 
-Users can control the maximum transaction lag allowed during failover through configuration. If a replica is behind the main instance by more than the configured threshold, 
-that replica becomes ineligible for failover. This prevents data loss beyond the user's acceptable limits.
+### max failover replica lag
+Users can control the maximum transaction lag allowed during failover through configuration. If a REPLICA is behind the MAIN
+instance by more than the configured threshold, that REPLICA becomes ineligible for failover. This prevents data loss
+beyond the user's acceptable limits.
 
-To implement this functionality, we employ a caching mechanism on the cluster leader that tracks replicas' lag. The cache gets updated with each StateCheckRpc response from 
-replicas. During the brief failover window on the cooordinators' side, the new cluster leader may not have the current lag information for all data instances and in that case, 
-any replica can become main. This trade-off is intentional and it avoids flooding Raft logs with frequently-changing lag data while maintaining failover safety guarantees 
-in the large majority of situations.
+To implement this functionality, we employ a caching mechanism on the cluster leader coordinator that tracks replicas' lag. The cache gets
+updated with each `StateCheckRpc` response from REPLICAs. During the brief failover window on the cooordinators' side, the new
+cluster leader may not have the current lag information for all data instances and in that case, any REPLICA can become MAIN.
+This trade-off is intentional and it avoids flooding Raft logs with frequently-changing lag data while maintaining failover safety
+guarantees in the large majority of situations.
 
 
 The configuration value can be controlled using the query:
@@ -208,20 +213,15 @@ The configuration value can be controlled using the query:
 SET COORDINATOR SETTING 'max_failover_replica_lag' TO '10' ;
 ```
 
-By default, the value is `true`, which means that only sync replicas are candidates in the election. When the value is set to `false`, the async replica is also considered, but
-there is an additional risk of experiencing data loss. However, failover to an async replica may be necessary when other sync replicas are down and you want to
-manually perform a failover.
-
-### max_replica_read_lag_ ???
-
-
-Users can control the maximum allowed replica lag to maintain read consistency. When a replica falls behind the current main by more than `max_replica_read_lag_` transactions, the
-bolt+routing protocol will exclude that replica from read query routing to ensure data freshness.
+### max_replica_read_lag
+Users can control the maximum allowed REPLICA lag to maintain read consistency. When a REPLICA falls behind the current MAIN by
+more than `max_replica_read_lag` transactions, the bolt+routing protocol will exclude that REPLICA from read query routing to
+ensure data freshness.
 
 The configuration value can be controlled using the query:
 
 ```
-SET COORDINATOR SETTING 'max_replica_read_lag_' TO '10' ;
+SET COORDINATOR SETTING 'max_replica_read_lag' TO '10' ;
 ```
 
 ## Observability

pages/clustering/high-availability/ha-commands-reference.mdx

@@ -33,7 +33,7 @@ ADD COORDINATOR coordinatorId WITH CONFIG {
 **Parameters:**
 - `coordinatorId` (int) - unique integer for each coordinator. You can set a different incrementing integer for each coordinator as you
   register them.
-- `boltServer` (string) - Network address in format `"IP_ADDRESS|DNS_NAME:PORT_NUMBER"`. Port is usually set to 7687 as
+- `boltServer` (string) - Network address in format `"IP_ADDRESS|DNS_NAME:PORT_NUMBER"`, used for querying the coordinator. Port is usually set to 7687 as
   that is representative for Bolt protocol. If IPs are ephemeral, it's best to use the DNS name/FQDN. The server IP needs
   to be exposed to the external network, if there are any external applications connected to it.
 - `coordinatorServer` (string) - Network address in format `"COORDINATOR_HOSTNAME|COORDINATOR_PORT"`. Coordinator hostname and port
@@ -94,11 +94,15 @@ REGISTER INSTANCE instanceName ( AS ASYNC | AS STRICT_SYNC ) ? WITH CONFIG {
 - `instanceName` (symbolic name) - unique name of the data instance
 - `AS ASYNC` (optional parameter) - register the instance in `ASYNC` replication mode
 - `AS STRICT_SYNC` (optional parameter) - register the instance in `STRICT_SYNC` replication mode
-- `boltServer` (string) - Network address in format "IP_ADDRESS|DNS_NAME:PORT_NUMBER". Port is usually set to 7687 as
-  that is representative for Bolt protocol. If IPs are ephemeral, it's best to use the DNS name/FQDN. The server IP needs
-  to be exposed to the external network, if there are any external applications connected to it.
-- `managementServer` (string) - ???
-- `replicationServer` (string) - ???
+- `boltServer` (string) - Server endpoint used for executing queries against the instance. The endpoint needs to be
+  in format `"IP_ADDRESS|DNS_NAME:PORT_NUMBER"`. Port is usually set to 7687 as that is representative for Bolt protocol.
+  If IPs are ephemeral, it's best to use the DNS name/FQDN. The server IP needs to be exposed to the external network,
+  if there are any external applications connected to it.
+- `managementServer` (string) - Server endpoint used for communication between coordinator and data instance. The endpoint
+  needs to be in format `"IP_ADDRESS|DNS_NAME:PORT_NUMBER"`. The management port needs to be the same, as provided in the command line
+  arguments for that data instance.
+- `replicationServer` (string) - Server endpoint used for replicating data between data instances. The endpoint needs to be in
+  format `"IP_ADDRESS|DNS_NAME:PORT_NUMBER"`. Usual port that is assigned for replication server is 20000.
 
 **Behaviour:**
 - The coordinator instance will connect to the data instance on the `management_server` network address.
@@ -115,12 +119,15 @@ Constructs `( AS ASYNC | AS STRICT_SYNC )` serve to specify a different replicat
 You can only have `STRICT_SYNC` and `ASYNC` or `SYNC` and `ASYNC` replicas together in the cluster. Combining `STRICT_SYNC`
 and `SYNC` replicas together doesn't have proper semantic meaning so it is forbidden.
 
+For local development, hostname of the data instance for management server and replication server is `localhost`. For Helm charts,
+check the name of the service (e.g. `memgraph-coordinator-1.default.svc.cluster.local`).
+
 **Example:**
 ```cypher
 REGISTER INSTANCE instance1 WITH CONFIG {
   "bolt_server": "my_outside_instance1_IP:7687", 
-  "management_server": "???:10000", 
-  "replication_server": "???:20000"
+  "management_server": "memgraph-data-1.default.svc.cluster.local:10000", 
+  "replication_server": "memgraph-data-1.default.svc.cluster.local:20000"
 };
 ```
 

pages/clustering/high-availability/setup-ha-cluster-docker-compose.mdx

@@ -288,6 +288,9 @@ coordinators in the cluster:
 <Callout>
 For localhost development:
 Since the host can't resolve the IP for coordinators and data instances, Bolt
-servers in Docker Compose setup require `bolt_server` set to `localhost:<port>`. ???
+servers in Docker Compose setup require `bolt_server` set to `localhost:<port>`, instead of `127.0.0.1`.
+
+This behaviour is such, because in some Docker Setups, for different machines, the `localhost` is intercepted,
+and mapped to the host network automatically, while `127.0.0.1` stays within the container.
 </Callout>
 </Steps>