Database server configuration

In a high availability cluster, secondary database servers are like mirror images of the primary database server. Instance-wide replication imposes some

requirements, such as the IDS version of the database server on the primary and secondary database servers must be identical. Similarly, at the database server configuration level, for the most part, configuration on both systems must be identical so that in the event of a primary server failure, the secondary server can be promoted to primary.

Note: Before installing the product, always check the IDS Machine Specific

Common configuration parameters

The following ONCONFIG parameters need to be identical on database servers involved in high availability replication:

򐂰 ROOTNAME 򐂰 ROOTOFFSET 򐂰 ROOTPATH 򐂰 ROOTSIZE 򐂰 PHYSDBS 򐂰 PHYSFILE 򐂰 LOGFILES 򐂰 LOGSIZE 򐂰 DYNAMIC_LOGS

When the primary server adds logical logs dynamically, that operation is logged in a logical log and automatically replicated to the secondary server. Although the DYNAMIC_LOGS value on the secondary server has no effect, keep

DYNAMIC_LOGS in sync with the value on the primary server, in case their roles switch.

Also, dbspaces and chunks need to be exactly the same down to the number of dbspaces and chunks, the pathnames, the size, and offsets.

Mirroring

You do not have to set the MIRROR parameter to the same value on the two database servers; you can enable mirroring on one database server and disable mirroring on the other. However, if you specify a mirror chunk for the root chunk of the primary database server, you must also specify a mirror chunk for the root chunk on the secondary database server. Therefore, the following ONCONFIG parameters must be set to the same value on both database servers:

򐂰 MIRROROFFSET

򐂰 MIRRORPATH

HDR configuration parameters

The following HDR configuration parameters must be set to the same value on both database servers in the replication pair:

򐂰 DRAUTO

򐂰 DRINTERVAL

򐂰 DRTIMEOUT

For more information about the HDR configuration parameters, refer to 3.3, “ONCONFIG parameters relevant to HDR” on page 50.

Index Page Logging

Index Page Logging must be enabled in order to use an RSS server. When an index is created, the Index Page Logging mechanism writes the index pages to the logical log for the purpose of synchronizing index creation between servers in high availability environments. Use the LOG_INDEX_BUILDS configuration parameter to enable or disable the Index Page Logging mechanism.

For more information about Index Page Logging, refer to 5.1.3, “Index Page Logging” on page 96.

SDS configuration parameters

The configuration parameters that affect the primary and SDS servers in a shared disk environment are:

򐂰 SDS_ENABLE

򐂰 SDS_TIMEOUT

򐂰 SDS_TEMPDBS

򐂰 SDS_PAGING

For more information about these parameters, refer to 6.2, “Configuration and setup” on page 122.

DataBlade modules

If you plan to use the user-defined types, user-defined routines, or DataBlade modules, then install them on both the primary and secondary database servers. Then register the user-defined types, user-defined routines, and DataBlade modules on the primary database server only. When you start HDR, the user-defined types, user-defined routines, or DataBlade modules are registered on the secondary database server.

Performance considerations

Many users appreciate the fact that the secondary server is not only a hot failover, but is also a read-only database for reporting purposes. So, the

secondary can be configured slightly different to handle the report type queries. For example, altering database configuration parameters, such as number of buffers and CPU VPs, can aid the reporting performance.

For even more improvement in performance, the logical and physical logs can be moved out to their own dbspaces. This is a common performance tuning practice and is highly recommended. If at all possible, put the logical and physical logs on separate controllers from the database data.

Determining the correct size of the logical log cannot only affect the overall performance of the database, but it also affects HDR.

When the logical log buffer on the primary database server is flushed from memory to disk, an entry is put into a HDR buffer, which is part of the virtual shared memory. It is important to note that the HDR buffer is always the same size as the logical-log buffers.

Therefore, it is important to give close attention to the size of the logical log buffer and how many logical logs are configured. Creating a logical log buffer that is too large could affect the checkpoint duration on both the primary and secondary. Coupling the large logical log with buffered database logging could also impact performance. Tips on estimating the size of the logical log buffer can be found in the IBM Informix Dynamic Server Administrator’s Guide, G229-6359.

Similarly, when RSS and SDS servers are configured in a high availability environment, there will be additional sets of replication buffers allocated on the primary server for each RSS and SDS server defined, and they will be of same size as logical-log buffers.

When Enterprise Replication is running on an HDR pair, some operations cannot be performed until the logs are shipped to the secondary server. This delay prevents possible inconsistency within the Enterprise Replication domain during an HDR switch-over to a secondary server. Consequently, there is a slight increase in replication latency when Enterprise Replication is used with HDR. You can control this latency increase by setting the DRINTERVAL configuration parameter to a low value.

Alternatively, using SDS servers instead of HDR can decrease replication latency.