Command-line Usage v1
Compare mode
Copy any /etc/2ndq-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
- Table name
- 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 sayssetup
, it 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
- Time elapsed
- Estimated time to complete
- Speed in records per second
If a table has more rows than the parallel_chunk_rows
setting (see more
details below), 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 like this:
But if any inconsistencies were found, the output will look like this:
Re-check mode
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.
Conflicts mode
To run LiveCompare in conflicts
mode, you should invoke it with:
For more details about the conflicts
mode, check BDR Support chapter.
- On this page
- Compare mode
- Re-check mode
- Conflicts mode