About Gateways

A multi-site installation consists of two or more distributed systems. Each site is its own distributed system and has one or more logical connections to other sites, called gateways.

Configuration Diagrams

In a simple multi-site deployment, two SQLFire clusters replicate DML operations to each other. If one of the SQLFire clusters fails or is taken offline for maintenance, clients in that geographical region can use the available SQLFire cluster for continued access.
Figure 1. Basic WAN replication configuration

More complex multi-site configurations can add additional SQLFire clusters to the basic configuration shown above. As additional clusters are added, each individual cluster in the deployment requires an additional gateway sender to ensure that each site replicates to all other sites across the WAN. (See Supported and Unsupported Topologies)

For example, the following figure shows three-site WAN configuration. Each cluster uses two gateway senders to replicate DML operations to the other clusters in the system.
Figure 2. WAN configuration with multiple gateway senders

Gateway Configuration Overview

The logical connections between distinct SQLFire clusters are known as gateways. Gateways are configured in one or more SQLFire data store members and consist of two physical connections: a gateway sender and a gateway receiver.

A gateway receiver provides a physical connection for receiving DML operations from one or more remote SQLFire clusters for replicating those operations in the local cluster. Each SQLFire cluster needs only a single named gateway receiver to replicate data from all other remote sites. Remote gateway senders use any available gateway receiver to send DML operations. However, you can deploy a gateway receiver to multiple SQLFire members for high availability.

A gateway sender runs on a SQLFire data store members, and it replicates configured table DML operations to another SQLFire distributed system. Each sender is usually hosted by more than one data store member, with one member hosting the primary gateway sender instance and the others hosting backup instances. The primary is the only instance that communicates with remote sites at a given time. Gateway senders are identified within the distributed system by a unique identifier.

Each gateway sender defines:
  • A unique identifier
  • The remote distributed system ID where the sender forwards DML operations.
  • The server group(s) on which to deploy gateway sender instances.
  • Optional variables to control the connection, persistence, and startup behavior for the sender and its queue.

Notice that each gateway sender only specifies the remote distributed system ID to use for replicating DML operations. The actual connection information (the host and port number of a gateway receiver in the remote distribute system) are obtained dynamically from the cluster locators. Locators automatically update this information as gateway receivers in remote sites change or go offline.

How Gateway Sender Startup Policy Affects Startup Behavior

This applies to systems where a gateway sender is installed to multiple data store members. When a gateway sender is deployed to multiple data stores, only one primary sender is active at any given time. All other gateway sender instances are secondaries that act as backups to the primary.

SQLFire designates the first gateway sender to start up as the primary sender, and all other senders become secondaries. As gateway senders are started and shut-down in the distributed system, SQLFire ensures that the oldest running gateway sender operates as the primary.