Please read the MACH 11 Overview section which contains links to useful information around the technology. Additionally it contains some general information about the MACH 11 Cluster whose setup is described in this Wiki as well as some links to popular virtualization software which allows you to create several virtual hosts on a single physical machine.

The RSS technology is based on the HDR technology that allows the replication of a complete instance (including all logged databases) to a standby instance. HDR only allows a single secondary server, where RSS allows the configuration of multiple secondary servers. The RSS instances runs in readonly mode and can be used to offload reporting and complex SQL queries from the primary instance. Starting with IDS V11.5, write access is also supported on the RSS instances. In case of a failure of the primary instance, the standby instance can not directly take over the work of the primary. It must be first promoted from a HDR secondary instance and then it could be promoted to a primary instance.

RSS is application neutral and is easy to configure and maintain. In the following article we will safeguard our penguin instance with a RSS instance named penguin_rss1.

RSS requires that you use the same hardware and operating systems on both boxes. Marginal differences regarding the OS patchlevel or the installed processors and memory are possible.

Also the IDS version has to be exactly the same on both systems. If you have the requirement to work with different IDS versions in an heterogeneous environment, consider the use of ER (Enterprise Replication).

RSS requires that exactly the same chunk pathnames are used on both machines. If you plan to setup the RSS instance on the same machine, which is only recommended for testing purposes , you need to work with relative chunk pathnames as described in the following blog entry from IDS architect Madison Pruet:

• Setting up MACH11 on a Single Server

The following instruction guidelines assume that the RSS instance is created on a dedicated machine (apollo_rss1), distinct from the machine (apollo) that runs the penguin instance. The configuration will be performed as user informix unless otherwise noted.

• export PENGUIN_RSS1=/home/informix/instances/penguin_rss1

• mkdir -p $PENGUIN_RSS1/logs

• chmod 775 $PENGUIN_RSS1/logs

• mkdir -p $PENGUIN_RSS1/data

• chmod 775 $PENGUIN_RSS1/data

We will copy the environment file from our primary penguin instance and change the INFORMIXSERVER environment variable:

• cd $PENGUIN_RSS1

• scp -p informix@apollo:/home/informix/instances/penguin/env.sh .

•  vi env.sh

  export INFORMIXSERVER=penguin_rss1

The new environment file looks like this:

#!/bin/bash
export INFORMIXDIR=/opt/ibm/ids/ids.dev
export INFORMIXSERVER=penguin_rss1
export ONCONFIG=onconfig.$INFORMIXSERVER
export INFORMIXSQLHOSTS=$INFORMIXDIR/etc/sqlhosts.$INFORMIXSERVER
export LD_LIBRARY_PATH=$LD_IBRARY_PATH:$INFORMIXDIR/lib:$INFORMIXDIR/lib/esql
export PATH=$PATH:$INFORMIXDIR/bin
export PENGUIN_RSS1=/home/informix/instances/$INFORMIXSERVER

After modifying the file we should execute it in the current shell in order to set the necessary environment for our IDS instance:

• . $PENGUIN_RSS1/env.sh

Remember to use the leading dot, so that the environment variables are set in the current shell.

You might check if everything has been set correctly using the env comand:

• env | egrep "^INFORMIX|^ONCONFIG|^LD_LIBRARY_PATH|^PATH|^PENGUIN_RSS1"

We will create a new sqlhosts file that contains an entry for our RSS instance and another entry pointing to our primary instance penguin:

• RSS node (Instance penguin_rss1, Machine apollo_rss1)

  • vi $INFORMIXSQLHOSTS

    #=================================================
    #DBSERVER      PROTOCOL      HOSTNAME      SERVICE
    #=================================================
    penguin_rss1   onsoctcp      apollo_rss1  40300
    penguin        onsoctcp      apollo       40000

In addition we need to add the new instance penguin_rss1 to the already existing sqlhosts file of the primary instance penguin on machine apollo:

