From c50824fb28433498a475794358cfcb1e4fad902c Mon Sep 17 00:00:00 2001 From: Andi Skrgat Date: Fri, 11 Apr 2025 09:32:28 +0200 Subject: [PATCH] HA MT failover --- pages/clustering/high-availability.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/pages/clustering/high-availability.mdx b/pages/clustering/high-availability.mdx index e9451e211..f66440a9c 100644 --- a/pages/clustering/high-availability.mdx +++ b/pages/clustering/high-availability.mdx @@ -446,9 +446,9 @@ about other REPLICAs to which it will replicate data. Once that request succeeds When failover is happening, some REPLICAs can also be down. From the list of alive REPLICAs, a new MAIN is chosen. First, the leader coordinator contacts each alive REPLICA to get info about each database's last commit timestamp. In the case of enabled multi-tenancy, from each instance coordinator will get info on all databases and their last commit -timestamp. Currently, the coordinator chooses an instance to become a new MAIN by comparing the latest commit timestamp only of the default database for every instance. -If multiple instances have the same latest commit timestamp, the instance that was registered earlier will be chosen as a new MAIN. - +timestamp. Currently, the coordinator chooses an instance to become a new MAIN by comparing the latest commit timestamps of all databases. The instance which is newest on most +databases is considered the best candidate for the new MAIN. If there are multiple instances which have the same number of newest databases, we sum timestamps of all databases +and consider instance with a larger sum as the better candidate. ### Old MAIN rejoining to the cluster @@ -874,4 +874,4 @@ that and automatically promote the first alive REPLICA to become the new MAIN. T - \ No newline at end of file +