Copy any /etc/livecompare/template*.ini to use in your project and adjust
as necessary (see the section Settings below).
During the execution of LiveCompare, you will see N+1 progress bars, N being
the number of processes (you can specify the number of processes in the
settings). The first progress bar shows overall execution while the other
progress bars show the current table being processed by a specific process.
The information being shown for each table is, from left to right:
Number of the process
Status, which may be the ID of the comparison round followed by the current
table chunk (p1/1 means the table was not split). If the status says
setup, it means the table is being analyzed (checking row count and splitting
Number of rows processed
Number of total rows being considered in this comparison round
Estimated time to complete
Speed in records per second
When table splitting is enabled (parallel_chunk_rows > 0), if a table has
more rows than the parallel_chunk_rows setting, then a hash function will
be used to determine which job will consider each row. This can slow down
the comparison individually, but the comparison as a whole may benefit
from parallelism for the given table.
While the program is executing, you can cancel it at any time by pressing
Ctrl-c. You will see a message like this:
Important: If LiveCompare is running in background or running in another shell,
you can still softly stop it. It will keep the PID of the master process inside the
session folder (in the example lc_session_6), in a file named livemaster.pid. You
can then invoke kill -2 <PID> to softly stop it.
Then, at any time you can resume a previously canceled session, for example:
When the program ends, if it found no inconsistencies, you will see an output
But if any inconsistencies were found, the output will look like this:
In a BDR environment, any divergence that BDR finds can be later non-existing
as the replication caught up due to eventual consistency. Depending on several
factors, replication lag can cause LiveCompare to report false positives.
To overcome that, in a later moment when replication lag has decreased or data
has already caught up, users can manually execute a re-check only on the
differences that were previously found. This execution mode is called "recheck"
and can be executed like this:
In this mode, LiveCompare will generate separate recheck logs and update all
reports that are already existing in the lc_session_X directory.
Important: If resuming a compare or executing under recheck,
LiveCompare will check if the settings and connections attributes are the same as
when the session was created. If any divergence found, it will quit the execution
with proper message.
To run LiveCompare in conflicts mode, you should invoke it with:
For more details about the conflicts mode, check BDR Support chapter.
LiveCompare dry-run mode support is available for LiveCompare version 2.2.0 and later.
For example you have the following INI file:
As the DSN for the Output Connection (the LiveCompare cache database) is incorrect,
running LiveCompare initially fails with:
After fixing this, then the Output Connection is now reachable, but let's imagine
that only one of the data connections is set correctly. LiveCompare would fail again
LiveCompare can start a comparison with at least 2 data connections available. So
you go ahead and fix the Third Connection, but then LiveCompare still fails with:
This happens because we have set difference_tie_breakers = first, and any
connection set as a tie breaker or source of truth needs to be reachable.
After fixing all those issues, then LiveCompare is able to start the comparison.
However, when setting up a comparison from scratch, it's possible to check
beforehand whether or not LiveCompare would abort with a configuration error,
and further abortion checks are all shown in the order they are performed by
This is possible with the --dry-run mode, which will:
Print all execution abortions that would happen due to configuration issues;
Print the list of connections with some details, including if it's reachable;
Print the Table Filter;
Print the list of tables that are common to the reachable connections, after
applying the Table Filter.
Here is one sample output, given the INI file exemplified above, and all
configuration errors regarding unreachable connections: