Database Reference
In-Depth Information
Londiste uses an efficient
COPY
command to move data across, and then carefully applies
changes, so that the set of tables all eventually match. You don't need to have all tables in a
single replication set listed on the same command line. The Foreign Keys are restored once
consistency is achieved.
Eventual consistency is probably the most important aspect of this system of replication.
Tables are copied separately, so that there is no need to lock all of the tables on the provider
using one big transaction, such as occurs during a
pg_dump
.
For Londiste, each row change creates one event row in the queue table using special
triggers. Triggers are placed automatically on each database table by the Londiste commands.
Londiste uses almost identical triggers to Slony, and so shares many of the characteristics of
that project; they are both offer
trigger-based
replication
.
Changed rows are brought across to the subscriber in batches. The batches are defined on
the provider by the ticker as demanded by the subscriber, so if the ticker fails, then you will
get very large batches.
There are downsides to this form of replication. First, there is an overhead to triggers and
writing to queue tables, though this will vary from workload-to-workload, it is best to plan for
a 10 to 20% overhead. Second, queue tables take up space and RAM. Third, that you need to
take special administrative actions to add, change, or remove tables from the replication set.
The benefit of using Londiste is that it allows you to make a selective replica of your database.
Not all tables need to be copied.
There's more...
You can stop Londiste safely by using the following:
londiste.py clustname_londiste.ini --stop
or you can stop in an emergency using the following:
londiste.py clustname_londiste.ini --kill
If you want to change the configuration while server is online, you can reload the configuration
using the following:
londiste.py clustname_londiste.ini --reload
Check status using the following command:
SELECT queue_name, consumer_name, lag, last_seen
FROM pgq.get_consumer_info();
The
lag
column helps monitor the replication delay.
