Performance Considerations v6.2
This section discusses provides some general guidelines on performance considerations.
When to Use Snapshot or Synchronization
Generally, synchronization would be the quickest replication method since it only applies changes to the target tables since the last replication occurred.
However, if a large percentage of rows are changed between each replication, there may be a point where it would be faster to completely reload the target tables using a snapshot than to execute individual SQL statements on a large percentage of rows as would be done for synchronization replication. Experimentation may be necessary to determine if, and at what point a snapshot would be faster.
Snapshot replication may be an option for tables with the following characteristics:
- Tables are relatively small in size
- A large percentage of rows are changed between replications
Synchronization replication is the better option for tables with the following characteristics:
- Tables are large in size
- A small percentage of rows are changed between replications
In a single-master replication system, if you find that one group of tables consistently replicates faster using snapshot replication, then these tables can be made part of a snapshot-only publication while the remaining tables can be members of a publication that uses synchronization replication.
When to Use On Demand Replication
The xDB Replication Console and xDB Replication Server CLI both give you the capability to immediately start a replication. This is called an on demand replication.
On demand replication can be performed at any time regardless of whether or not there is an existing schedule. An on demand replication does not change the date and time when the next replication is scheduled to occur according to an existing schedule.
If a publication is a snapshot-only publication, then the only type of on demand replication that can be performed on this publication is a snapshot.
If a publication is not a snapshot-only publication, you can perform an on demand replication using either the snapshot method or the synchronization method.
When you are in the development and testing phases of your replication system, you would typically use on demand replication so that you can immediately force the replication to occur and analyze the results.
When your replication system is ready for production, a schedule would typically be used so that replications can occur unattended at regular time intervals. See Creating a Schedule for directions on creating a schedule.
There may be other situations where you would want to force a replication to take place ahead of its normal schedule. Reasons for performing an on demand replication may include the following:
- The number of changes to the source tables is growing at a faster rate than usual, and you do not want to wait for the regularly scheduled synchronization time to replicate all of the accumulated changes.
- You have set up your replication system to perform synchronizations, but on this occasion there have been an unusually large number of changes made to the source tables, and you would rather perform a snapshot of all source tables rather than execute a large number of SQL statements against the target tables.
- Changes have been made directly to the rows of the target tables so that they no longer have the same content as their source table counterparts. You can perform an on demand snapshot replication to reload all rows of the target tables from your current set of source tables.
Note
In a multi-master replication system, on demand snapshots can only be made from the primary definition node to another primary node.
See On Demand Replication for directions on performing an on demand replication for a single-master replication system. See On Demand Replication for a multi-master replication system.