LiveCompare
===========

LiveCompare is designed to compare any number of databases to verify
they’re identical. The tool compares the databases and generates a
comparison report, a list of differences, and handy DML scripts so you
can optionally apply the DML and fix the inconsistencies in any of the
databases.

By default, the comparison set includes all tables in the database.
LiveCompare allows checking of multiple tables concurrently (multiple
worker processes) and is highly configurable to allow checking just a
few tables or just a section of rows in a table.

Each database comparison is called a *comparison session*. When the
program starts for the first time, it starts a new session and starts
comparing table by table. In standalone mode, once all tables are
compared, the program stops and generates all reports. You can start and
stop LiveCompare without losing context information, so you can run it
at convenient times.

Each table comparison operation is called a *comparison round*. If the
table is too big, LiveCompare splits the table into multiple comparison
rounds that are also executed in parallel, alongside other tables that
are being carried on by other workers at the same time.

In standalone mode, the initial comparison round for a table starts from
the beginning of the table (oldest existing PK) to the end of the table
(newest existing PK). New rows inserted after the round starts are
ignored. LiveCompare sorts the PK columns to get min and max PK from
each table. For each PK column that’s unsortable, LiveCompare casts its
content to ``string`` . In PostgreSQL, you achieve this by using
``::text`` . In Oracle, use ``to_char`` .

When executing the comparison algorithm, each worker requires N+1
database connections, where N is the number of databases being compared.
The extra required connection is to an output/reporting database, where
the program cache is kept too, enabling you to stop and resume a
comparison session.

You can manually recheck any differences found by the comparison
algorithm at a later, convenient time. We recommend doing this to allow
a replication consistency check. Upon the difference recheck,
replication might have caught up on that specific row and the difference
doesn’t exist anymore, so the difference is removed. Otherwise it’s
marked as permanent.

At the end of the execution, the program generates a DML script so you
can review it and fix differences one by one. Or you can apply the
entire DML script to fix all permanent differences.

You can potentially use LiveCompare to ensure logical data integrity at
the row level, for example, for these scenarios:

- Database technology migration (Oracle x Postgres).

- Server migration or upgrade (old server x new server).

- Physical replication (primary x standby).

- After failover incidents, for example to compare the new primary data
  against the old, isolated primary data.

- In case of an unexpected split-brain situation after a failover. If
  the old primary wasn’t properly fenced and the application wrote data
  into it, you can use LiveCompare to know exactly the data that’s
  present in the old primary and isn’t present in the new primary. If
  they want, the DBA can use the DML script that LiveCompare generates
  to apply those data into the new primary.

- Logical replication. Three kinds of logical replication technologies
  are supported: Postgres native logical replication, pglogical, and EDB
  Postgres Distributed (PGD, formerly known as BDR).

.. toctree::
  :maxdepth: 3

  ch_01
  rel_notes--index
  requirements
  installation
  supported_technologies
  command_line_usage
  advanced_usage
  bdr_support
  oracle_support
  licenses
  settings--index