CREATE LOGICALLY REPLICATED

On this page

The CREATE LOGICALLY REPLICATED statement starts logical data replication (LDR) on a table(s) that runs between a source and destination cluster in an active-active setup. CREATE LOGICALLY REPLICATED creates the new table on the destination cluster automatically and conducts a fast, offline initial scan. It accepts unidirectional or bidirectional on as an option to create either one of the setups automatically.

Once the offline initial scan completes, the new table will come online and is ready to serve queries. In a bidirectional setup, the second LDR stream will also initialize after the offline initial scan completes.

This page is a reference for the CREATE LOGICALLY REPLICATED SQL statement, which includes information on its parameters and options. For a step-by-step guide to set up LDR, refer to the Set Up Logical Data Replication page.

Required privileges

New in v25.2: Users need the following privileges to create an LDR stream with CREATE LOGICALLY REPLICATED:

• Source connection string user: Needs the REPLICATIONSOURCE privilege on the source table(s). This is the user specified in the source connection string in unidirectional or bidirectional streams.
• User starting the LDR stream on the destination: Must have CREATE on the destination database and be the same user that is specified in the destination connection string for a bidirectional stream. The destination table will be created and the user given the REPLICATIONDEST privilege on the new table automatically.
• For reverse (bidirectional) setup: The original source user must have REPLICATIONDEST on the tables in the original source cluster.

LDR from cluster A to B represents a unidirectional setup from a source to a destination cluster. LDR from cluster B to A is the reverse stream for a bidirectional setup:

For example, the user maxroach will run the following statement to start LDR on the destination cluster:

CREATE LOGICALLY REPLICATED TABLE B.table FROM TABLE A.table ON 'A_connection_string/user=samroach' WITH BIDIRECTIONAL ON 'B_connection_string/user=maxroach;

To start LDR successfully with this statement:

• maxroach requires CREATE on database B, implicitly gets REPLICATIONDEST and REPLICATIONSOURCE on B.table.
• samroach requires REPLICATIONSOURCE and REPLICATIONDEST on A.table.
• maxroach must be the user in the BIDIRECTIONAL ON connection string.

Grant the privilege at the table or system level with the GRANT statement to a user or a role:

GRANT REPLICATIONSOURCE ON TABLE database.public.tablename TO user/role;

Synopsis

Parameters

Options

LDR modes

Modes determine how LDR replicates the data to the destination cluster. There are two modes:

• immediate (default): Attempts to replicate the changed row directly into the destination table, without re-running constraint validations. It does not support writing into tables with foreign key constraints.
• validated: Attempts to apply the write in a similar way to a user-run query, which would re-run all constraint validations relevant to the destination table(s). If the change violates foreign key dependencies, unique constraints, or other constraints, the row will be put in the dead letter queue (DLQ) instead. Like the SQL layer, validated mode does not recognize deletion tombstones. As a result, an update to the same key from cluster A will successfully apply on cluster B, even if that key was deleted on cluster B before the LDR job streamed the cluster A update to the key.

Examples

CREATE LOGICALLY REPLICATED will automatically create the specified source tables on the destination cluster. For unidirectional and bidirectional, run the statement to start LDR on the destination cluster that does not contain the tables.

Unidirectional

From the destination cluster of the LDR stream, run:

CREATE LOGICALLY REPLICATED TABLE {database.public.destination_table_name} FROM TABLE {database.public.source_table_name} ON 'external://source' WITH unidirectional, mode=validated;

Include the following:

• Fully qualified destination table name.
• Fully qualified source table name.
• External connection for the source cluster. For instructions on creating the external connection for LDR, refer to Set Up Logical Data Replication.
• unidirectional option.
• Any other options.

For details on managing schema changes, conflicts, and jobs when LDR is running, refer to the Manage Logical Data Replication page.

Bidirectional

Both clusters will act as a source and destination in bidirectional LDR setups. To start the LDR jobs, you must run this statement from the destination cluster that does not contain the tables:

CREATE LOGICALLY REPLICATED TABLE {database.public.destination_table_name} FROM TABLE {database.public.source_table_name} ON 'external://source' WITH bidirectional ON 'external://destination';

Include the following:

• Fully qualified destination table name.
• Fully qualified source table name.
• External connection for the source cluster. For instructions on creating the external connection for LDR, refer to Set Up Logical Data Replication.
• bidirectional on option defining the external connection for the destination cluster.
• Any other options.

For details on managing schema changes, conflicts, and jobs when LDR is running, refer to the Manage Logical Data Replication page.

Multiple tables

To include multiple tables in an LDR stream, add the fully qualified table names in a list format. Ensure that the table name in the source table list and destination table list are in the same order:

CREATE LOGICALLY REPLICATED TABLES ({database.public.destination_table_name_1}, {database.public.destination_table_name_2}) FROM TABLES ({database.public.source_table_name_1}, {database.public.source_table_name_2}) ON 'external://source' WITH bidirectional ON 'external://destination';

For details on managing schema changes, conflicts, and jobs when LDR is running, refer to the Manage Logical Data Replication page.

See more

• SHOW LOGICAL REPLICATION JOBS

Was this helpful?