Skip to Content

rss

Informix: Delayed Apply and External Backup on RSS Nodes

There is an excellent article on IBM developerworks that describes the Delayed Apply feature of RSS nodes in a MACH11 cluster.

The article also describes how to take advantage of RSS nodes in order to perform external backups without blocking the primary server:

What's new in Informix MACH 11 high-availability features for secondary servers

IBM Blue Blog: Transaktionen und "Undo"-Funktion ?

(german content)

IBM Deutschland betreibt einen sogenannten IBM Blue Blog, der sich mit diversen Themen rund um die IBM Produktpalette befasst.

Martin Fürderer - IBM Informix Entwicklung München - bloggt dort auch zum Thema Informix.

Webcast - MACH11 best practices around HDR/RSS


  • Date: Thursday, Nov the 18th
  • Time: 1.5 hour, 8:30 AM Pacific, 10:30 AM Central, 11:30 AM Eastern, 4:30 PM London, 5:30 PM Paris
  • Title: MACH11 best practices around HDR/RSS
  • Speaker: Madhuri, Madison Pruet (IBM)

You can register for the webcast here...

Jerry Keesee, Director of the Informix Lab will introduce the call 
and Madison Pruet, Informix STSM will be our technical speaker.

RSS Server Latency for Disaster Recovery

In case you haven't seen it already, here is the link to an excellent article from Mr. Replication - Madison Pruet - about the new RSS Delayed Apply feature available in IDS 11.50.xC5:

MACH11: TEMPTAB_NOLOG

MACH11: TEMPTAB_NOLOG

In IDS V11.1 there has been a new onconfig parameter introduced: TEMPTAB_NOLOG

The purpose of this parameter is:

  • Allowing the creation of unlogged temporary tables on secondary servers (SDS,HDR,RSS) without the need to explicitly add the with no log extension
  • Increasing performance for operations on temporary tables on the primary (PRI) as statements against them will not be logged and hence not transfered to a secondary server

Let's have a deeper look at this technique. In the following example we have a primary server and a secondary HDR server. I leave SDS and RSS secondary servers out, as they show exactly the same behaviour as a HDR secondary regarding the TEMPTAB_NOLOG parameter. The dbspace layout looks like this:

MACH11: HA_ALIAS

MACH11: HA_ALIAS

In IDS V11.5 there is a new onconfig parameter: HA_ALIAS

HA_ALIAS specifies the IDS servername that a SDS- or RSS-Node will send to the PRIMARY when it registers itself in a MACH-Cluster. The specified HA_ALIAS name must be one of the configured DBSERVERNAME or DBSERVERALIASES servernames that belongs to a TCP based connection type. It will be used in case of failover. If HA_ALIAS isn't set, the value of the DBSERVERNAME acts as the default and will be send to the PRIMARY.

HA_ALIAS is particulary useful in configurations where the DBSERVERNAME onconfig parameter is based on a local connection protocol like onipcshm (shared memory) or onipcstr (stream pipe). In order for such instances to be able to participate as a secondary SDS- or RSS-Node in a MACH-Cluster, HA_ALIAS must be set to a configured DBSERVERALIASES name that belongs to a TCP based connection type.

MACH11: FAILOVER_CALLBACK

MACH11: FAILOVER_CALLBACK

In IDS V11.5 there is a new onconfig parameter: FAILOVER_CALLBACK

It is allows you to customize the automatic failover capability of the Connection Manager in some way. FAILOVER_CALLBACK should be set to the full path of your own script. IDS will execute the specified script on a secondary server when:

  • the secondary server is promoted to a primary server
  • the secondary server is promoted to a standard server

This means that FAILOVER_CALLBACK can be used in conjunction with HDR (DRAUTO) as well as with the Connection Manager FOC (FailOver Configuration) capability.

Syndicate content
Copyright