Replication sets v4
A replication set is a group of tables that a BDR node can subscribe to. You can use replication sets to create more complex replication topologies than regular symmetric multi-master where each node is an exact copy of the other nodes.
Every BDR group creates a replication set with the same name as the group. This replication set is the default replication set, which is used for all user tables and DDL replication. All nodes are subscribed to it. In other words, by default all user tables are replicated between all nodes.
Using replication sets
You can create replication sets using create_replication_set()
,
specifying whether to include insert, update, delete, or truncate actions.
One option lets you add existing tables to the set, and
a second option defines whether to add tables when they are
created.
You can also manually define the tables to add or remove from a replication set.
Tables included in the replication set are maintained when the node joins the cluster and afterwards.
Once the node is joined, you can still remove tables from the replication set, but you must add new tables using a resync operation.
By default, a newly defined replication set doesn't replicate DDL or BDR
administration function calls. Use replication_set_add_ddl_filter
to define the commands to replicate.
BDR creates replication set definitions on all nodes. Each node can then be
defined to publish or subscribe to each replication set using
alter_node_replication_sets
.
You can use functions to alter these definitions later or to drop the replication set.
Note
Don't use the default replication set for selective replication. Don't drop or modify the default replication set on any of the BDR nodes in the cluster as it is also used by default for DDL replication and administration function calls.
Behavior of partitioned tables
BDR supports partitioned tables transparently, meaning that you can add a partitioned table to a replication set. Changes that involve any of the partitions are replicated downstream.
Note
When partitions are replicated through a partitioned table, the
statements executed directly on a partition are replicated as they
were executed on the parent table. The exception is the TRUNCATE
command,
which always replicates with the list of affected tables or partitions.
You can add individual partitions to the replication set, in which case they are replicated like regular tables (to the table of the same name as the partition on the downstream). This has some performance advantages if the partitioning definition is the same on both provider and subscriber, as the partitioning logic doesn't have to be executed.
Note
If a root partitioned table is part of any replication set, memberships of individual partitions are ignored. only the membership of that root table is taken into account.
Behavior with foreign keys
A foreign key constraint ensures that each row in the referencing table matches a row in the referenced table. Therefore, if the referencing table is a member of a replication set, the referenced table must also be a member of the same replication set.
The current version of BDR doesn't automatically check for or enforce this condition. When adding a table to a replication set, the database administrator must make sure that all the tables referenced by foreign keys are also added.
You can use the following query to list all the foreign keys and replication sets that don't satisfy this requirement. The referencing table is a member of the replication set, while the referenced table isn't:
The output of this query looks like the following:
This means that table t2
is a member of replication set s2
, but the
table referenced by the foreign key t2_x_fkey
isn't.
The TRUNCATE CASCADE
command takes into account the
replication set membership before replicating the command. For example:
This becomes a TRUNCATE
without cascade on all the tables that are
part of the replication set only:
Replication set management
Management of replication sets.
With the exception of bdr.alter_node_replication_sets
, the following
functions are considered to be DDL
. DDL replication and global locking
apply to them, if that's currently active. See DDL replication.
bdr.create_replication_set
This function creates a replication set.
Replication of this command is affected by DDL replication configuration including DDL filtering settings.
Synopsis
Parameters
set_name
— Name of the new replication set. Must be unique across the BDR group.replicate_insert
— Indicates whether to replicate inserts into tables in this replication set.replicate_update
— Indicates whether to replicate updates of tables in this replication set.replicate_delete
— Indicates whether to replicate deletes from tables in this replication set.replicate_truncate
— Indicates whether to replicate truncates of tables in this replication set.autoadd_tables
— Indicates whether to replicate newly created (future) tables to this replication setautoadd_existing