DDL change replication process v7

The DDL statement is executed in a controlled manner such that the target table is exclusively locked (by the default setting of configuration option ddlChangeTableLock) during the course of the operation. This is done to avoid loss of any transactions while the replication triggers and shadow table are modified by the DDL change replication process. Only one target table is locked at a time while DDL change replication takes place on that table, its triggers, and shadow table.

If there's a backlog of pending transactions, we recommend that you perform an explicit synchronization replication before performing DDL change replication. This approach avoids prolonging the DDL change replication process.

Perform DDL change replication when the OLTP rate is very low (near zero).

The following is the series of steps that occur during the DDL change replication process.

• The publication server performs a health check across all databases in the replication system to ensure you can access them. If any database is not available, the DDL change replication process stops and notifies you.
• If the publication server configuration option ddlChangeTableLock is set to its default value of true, an exclusive table lock is requested on the table to which the DDL change is to be applied. If another application already has a lock on the table, there's a wait time of two minutes. After that the DDL change replication process stops if the lock isn't released before then. If ddlChangeTableLock is set to false, an exclusive table lock isn't requested.
• The DDL statement is executed against the target table. The replication triggers and shadow table are modified accordingly. If an error occurs, you're notified and the operation stops. If ddlChangeTableLock is set to true, the exclusive lock is released.
• These two actions are repeated on the target table for each database in the replication system.
• The in-memory table metadata definition is refreshed to reflect the DDL change. You're notified when the operation completes successfully.
• If an error occurs during these steps, any changes up to that point are rolled back so that the publication table, replication triggers, and shadow table revert to their original state prior to the start of this operation. If one or more databases goes down before the operation finishes, the publication is marked as dirty to avoid further replication events.