Seeding a Replica

This section explains how to seed a new replica by restoring the target database from a full backup of the source database, then starting replication from that backup point. In some cases, this approach may be preferable to starting replication on an empty database.

When to Seed a Replica

Seeding a replica is a matter of choice. Consider the performance of the link between the two appliances. If the initial replication cycle is going to be time-consuming given the bandwidth requirements, it is probably more effective to back up the database to a NAS system, then ship the NAS to the other data center and restore from that backup.

Note the following recommendations.
  • Do not seed the replica:
    • If both systems are empty or mostly empty.
    • When the source system contains a small amount of data and the link between the appliances provides good performance.
  • Seed the replica when:
    • The source system contains a large amount of data but the average amount of change in the data is fairly small.
    • The source system has been running with Version 4.0 backup and restore for some time and you have one or more other appliances available for replication purposes.

    Note that if you are going to seed the replica, in some cases you may want to take a new full backup of the source database. Seeding the replica from a new full backup may be more efficient than seeding from a long sequence of backup points that have to be replayed in order.

Procedure for Seeding a Replica

To seed a replica from a backup of the source database, follow these steps:
  1. Take a full backup of the source database on the primary system. For example:
    $ ybbackup -W --username yb100 -d premdb --full --name Feb13Full --chain February2020 /home/yb100/premdb_daily_backups
  2. Create the target database automatically in HOT_STANDBY mode by adding a replica to the source database. For example:
    premdb=# alter database premdb add replica premdb_replica to yblocal 
    with (alias premdb_replicated, frequency 60, security_mode 'all');

    Do not start the replica yet.

  3. Restore the source database to the secondary system, using a backup point and chain name that correspond to the values you specified in the ybbackup command. For example:
    $ ybrestore -W --username yb100 -d premdb_replicated --point Feb13Full --chain February2020 /home/yb100/premdb_daily_backups --security-mode all
    Important: Also note the following requirements:
    • The -d database name must correspond to the database that will be the target for replication (as specified with the ALIAS option in the ADD REPLICA command).
    • The security mode for the restore must match the security mode for the replica. In this example, --security-mode all was specified in the ybrestore command, which matches the setting specified for the replica. If the security modes do not match, subsequent attempts to replicate will fail with an error.
    • Any schemas excluded from the backup chain used to seed the replica must match those excluded from the replica. For example, you cannot exclude schema1 from the backups used for the restore, then exclude schema2 when you create the replica.
    • Make sure that the restore runs against the secondary system (for example, by setting YBHOST).
    • Make sure that the secondary system has access to the backup directory. (If the backup files need to be moved, you may need to use the ybbackupctl command with the --fix-bundle-paths option.)
  4. Get the chain name for the backup you restored from the sys.backup_chain view. This chain name must refer to the backup (or sequence of backups) that you restored to the secondary appliance. Run this query from the source database on the primary system. For example:
    premdb=# select * from sys.backup_chain;
     database_id |  chain_name  | policy | oldest_backup_point_id | oldest_rollback_point_id |         created_time          
           20309 | February2020 | {}     | Feb13Full              | [NULL]                   | 2020-02-13 18:41:25.927609-08
    (1 row)
  5. Start replication from the source system by using the START WITH CHAIN syntax. For example:
    premdb=# alter database premdb alter replica premdb_replica 
    start with chain 'February2020';
  6. Monitor replication in the usual way via the SMC or by querying the system views. Check that the initial replication cycles only replicate changes made after the target database was restored.