• Primary node (Instance penguin, Machine apollo)

  • vi $INFORMIXSQLHOSTS

    #=================================================
    #DBSERVER      PROTOCOL      HOSTNAME      SERVICE
    #=================================================
    penguin        onsoctcp      apollo       40000
    penguin_drda   drsoctpc      apollo       40001
    penguin_shm    onipcshm      apollo       dummy
    penguin_hdr    onsoctcp      apollo_hdr   40200
    # new entry pointing to the RSS instance
    penguin_rss1   onsoctcp      apollo_rss1  40300

Please do not copy/paste the sqlhosts files above. This might lead to problems due to hidden control characters. Just write it off from the above examples.

In the next step we will create a dedicated onconfig file for our penguin_rss1 instance. We use the existing onconfig.penguin as a template for onconfig.penguin_rss1:

• cd $INFORMIXDIR/etc

• scp informix@apollo:/opt/ibm/ids/ids.dev/etc/onconfig.penguin $ONCONFIG

• vi $INFORMIXDIR/etc/$ONCONFIG

• MSGPATH

  • MSGPATH  /home/informix/instances/penguin_rss1/logs/online.log

• SERVERNUM
  • Our PRIMARY instance penguin has SERVERNUM 1 assigned, the SDS instance penguin_sds1 has SERVERNUM 2 assigned, the HDR instance penguin_hdr has SERVERNUM 3 assigned. IDS server numbers must be unique on the same machine, but are allowed to overlap if the instances are located on different machines. Anyway, we will choose the unique approach:

  • SERVERNUM  4

• DBSERVERNAME

  • DBSERVERNAME     penguin_rss1

• DBSERVERALIASES
  • We will create no aliases for our penguin_rss1, so leave this parameter blank.

  • DBSERVERALIASES

• DUMPDIR

  • DUMPDIR  /home/informix/instances/penguin_rss1/logs

You need to trust user informix on the Primary as well as on the RSS node. This could either be done thru the traditional Unix etc/hosts.equiv or .rhosts mechanism or thru a new Informix based mechanism. We will use the .rhosts mechanism here:

• Primary, Instance penguin, Machine apollo

  • vi ~informix/.rhosts

  • apollo_rss1  informix

• RSS Node, Instance penguin_rss1, Machine apollo_rss1

  • vi ~informix/.rhosts

  • apollo  informix

Verify that trusting works by making sure that executing the following commands as user informix don't prompt for a password:

• Machine apollo

  • rsh apollo_rss1 date

• Machine apollo_rss1

  • rsh apollo date

Before a RSS node could be integrated in the MACH 11 Cluster, the parameter LOG_INDEX_BUILDS must be enabled on the primary. This could be done thru the following command:

• onmode -wf LOG_INDEX_BUILDS=1

We need to create a backup image of your Primary instance which will serve as base for the initial synchronization between Primary and RSS instance:

• Perform Level-0-Backup on Primary (Instance penugin, Machine apollo)

  • ontape -s -L 0 -t STDIO | gzip > /tmp/ontape.L0.penguin.gz

• Transfer the backup image from Primary to RSS Node (Instance penguin_rss1, Machine apollo_rss1)

  • scp /tmp/ontape.L0.penguin.gz informix@apollo_rss1:/tmp

The backup image of the Primarymust be restored on the RSS instance:

• Before starting the Restore, you need to create the same chunk layout on the RSS node as on the Primary node

  • for CHK in (rootdbs1.chk datadbs1.chk1  idxdbs1.chk1  logdbs.chk1  physdbs.chk1 tempdbs1.chk1)
    do
       touch $PENGUIN_RSS1/data/$CHK
       chmod 660 $PENGUIN_RSS1/data/$CHK
    done

  • Because the chunk pathnames need to be exactly the same as on the Primary node, we will create a symbolic link. This ensures that IDS can address the chunks on machine apollo_rss1 thru the same pathname as on machine apollo:

    • ln -s $PENGUIN_RSS1 /home/informix/instances/penguin

• Restore the backup image on the RSS node (Instance penguin_rss1, Machine apollo_rss1)

  • gzip -d -c /tmp/ontape.L0.penguin.gz | ontape -p -t STDIO

