Three SQL Anywhere servers are required to provide high-availability: an arbiter and two partner servers. One partner is assigned the role of the primary and the other is the mirror. Write operations, such as an insert to a global table, are only permitted on the primary, while read operations, such as a select, are permitted on both types of servers. The primary automatically keeps its mirror synchronized as it receives updates. In the event of a failure on the primary, the arbiter switches the roles of the partners such that the mirror becomes the primary.

High availability may be leveraged within a web service environment by routing all HTTP requests through a Relay Server. The Relay Server processes the URL of the HTTP request to derive the target server farm. For simplicity, consider a Relay Server configuration that routes HTTP requests to either a readFarm or a writeFarm. Although the primary back-end server may process both read and write requests, you can configure it to process write requests only if there are other read-only copy nodes to cover the read functionality in case of server failure; otherwise, you can configure it to process both read and write requests. However, you may configure the mirror server to process read requests to spread the read load, or it can be configured not to process any requests to reduce hardware use on the mirror server. The client application requires no knowledge of the physical server that it will access for read and write requests; it simply composes its URL to direct the request to either the readFarm or the writeFarm.

In addition to the Relay Server, each of the partnered back-end servers requires two Outbound Enablers, one for each farm the back-end server participates in. Two Outbound Enablers control the communication channels to the primary partner and two Outbound Enablers establish communications with the mirror partner. Within this configuration, at any instant in time there is only one primary server and it activates its Outbound Enabler assigned to the writeFarm, and optionally deactivates its Outbound Enabler associated with the readFarm if there are other members in the readFarm, other than the copy nodes. The mirror deactivates its Outbound Enabler associated with the writeFarm and optionally activates its Outbound Enabler associated with the readFarm.

If the primary server becomes unavailable because of hardware or software failure, the mirror server negotiates with the arbiter to assume the role of primary server, and thus become a member of the writeFarm. It should also become a member of the readFarm if the system has no other read-only copy nodes. At the time of failure, the original primary is abruptly withdrawn from both the writeFarm and the readFarm if it is a member. The original primary server may not recover until the cause of the failure has been resolved. When it recovers, it assumes the mirror role, and optionally joins the readFarm. The abrupt failure may fail requests currently being processed by the failing server. The latency of writeFarm recovery from the mirror depends on the role-switch latency of the SQL Anywhere mirror plus the status polling interval specified on the writeFarm Outbound Enabler of the mirror. This status polling interval can be set and its default is 5 seconds if not explicitly specified.

A minimum of two SQL Anywhere servers are required to provide scale-out capability: a root node and a copy node. A copy node, like a mirror server, is read-only, but it differs in that it can never assume the primary role. It is strictly intended to service read requests. As discussed in the high availability scenario, the primary is associated with the writeFarm and the copy node replaces the mirror server as the readFarm member. With one root node and a single copy node, only two Outbound Enablers are required in total, one for each server. Optionally, you may add the primary to the readFarm so that your environment remains fully functional when all the copy nodes are down. The Outbound Enabler associated with the root node is configured to receive requests to the writeFarm while the copy node's Outbound Enabler is configured to accept requests to the readFarm. The root node continually updates its copy node as it receives write updates. The configuration can be expanded by adding copy nodes to the readFarm. Running 10 copy nodes to the readFarm provides load balancing and mitigates server failures incurred within the readFarm.

The above configuration scenarios may be combined to provide both high-availability and scale-out. Such a configuration would provide fault tolerance for writable (primary/mirror) and readable (mirror and copy) back-end servers. In addition, adding more copy nodes increases the throughput potential for HTTP read-only requests. In this configuration, the primary and mirror server make up the root node, and the primary, the mirror, and the copy nodes all have one Outbound Enabler for participation in the readFarm. The primary and mirror have one additional Outbound Enabler for participation in the writeFarm. Optionally, you can remove the primary and mirror from the readFarm.

For the purposes of this discussion, an Outbound Enabler must be configured to identify the following:

In the following command the Outbound Enabler sets up a connection to the Relay Server based on parameters provided by the -cr option. If it is active, the Relay Server forwards requests made to the readFarm to the backend server configured according to the -cs option.

rsoe.exe -f readFarm -id saHost1 -cr url_suffix="/ias_relay_server/server/rs_server.dll";host=rs_server;port=80 -cs host=sahost1;port=8080;status_url=/satest/oe_read_status?ro=1

Based on the above example, a request URL of the form http://rs_server/ias_relay_server/client/rs_client.dll/readFarm/service_path[?service_query]

directs the request to the Relay Server hosted on rs_server. The Relay Server strips off the domain and farm components from the URL and relays the request to an active Outbound Enabler associated with the farm, over the RS-OE channel. The Outbound Enabler then forwards the request to its backend server.

An Outbound Enabler maintains a channel to the Relay Server only if it detects that the backend server is ready to process requests. It does this by polling the server at a configurable interval, sending an HTTP request specified by the -cs option. The status_url option provides the specific URL path for the ping service. In the example configuration above, the Outbound Enabler sends HTTP requests to http://sahost1:8080/satest/oe_read_status?ro=1. If the server responds with AVAILABLE=TRUE | ON | 1 then the Outbound Enabler maintains or initiates a communication channel with the Relay Server hosted on rs_server.

For information about how to configure and start SQL Anywhere as a web server, see SQL Anywhere as an HTTP web server.

Leveraging the rsoe (Relay Server outbound Enabler) startup example discussed in the Outbound Enabler configuration section, an oe_read_status service may be written as follows:

// READ-ONLY SA-OE ping service
//  optionally includes primary as a READ node.
call sa_make_object( 'service', 'oe_read_status' );
alter service oe_read_status
    type 'raw'
    authorization off
    secure off
    user DBA
    as call sp_oe_read_status(:ro);

// if ro is 1 then only read-only servers are activated: mirror or copy
// if ro is 0 then include all servers: primary, mirror, copy...
create or replace procedure sp_oe_read_status( ro int )
begin
    declare readonly long varchar;
    declare res long varchar;

    set res = 'AVAILABLE=';

    set ro = isnull(ro, 0);
    if ro = 1 then
         select db_property('ReadOnly') into readonly;
          if readonly = 'On' then
               set res = res || 'TRUE';
          else
               set res = res || 'FALSE';
           end if;
    end if;;

    call sa_set_http_header('Content-Length', length(res) );
    select res;
end;

The above web service and stored procedure could be used for any SQL Anywhere server that has the role of a primary, mirror, or copy node. If the ReadOnly database property is set to On, then AVAILABLE=TRUE is returned. With minor modifications, a service for use within a writable server farm, for example writeFarm, would return AVAILABLE=TRUE only when ReadOnly is set to Off. Optionally, a ping service for an Outbound Enabler may base its AVAILABILITY on other factors such as an entry in a global table. For example, a staged deployment might update a table or procedure on the primary which, when propagated to the mirror and copy nodes, activates or deactivates each server's server farm membership.

To configure the Relay Server:

• Relay Server configuration file
• Relay Server farm configuration updates
• Backend farm section properties