Database Reference
In-Depth Information
After a transaction commits on the Master, the time taken to transfer data changes are sent
from Master to Standby is important, and is usually referred to as the latency, or replication
delay. Replication delay is best measured as a time (in seconds). Changes must then be
applied to the Standby, which takes an amount of time known as the apply delay. Data
changes are often sent in batches. Increasing batch size may increase transfer efficiency,
though will also increase replication delay, and also the apply delay of the data changes
towards the end of the batch. The total time a record takes from Master to Standby is the
replication delay plus the apply delay. Be careful to note that some authors describe those
times differently, and sometimes confuse the two, which is easy to do. In some cases,
you may see the apply delay expressed in terms of the total volume of changes currently
outstanding, expressed in bytes (usually MB). Please note that the throughput, or rate of data
transfer, measured in MBs, is interesting, but not the same thing as the latency or replication
delay, though may often be loosely related.
If data changes are acknowledged as sent from Master to Standby before transaction commit
is acknowledged, we refer to that as synchronous replication. If data changes are sent after a
transaction commits, we name that asynchronous replication. With synchronous replication,
the replication delay directly affects performance on the Master. With asynchronous
replication the Master may continue at full speed, though this opens up a possible risk that
the Standby may not be able to keep pace with the Master. All asynchronous replication must
be monitored to ensure that a significant lag does not develop, which is why we must be
careful to monitor the replication delay.
All forms of Single-Master replication are initialized in roughly the same way. First, you enable
change capture, and then make a full replica of the data set onto the Standby. After that, we
begin applying the changes. As a result, the replication delay immediately following the initial
copy task will be equal to the duration of the initial copy task. The Standby will then begin to
catch-up with the Master, and the replication delay will begin to get smaller. This is known
as the catch up period. If the Master is busy, it will continue to produce many new changes,
and that can lengthen the time it takes the Standby to catch up. Note that in some cases, the
catch-up period will be too long to be acceptable. Be sure to include this understanding in
your planning and monitoring. Replication tuning may often be different during the catch-up
period from the tuning you may need during normal running.
Replication will either copy all tables, or in some cases, we can copy a subset of tables, in
which case we call this selective replication. When using selective replication we can group
selected objects together into a replication set. If you choose selective replication, you should
note that the management overhead increases as the number of objects managed increases.
Additional administration time should be planned, especially if more than a few hundred
objects are being managed.
