From f8f9e0fa04d2ba48ab9c50b10712b855907997a1 Mon Sep 17 00:00:00 2001 From: Andi Skrgat Date: Thu, 14 Aug 2025 10:07:31 +0200 Subject: [PATCH] Add replication lag --- pages/clustering/high-availability.mdx | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/pages/clustering/high-availability.mdx b/pages/clustering/high-availability.mdx index 3629f2c7a..04e15e1d1 100644 --- a/pages/clustering/high-availability.mdx +++ b/pages/clustering/high-availability.mdx @@ -294,8 +294,6 @@ e.g during a maintenance work on the instance where the current MAIN is deployed - - ### Unregister instance There are various reasons which could lead to the decision that an instance needs to be removed from the cluster. The hardware can be broken, @@ -366,6 +364,16 @@ This query will return the information about: If the query `ADD COORDINATOR` wasn't run for the current instance, the value of the bolt server will be "". +### Show replication lag + +The user can find the current replication lag on each instance by running `SHOW REPLICATION LAG` on the cluster's leader. The replication lag is expressed with +the number of committed transactions. Such an info is made durable through snapshots and WALs so restarts won't cause the information loss. The information +about the replication lag can be useful when manually performing a failover to check whether there is a risk of a data loss. + +```plaintext +SHOW REPLICATION LAG; +``` + ## Setting config for highly-available cluster