The RSS connection could be established with two simple commands:

• On the Primary node (Instance penguin, Machine apollo) we need to declare the RSS node:

  • onmode -d add RSS penguin_rss1

• On the RSS node (Instance penguin_rss1, Machine apollo_rss1) we need to announce the name of the Primary

• onmode -d RSS penguin

After these commands Primary and RSS node will talk to each other and the Primary sends all transactions, that have been processed since the Level-0-Backup, to the RSS node. The RSS node rollforwards them until both instances are synchronized. Just continuously watch the online.log on the RSS node:

• tail -f $PENGUIN_RSS1/logs/online.log &

  • On the RSS node, you will see some similar messages like the following in your online.log:

    13:28:24  DR: Reservation of the last logical log for log backup turned off
    13:28:24  DR: new type = RSS
    13:28:24  Warning: Invalid (non-existent/blobspace/disabled) dbspace listed
             in DBSPACETEMP: 'tempdbs1'
    13:28:24  DR: Owner of the disk is set as penguin_rss1.
    13:28:25  RSS Server penguin - state is now connected
    13:28:25  Logical Recovery Started.
    13:28:25  10 recovery worker threads will be started.
    13:28:25  Start Logical Recovery - Start Log 7, End Log ?
    13:28:25  Starting Log Position - 7 0x8e6018
    13:28:25  Clearing the physical and logical logs has started
    13:28:25  Segment locked: addr=0x4d1b1000, size=8388608
    13:28:25  Dynamically allocated new virtual shared memory segment (size 8192KB)
    13:28:25  Memory sizes:resident:116532 KB, virtual:40848 KB, no SHMTOTAL limit
    13:28:27  shmctl: errno = 12
    13:28:27  Shared memory segment 0x0x4d9b1000 could not be forced resident.
    13:28:27  Dynamically allocated new virtual shared memory segment (size 8192KB)
    13:28:27  Memory sizes:resident:116532 KB, virtual:49040 KB, no SHMTOTAL limit
    13:28:36  Cleared 254 MB of the physical and logical logs in 11 seconds
    13:28:36  B-tree scanners disabled.
    13:28:37  DR: RSS secondary server operational

  • On the Primary node, you will see some similar messages like the following in your online.log:

    13:28:25  RSS Server penguin_rss1 - state is now connected
    13:28:26  RSS penguin_rss1 is not acknowledging log transmission
    13:28:37  RSS penguin_rss1 resumed acknowledging log transmission

That's it. Your server pair is up and running !

You can monitor the status of your RSS server pair with a single simple command:

• onstat -g rss

  or

  onstat -g rss verbose

  • on the Primary node, you will see something like this:

    IBM Informix Dynamic Server Version 11.50.FC2DE -- On-Line (Prim) -- Up 2 days 03:32:55 -- 149188 Kbytes
    
    Local server type: Primary
    Index page logging status: Enabled
    Index page logging was enabled at: 2008/09/01 13:25:32
    Number of RSS servers: 1
    
    RSS Server information:
    
    RSS Srv      RSS Srv      Connection     Next LPG to send        Supports
    name         status       status           (log id,page)         Proxy Writes
    penguin_rss1 Active       Connected               7,2301         N
    

  • on the RSS node, the following information will be displayed:

    IBM Informix Dynamic Server Version 11.50.FC2DE -- Read-Only (RSS) -- Up 00:42:43 -- 165572 Kbytes
    
    Local server type: RSS
    Server Status : Active
    Source server name: penguin
    Connection status: Connected
    Last log page received(log id,page): 7,2300

From here you might move on to:

• section SDS - Shared Disk Server which shows how to configure a SDS instance
• section HDR - High Availability Data Replication which shows how to configure a RSS instance
• section ER - Enterprise Replication which shows how to configure a ER instance
• section CM - Connection Manager which shows how to configure the Connection Manager
• section CLR - Continuous Log Restore which shows how to configure a CLR instance