Description
Causes a node (subscriber) to start replicating a set of
tables either from the origin or from another provider node, which
must itself already be be an active, forwarding subscriber.
The application tables contained in the set must already
exist and should ideally be empty. The current version of
edb-async-replic will not
attempt to copy the schema of the set. The replication daemon will
start copying the current content of the set from the given
provider and then try to catch up with any update activity that
happened during that copy process. After successful subscription,
the tables are guarded on the subscriber, using triggers, against
accidental updates by the application.
If the tables on the subscriber are not empty, then
the COPY SET process winds up doing more work than should be
strictly necessary:
It deletes all "old" entries in
the table
Those old entries
clutter up the table until it is next
VACUUMed after the
subscription process is complete
The indices for the table will contain entries
for the old, deleted entries, which will slow the process of
inserting new entries into the index.
Note: If you need to revise subscription information for a
node, you also submit the new information
using this command, and the new configuration will be propagated
throughout the replication network. The normal reason to revise
this information is that you want a node to subscribe to a
different provider node, or for a node to
become a "forwarding" subscriber so it may later
become the provider for a later subscriber.
- ID = ival
ID of the set to subscribe
- PROVIDER = ival
Node ID of the data provider from which this
node draws data.
- RECEIVER = ival
Node ID of the new subscriber
- FORWARD = boolean
Flag whether or not the new subscriber should
store the log information during replication to make it
possible candidate for the provider role for future
nodes.
Example
SUBSCRIBE SET (
ID = 1,
PROVIDER = 1,
RECEIVER = 3,
FORWARD = YES
);
