How to handle ties in LiveCompare

This article explains why LiveCompare might not generate an apply file to fix the divergences in a cluster and how to set the configuration to handle this.

Sometimes LiveCompare might not generate the apply_*.sql file to fix a divergence that was previously detected. This is the expected behavior, for example, when comparing only 2 database nodes: a Source Connection and Target Connection, as LiveCompare doesn't know what to do in this case. Should LiveCompare suggest to fix the Source or the Target?

For other cases, when comparing more than 2 connections (like in a BDR cluster), then by default LiveCompare suggests the apply_*.sql file to fix the divergences according to the majority of the connections.

For example, having nodes A, B and C, and if a specific row exists on nodes A and B but not in C, then LiveCompare would suggest to INSERT the row in C, in order to be consistent with the majority. We call this "LiveCompare Consensus Algorithm". The behavior explained is the default behavior as consensus_mode = simple_majority.

However, when there is an even number of connections, then there is the chance that half of the connections have the row while the other half of the connections don't have the row. We call this a "Tie".

When comparing only 2 nodes, then every divergence detected will be considered a Tie. It's up to the user to determine how to break the tie. There are 2 possibilities as explained below:

For example, if you want to consider the data on the Source Connection as the correct data, or the true data, and for every divergence detected you would like to fix the Target Connection, then you can configure as follows:

[General Settings]
...
difference_tie_breakers = source

Note: you can use the connection name as in this example or the BDR node name when using logical_replication_mode = bdr and all_bdr_nodes = on

Once LiveCompare is run again, the apply_on_the_target.sql or apply_on_<node_name>.sql script will be generated, suggesting you to run the SQL on the Target Connection or Node_name, so it will be consistent with Source Connection.

A different strategy would be to specify a "Source of Truth", i.e., the connection that should always "win" the comparison, regardless of other connections disagreeing with it:

[General Settings]
...
consensus_mode = source_of_truth
difference_sources_of_truth = source

When comparing only 2 connections, then either setting a Tie Breaker or a Source of Truth has exactly the same effect. However, when comparing 3 or more connections, then they can have different behaviors depending on the case:

• The Tie Breaker connections are used only in case of a tie;

• The Source of Truth connections always win the comparison.