Copy any /etc/livecompare/template*.ini to use in your project and adjust as necessary. See Settings.
While LiveCompare executes, N+1 progress bars appear, where N is the number of processes. (You can specify the number of processes in the settings.) The first progress bar shows overall execution. 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 can be the ID of the comparison round followed by the current table chunk.
p1/1 means the table wasn't split. A status of setup means the table is being analyzed (checking row count and splitting if necessary).
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 is used to determine the job that considers each row. This can slow down the comparison individually. However the comparison as a whole might benefit from parallelism for the given table.
While the program is executing, you can cancel it at any time by pressing Ctrl-C. A message like the following appears:
If LiveCompare is running in the background or running in another shell, you can still softly stop it. It keeps the PID of the master process inside the session folder (lc_session_6 in the example) 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, the output is similar to the following:
If any inconsistencies were found, the output looks like this:
In a PGD environment, any divergence that PGD finds can later not exist, 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, you can manually execute a recheck only on the differences that were previously found. This execution mode is called recheck. You can execute it like this:
In this mode, LiveCompare generates separate recheck logs and updates all reports that already exist in the lc_session_X directory.
If resuming a compare or executing under recheck, LiveCompare checks whether the settings and connections attributes are the same as when the session was created. If any divergence is found, it quits the execution and gives a message.
To run LiveCompare in conflicts mode, invoke it with:
For more details about the conflicts mode, see PGD support.
LiveCompare dry-run mode support is available for LiveCompare version 2.2.0 and later.
For example, suppose you have the following INI file:
As the DSN under Output Connection (the LiveCompare cache database) is incorrect, running LiveCompare initially fails with:
After fixing this, then the output connection is now reachable. But suppose that only one of the data connections is set correctly. In that case, LiveCompare fails again with:
LiveCompare can start a comparison with at least two data connections available. So you go ahead and fix the third connection. But LiveCompare still fails with:
This happens because the example 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 can start the comparison.
However, when setting up a comparison from scratch, you can check beforehand whether LiveCompare will abort with a configuration error. Further checks of this nature are all shown in the order LiveCompare performs them.
You can do this with the --dry-run mode, which:
Prints all execution aborts that will happen due to configuration issues.
Prints the list of connections with some details, including if it's reachable.
Prints the table filter.
After applying the table filter, prints the list of tables that are common to the reachable connections.
Here's one sample output, given the example .ini file, and all configuration errors regarding unreachable connections: