Chapter 8. DDL Replication

Table of Contents
8.1. Statement specific DDL replication concerns
8.1.1. Not replicated DDL statements
8.1.2. Prohibited DDL statements
8.1.3. DDL statements with restrictions

BDR supports replicating changes to a database's schemas to other connected nodes. That makes it easier to make certain DDL changes without worrying about having to manually distribute the DDL change to all nodes and ensure they're consistent.

There is not currently an option to turn off DDL replication and apply DDL manually instead.

To safely manipulate the database schema in a asynchronous multimaster setup, all pending changes have to be replicated first. Otherwise it is possible that a row being replicated contains data for a row that has been dropped, or has no data for a row that is marked NOT NULL. More complex cases also exit. To handle that problem, BDR acquires a so called DDL lock the first time in a transaction schema changes are made.

Acquiring such a DDL locks requires contacting all nodes in a BDR group, asking them to replicate all pending changes, and prevent further changes from being made. Once all nodes are in that state, the originator of the DDL lock is free to perform schema changes.

This means that schema changes, in contrary to data changes, can only be performed while all configured nodes are reachable. If DDL has to be performed while a node is down, it has to be removed from the configuration (using bdr.bdr_part_by_node_names) first.

This also makes DDL a heavier weight operation than on standalone PostgreSQL. Performing DDL will cancel currently running transactions and stop new transactions from proceeding until replication has caught up and the DDL has been applied.