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
- Stop all table DML operations on all GemFire XD distributed systems that host the
- 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.
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.
- After the table schema has been updated on all GemFire XD distributed systems,
resume DML operations against the table.
- 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
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.