1.1.1

Table Of Contents
visibility to the cluster is lost, then those clients can fail over to any other cluster that replicates data using a
gateway. A multi-site deployment requires a vFabric SQLFire Enterprise license for each data host in each site.
How Multi-site Systems Work
Each distributed system in a multi-site conguration operates independently of the other connected systems.
Each system can be congured as necessary for the resources available at the local site, as well as the local
topology (peer-to-peer and/or client-server).
However, tables that are congured for replication between sites must be created using identical table names
and column denitions. In addition, gateway senders and receivers must be congured to assign logical gateway
connections to physical network connections in each system.
For each table that is congured to use a gateway sender, DML events are automatically forwarded to the gateway
sender for distribution to other sites. The events are placed in a gateway queue and distributed asynchronously
to remote sites. The ordering of events sent between sites is preserved. The following types of DML operations
are distributed:
inserts
updates
deletes (except for data deletion associated with table expiration).
Other operations are not distributed, such as:
Queries against the table
DDL operations of any kind
Expiration actions of any kind
Transaction boundaries that involve the congured table
If the queue of DML events becomes too full, it is overowed to a disk store to keep the member from running
out of memory. Optionally, you can congure the queue to be persisted to disk. With persistence, if the member
that manages the queue goes down, the member picks up where it left off after it is restarted.
How Multi-site Event Distribution Works
In a multi-site conguration, vFabric SQLFire distributes table DML operations between remote distributed
systems, with a minimum impact on each system's performance. DML events are distributed only for the tables
that you congure for replication by using a gateway receiver.
The DML event contains the originating site's distributed system ID, and the ID of each site to which it sends
the event. This information ensures that no site re-forwards the event to a site that has already received the event.
When a SQLFire site receives an event for a table DML operation, it forwards the event to the other sites it
knows about (sites that correspond to congured gateway senders for the table), but it excludes those sites that
it knows have already received the event for the table.
Note: A DML event does not record the ID of the sites that receive and apply the DML event. This means
that unsupported WAN topologies can result in more than one copy of an event being applied to a single
site. This can lead to duplicate data or failed DML execution in the table, and must be avoided. See the
discussion of supported and unsupported topologies under Supported and Unsupported Topologies on
page 219.
How a Gateway Processes Its Queue on page 218
How a Gateway Handles Batch Processing Failure on page 219
How a Gateway Processes Its Queue
Each primary gateway sender contains a processor thread that reads messages from its queue, batches them, and
distributes them to the connected site. To process the queue, the thread takes the following actions:
vFabric SQLFire User's Guide218
Deploying vFabric SQLFire