Managing Schema Changes

The GemFire XD WAN replication and DBSynchronizer features are designed to keep tables having identical schemas in sync with one another. However, DDL operations such as ALTER TABLE are never propagated over a WAN or to a configured back-end database. If you need to change the schema of a table after configuring WAN or DBSynchronizer replication, use this procedure to avoid excessive synchronization failures.

Procedure

  1. Stop all table DML operations on all GemFire XD distributed systems that host the table.
  2. Apply the same ALTER TABLE command to modify the table schema on each GemFire XD distributed system. You will need to connect to each system to execute the ALTER TABLE command and verify that the schema has been modified.
    Note: The ALTER TABLE command flushes any asynchronous queues for the table before modifying the schema. This ensures that any pending operations against the old schema are written to the table before applying the schema change. If a remote WAN site or back-end database is unavailable for processing queued events, then GemFire XD may wait for 5 minutes or longer (up to the value of gemfirexd.max-lock-wait) before timing out. You can optionally use the SYS.WAIT_FOR_SENDER_QUEUE_FLUSH procedure to flush all queues before you execute the ALTER TABLE statement.
  3. After the table schema has been updated on all GemFire XD distributed systems, resume DML operations against the table.
  4. Verify that new updates are being propagated to the back-end database (for DBSynchronizer configurations) and/or propagated to remote GemFire XD clusters over the WAN.
Note: Executing DML operations against the table while you execute ALTER TABLE in the GemFire XD clusters can lead to synchronization errors and data inconsistency between copies of the table.