DDL replication filtering v5.6
See also DDL replication filtering.
bdr.replication_set_add_ddl_filter
This function adds a DDL filter to a replication set.
Any DDL that matches the given filter is replicated to any node that's subscribed to that set. This function also affects replication of PGD admin functions.
This function doesn't prevent execution of DDL on any node. It only alters whether DDL is replicated to other nodes. Suppose two nodes have a replication filter between them that excludes all index commands. Index commands can still be executed freely by directly connecting to each node and executing the desired DDL on that node.
The DDL filter can specify a command_tag
and role_name
to allow
replication of only some DDL statements. The command_tag
is the same as those
used by event triggers
for regular PostgreSQL commands. A typical example might be to create a
filter that prevents additional index commands on a logical standby from
being replicated to all other nodes.
You can filter the PGD admin functions used by using a tagname matching the
qualified function name. For example, bdr.replication_set_add_table
is the
command tag for the function of the same name. In this case, this tag allows all PGD
functions to be filtered using bdr.*
.
The role_name
is used for matching against the current role that's executing
the command. Both command_tag
and role_name
are evaluated as regular
expressions, which are case sensitive.
Synopsis
Parameters
set_name
— Name of the replication set. If NULL then the PGD group default replication set is used.ddl_filter_name
— Name of the DDL filter. This name must be unique across the whole PGD group.command_tag
— Regular expression for matching command tags. NULL means match everything.role_name
— Regular expression for matching role name. NULL means match all roles.base_relation_name
— Reserved for future use. Must be NULL.query_match
— Regular expression for matching the query. NULL means match all queries.exclusive
— If true, other matched filters aren't taken into consideration (that is, only the exclusive filter is applied). When multiple exclusive filters match, an error is thrown. This parameter is useful for routing specific commands to a specific replication set, while keeping the default replication through the main replication set.
Notes
This function uses the same replication mechanism as DDL
statements. This means
that the replication is affected by the DDL filters
configuration. This also means that replication of changes to DDL
filter configuration is affected by the existing DDL filter configuration.
The function takes a DDL
global lock.
This function is transactional. You can roll back the effects with the
ROLLBACK
of the transaction. The changes are visible to the current
transaction.
To view the defined replication filters, use the view bdr.ddl_replication
.
Examples
To include only PGD admin functions, define a filter like this:
To exclude everything except for index DDL:
To include all operations on tables and indexes but exclude all others, add two filters: one for tables and one for indexes. This example shows that multiple filters provide the union of all allowed DDL commands:
bdr.replication_set_remove_ddl_filter
This function removes the DDL filter from a replication set.
Replication of this command is affected by DDL replication configuration, including the DDL filtering settings.
Synopsis
Parameters
set_name
— Name of the replication set. If NULL then the PGD group default replication set is used.ddl_filter_name
— Name of the DDL filter to remove.
Notes
This function uses the same replication mechanism as DDL
statements. This
means that the replication is affected by the
DDL filters configuration.
This also means that replication of changes to the DDL filter configuration is
affected by the existing DDL filter configuration.
The function takes a DDL
global lock.
This function is transactional. You can roll back the effects with the
ROLLBACK
of the transaction. The changes are visible to the current
transaction.