1.1

Configuring for Consistency and Redundancy
To ensure high availability and reliable delivery of DML events, configure each gateway sender for both
persistence and redundancy. For performance reasons, deploy no more than one secondary gateway sender
(redundancy of one).
If a peer or server joins an existing WAN-enabled distributed system, then WAN components, such as gateway
senders and gateway receivers, are automatically created as part of DDL replay. This replay is subject to each
new SQLFire member satisfying the criteria of the server group. For example, if you deploy a gateway receiver
to a particular server group, and you later add a member to that server group, the receiver will be created on the
new member as well.
Possible Side Effect of Failover Process
A side effect of the gateway sender failover process is that a DML operation may be reapplied to the remote
WAN site if the primary sender fails. If the member that hosts the primary sender fails while sending a batch of
operations, some DML statements in the batch may have already been applied to the remote WAN site. After a
failover, the new primary sender sends the failed batch in its entirety, and reapplies the initial DML operations.
Because of this, the remote WAN site may become out-of-synch depending upon the nature of the DML operation;
how the DML modifies table columns; and the presence or absence of column constraints on the target table.
For example, consider the following update statement:
update trade.networth set availloan=availloan-? where cid = ? and tid= ?
If a failure occurs mid-way through applying this DML statement, reapplying the statement decreases the
"availloan" value twice in rows that applied the update before the failure.
Limitations of Multi-Site Replication
The vFabric SQLFire multi-site implementation has the following limitations and restrictions.
• Only SQL insert, update, and delete operations are distributed using configured gateway senders. Queries and
DDL operations are not distributed to remote SQLFire systems.
• Table expiration actions are not distributed to remote SQLFire systems.
• SQLFire does not extend transaction boundaries to remote systems that are configured for WAN replication.
If you use a transaction to update a table that is configured for WAN replication, the transaction is only honored
within the local SQLFire cluster where you initiated the transaction. Any DML operations that are replicated
to a remote table are applied outside of a transaction
• SQLFire provides no conflict detection to address simultaneous updates to table data on multiple SQLFire
systems. If multiple sites in a WAN configuration update the same table data at the same time, then the table
data can become inconsistent between sites.
For example, consider a situation where two SQLFire sites replicate the table "employees" to each other over
a WAN, and the employees data is currently consistent between both sites. Site 1 executes the DML operation:
update employees set bonus = bonus + 500 where department = 'sales'
At the same time, Site 2 executes the DML operation, moving the employee with ID 12345 from the Sales
department to the QA department:
update employees set department = 'qa' where employee_id = '12345'
In this case the DML is successfully applied to each SQLFire site and propagated to the other. However, in
Site 1, the employees row for employee_id 12345 has a higher bonus value than the same row in Site 2.
Similar problems can occur if each site tries to add a row using the same primary key, if one site deletes a
parent row required by an insert on the other site, and so forth.
To avoid these kinds of inconsistencies, enable WAN replication only for tables that do not require simultaneous
updates of the data on different SQLFire systems.
vFabric SQLFire User's Guide230
Deploying vFabric SQLFire