HDR and applications

It is important to realize that from an application perspective there is no

difference between a primary and a secondary HDR instance other than that one is read-only. If permitted by the business (because of licensing reasons), and depending on the log transfer mode used, a smart programmer will use both instances to the benefit of the application. Applications could be written such that updates and modifications occur at the primary instance while report functions or applications are directed to the secondary instance. This could be accomplished through hard coding the instance names into the application, or, preferably, changing the environment on which the application operates.

How current the data is on the secondary instance depends on DRINTERVAL. If set to asynchronous mode, the data on the secondary server will not be an exact duplicate of the primary’s data at any moment in time. This may not be important if, for example, the time range for the report does not conflict with the replication interval.

So how can an application be directed to connect to one instance or another, and if HDR is used, can an application automatically reconnect to the secondary instance if the primary experiences a failure?

As should be well understood, application connectivity is determined by a series of parameters or environmental variables. These include $INFORMIXSERVER, DBPATH, and the SQLHOSTS GROUP option, as well as the connect SQL statement. Of these, the SQLHOSTS GROUP option is the newest and probably the least well known.

The most common method for directing an application to an instance is through the connect SQL statement. While it can contain the syntax of connect to database_name@instance_name, it typically only holds the database name relying on $INFORMIXSERVER to point to the correct instance. Some application languages may allow this to be treated through a variable passed in from the command line, but for the most part this statement is hard-coded into the application, requiring modification and recompiling for any change to take effect. This is hardly a seamless change from a user perspective if it must be switched during an HDR failure. For this reason, most applications only declare the database name in the statement and use INFORMIXSERVER to find the correct instance.

The INFORMIXSERVER parameter can either contain a single instance name

or

a server GROUP, as we explain shortly. In theory, if one instance is unavailable, all that is required is to reset the value of this parameter to find the new instance. Unfortunately, the value of INFORMIXSERVER is only read when the application is started, so applications must be restarted to recognize a change. This is not a seamless change from a user perspective, but it can work, and many sites use this approach.

If INFORMIXSERVER is not defined,

or the instance defined in

INFORMIXSERVER is not available

, the application will look for and use the list of instances in the DBPATH environment parameter. This permits the first of two methods of more seamlessly switching application connectivity in the event of failure. For this to occur, INFORMIXSERVER is populated with the primary instance name while DBPATH is configured with the secondary instance. In the event of an HDR failure, the application will attempt to reach the

INFORMIXSERVER instance. If it does not respond, the application will then attempt to connect to the DBPATH instance. With this approach, the application does not need to be recompiled or restarted. Transactions that were in-flight, however, will need to be restarted since the newly promoted primary does not have any of the shared memory buffer or transaction state information that existed on the original primary instance.

Using server groups

Created for Enterprise Replication connections, a group of one or more

instances can be defined within the SQLHOSTS file. ER connectivity is based on these groups, but the groups can also be used for HDR. Figure 3-1 illustrates the concept behind a server group; Table 3-2 shows the creation of a server group.

Figure 3-1 Conceptual illustration of a server group

In Figure 3-1, both the primary and secondary instances are to be configured as one logical instance named g_serv1. This is accomplished through entries in the client and server SQLHOSTS files as shown in Table 3-2. In this case, the primary instance file is shown.

Table 3-2 An SQLHOSTS file with server groups

In practical terms, an application could use any of these instance definitions as its INFORMIXSERVER – serv1 for read/write access, serv1_sec for read-only access, as well as their shared memory or regular network-based

DBSERVERALIAS. From a failover perspective though, if g_serv1 is used, the Informix connectivity libraries will direct an instance connection to the first instance defined in the group and if not found or unresponsive, will then attempt to connect to the next instance defined as part of the group. The application does not need to be recompiled nor restarted. Transactions that were in-flight will need to be restarted since the newly promoted primary does not have any of the shared memory buffer information.

DBSERVERNAME NETTYPE HOSTNAME SERVICE NAME

Options

g_serv1 group - - i=100

serv1 onsoctcp sys1 serv1_tcp g=g_serv1

serv1_sec onsoctcp sys2 serv1_sec_tcp g=g_serv1

serv1_shm onipcshm sys1 placeholder

serv1sec_net onsoctcp sys2 serv1secnet

serv1

serv1_sec

HDR

In document Informix Dynamic Server V10: (Page 47-51)