The high availability data replication (HDR) reproduces updates to the primary database server on the secondary database server by having the primary database server send all its logical-log records to the secondary database server as they are generated. The secondary database server receives the logical-log records generated on the primary database server and applies them to its dbspaces.

How log records are sent: When the primary database server starts to flush the contents of the logical-log buffer in shared memory to the logical log on disk, the database server also copies the contents of the logical-log buffer to a data-replication buffer on the primary database server. The primary database server then sends these logical-log records to the secondary database server.

The secondary database server receives the logical-log records from the primary database server into a shared-memory reception buffer (which the database server automatically adjusts to an appropriate size for the amount of data being sent). The secondary database server then applies the logical-log records through logical recovery.

The HDR buffers are part of the virtual shared memory that the primary database server manages. The HDR buffers hold logical-log records before the primary database server sends them to the secondary database server. The HDR buffers are the same size as the logical-log buffers. This concept is represented in the following figure.

Related documents:

• Replication technologies in Informix Dynamic Server
• High-availability cluster configuration
• Performing basic administration tasks

Version of the database servers

The versions of the primary and secondary database servers must be the same.

Configuring dbspaces and chunks

The number of dbspaces, the number of chunks, their sizes, and the pathnames and their offsets must be identical on the primary and secondary servers.

Configuration Parameters

The ONCONFIG parameters shown below must have the same value on the two database servers:

• ROOTNAME

• ROOTOFFSET

• ROOTPATH

• ROOTSIZE

• PHYSDBS

• PHYSFILE

• LTAPEBLK

• LTAPESIZE

• TAPEBLK

• TAPESIZE

• DRAUTO

• DRINTERVAL

• DRTIMEOUT

Configuration of logical logs

All logs are replicated to the secondary server. You must configure the same number of logical logs and the same logical log size on both servers. The ONCONFIG parameters shown below must have the same values:

• LOGFILES
• LOGSIZE
• DYNAMIC_LOGS

Logical logs that are automatically added to the primary server are automatically replicated to the secondary server. Therefore, the value of the DYNAMIC_LOGS parameter has no effect on the secondary server, although it is recommended that it be kept in sync with the primary server value.

The logical logs on the secondary server have no utility, however, or the parameter LTAPEDEV of both servers point to /dev/null or point to a device (it may be different on both servers). This way in the secondary server (since in the primary it is usual to have a device to save the logical logs) it is necessary to indicate the path of a file that does not exist.

In order for replication to work, the two database servers must be able to connect to each other. To meet this requirement, the $INFORMIXDIR/etc/sqlhosts file on each server must contain at least the following lines:

• An entry that identifies a network connection to the server running on the server itself.
• An entry that identifies a network connection to the other server that is part of the replication.

For example, if the primary server is called dbsrv1 and the secondary server is called dbsrv1m, you must configure the following files:

In the /etc/hosts file there must be [dbsrv1] and [dbsrv1m]

192.168.10.11 dbsrv1
192.168.10.21 dbsrv1m

$INFORMIXDIR/etc/sqlhosts

dbsrv1          onipcshm        dbsrv1          on_servername
ol_dbsrv1       onsoctcp        dbsrv1          sqlexec
ol_dbsrv1m      onsoctcp        dbsrv1m         sqlexec

/etc/hosts.equiv

dbsrv1m

In the $INFORMIXDIR/etc/onconfig file, the DBSERVERALIASES must be indicated by the database manager for the connection.

In the /etc/hosts file there must be [dbsrv1] and [dbsrv1m]

192.168.10.11   dbsrv1
192.168.10.21	dbsrv1m

$INFORMIXDIR/etc/sqlhosts

dbsrv1m         onipcshm        dbsrv1m         on_servername
ol_dbsrv1m      onsoctcp        dbsrv1m         sqlexec
ol_dbsrv1       onsoctcp        dbsrv1          sqlexec

/etc/hosts.equiv

dbsrv1

The hosts.equiv file is important since one machine must be able to connect to the other directly. For this you need to configure the hosts.equiv file on both machines.

If the HDR connection is configured correctly, SQL statements can be executed from one server against the other. The following example can be done in both directions, from the primary to the secondary and from the secondary to the primary.

The following example is to do this from the primary server dbsrv1.

dbaccess

After choosing a database (any) and choosing the "New" menu, the following query is performed:

Select * from NOMBRE_BD@DBSRVALIAS_MAQUINA_2:NOMBRE_TABLA;

For example:

Select *  from sysmaster@ol_dbsrv1m:sysdatabases;

This must be done without errors. If an error occurs, it can be for one of the following reasons:

908: Attempt to connect to database server (ol_dbsrv1, conerr=-25555, oserr=0) failed.

In $INFORMIXDIR/etc/sqlhosts an entry is missing to connect to the server.

956: Client host or user (informix@dbsrv2) is not trusted by the server.

In /etc/hosts.equiv an entry is missing for trusted servers. This file indicates the aliases of cards defined in /etc/hosts for which access by that card is considered trusted.

Optionally, you can configure the HDR connection between the primary and the secondary server to be performed by a unique port. To do this, add the s=6 attribute in the sqlhosts file of the two machines. For example:

• Primary Server:
  Copy

  dbsrv1             onipcshm        dbsrv1          informix
  ol_dbsrv1          onsoctcp        dbsrv1          sqlexec
  ol_dbsrv1_hdr      onsoctcp        dbsrv1          sqlexec2 s=6
  ol_dbsrv2          onsoctcp        dbsrv2          sqlexec
  ol_dbsrv2_hdr      onsoctcp        dbsrv2          sqlexec2 s=6

• Secondary server:
  Copy

  dbsrv2             onipcshm        dbsrv2          informix
  ol_dbsrv2          onsoctcp        dbsrv2          sqlexec
  ol_dbsrv2_hdr      onsoctcp        dbsrv2          sqlexec2 s=6
  ol_dbsrv1          onsoctcp        dbsrv1          sqlexec
  ol_dbsrv1_hdr      onsoctcp        dbsrv1          sqlexec2 s=6

  As seen in the example HDR communication between the primary and secondary server is done by the port sqlexec2 which must be defined in the file /etc/services of the two servers:

  Copy

  sqlexec         1526/tcp                        # IBM IDS
  sqlexec2        1528/tcp                        # IBM IDS

  In the case of using this connection mode, you must define the hosts.equiv file in the $INFORMIXDIR/etc/hosts.equiv directory of the two machines.

  If you attempt to access the server through that port, you get the following error message:

  Copy

  25539: Invalid connection-type.

If there is a different password defined for the informix user on each server, it is possible to indicate the login password by performing the following steps. Create a file in $INFORMIXDIR/etc/server_passwords with the contents:

remote_dbserver  remote_informixserver  informix  informix_passwd

Where

• remote_dbserver_ IP or network connection name
• remote_informixserver: the DB manager on the remote server that handles requests through remote_dbserver
• informix: the connection user to perform replication
• informix_passwd: the informix user password

For example:

server1m_hdr    ol_server1m_hdr    informix    infpasswd

With the command:

onpassword -k access_key -e $INFORMIXDIR/etc/server_passwords

The $INFORMIXDIR/etc/passwd_file file is created to contain the encrypted content and thus the $INFORMIXDIR/etc/server_passwords file can be deleted. And finally you have to modify the onconfig file to modify the parameter:

REMOTE_USERS_CFG passwd_file

For more information consult:

Configuring Secure Connections for Replica Servers

https://www.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.erep.doc/ids_erp_110.htm

Let's continue to assume that it will launch HDR replication on two servers named dbsrv1 as the primary server and dbsrv1m as the secondary server. The steps to enable HDR replication are:

Primary Server

• Make a level 0 backup on the dbsrv1 server:

  Copy

  > ontape -s -L 0

  And wait for it to end. This instruction will create an ontape file for use on the secondary machine. Examine the variable TAPEDEV of the onconfig file to check the file where the ontape will be located. This location could be on tape or on disk. This is necessary to make this file accessible to the secondary machine.

• Use the onmode -d command to pass the dbsrv1 server to primary and associate it with dbsrv1m as child:

  Copy

  > onmode -d primary ol_dbsrv1m

  When you run this command, the server will try to establish the connection on the secondary server and begin replication. At this time, dbsrv1m is not configured as a secondary server so the connection is not set correctly.

Secondary Server

• Verify that the database engine is stopped.

• Check that the TAPEDEV parameter of the onconfig file is pointing to the ontape file.

  Copy

  TAPEDEV		/RUTA/NOMBRE_FICHERO	> Tape device path

  If the ontape file is compressed there are two options:

  • Unzip the file.
  • Use a fifo mechanism (pipe) so you do not have to decompress.

  In the following section "Accessibility of the backup (ontape) from the secondary machine" explains the possibilities that exist for the secondary server to have access to this file.

  It is necessary to verify that the user and group owning the file is informix, and the permissions are 660 (-rw-rw ----).

  Copy

  > ls -l /RUTA/NOMBRE_FICHERO
  > -rw-rw----  1 informix informix 31459802 dic  1 15:48 /RUTA/NOMBRE_FICHERO

• Perform dbsrv1m on the physical restore of the level 0 backup created on the primary server. Use the command:

  Copy

  > ontape -p

  And do not use ontape -r as it performs both physical and logical restore.

  This operation must be performed with the database engine stopped (otherwise the error 'Can not recovery warm ROOTDBS' would be displayed). The ontape file must be accessible from the secondary server, the following section explains the different possible mechanisms to make this file accessible and execute the command successfully.

  When this command is executed, several questions are asked.

  1. Please mount tape 1 on PATH_TAPEDEV and press Return to continue ... [Return]

  2. Continue restore? [Return]

  3. Do you want to back up the logs? no [Return]. These are the logs of the local server, as a complete ontape start up for replication does not matter what was before.

  4. When the recovery of level 0 ends, it asks if it is also going to recover from a level 1.

  5. Do you want to restore level 1? no [Return]. In this run there are no restores of incremental levels.

  When the restore is finished, the database server is put into FAST RECOVERY.

• Use the onmode -d command to enable dbsrv1m as the secondary server and associate it with the primary server:

  Copy

  > onmode -d secondary ol_dbsrv1

  dbsrv1m will attempt to establish an HDR connection to the primary server (dbsrv1) and begin replication. The connection must be completed successfully.

  This operation must be performed just when the restore is complete. The engine will start in secondary mode automatically.

The backup (ontape) made on the primary machine must be accessible from the secondary machine:

• Copy the file (ontape) from the primary server to the secondary server.

• Mount a directory with nfs .This way the secondary server could access the file located on the primary server.

• If you have two tape drives on each machine, and the ontape has been sent to tape, you simply have to change the drive tape. In case of only having a tape drive, you can change the unit from one machine to the other but surely it will need to restart to detect the device.

• Use standard I / O to perform simultaneous backup and restore (available from version 10). This option is recommended for versions 10 or higher.

If the version is 10 or higher it is recommended to see the following section "Simultaneous Backup and Restore Using Standard I/O".

In case of copying the file in the machine, there are two alternatives.

• Use the compressed file generated by the dbs_ontape shell.
• Unzip the file

If there is enough disk space, you can choose to uncompress the contents of the file (ontape.gz) and have the TAPEDEV parameter of the onconfig file point to the uncompressed file. However, there is a more elegant (and obligatory if there is no disk space) that avoids having to unzip the file, using a pipe file.

1. The ontape command can not read from standard outputs (via command line) in versions prior to 10. The ontape file is compressed with gzip. Suppose the ontape file is located in / tmp. Create a pipe file in order to execute the gzip command on the:

   Copy

   > cd /tmp
   > ls
   [...] ontape.gz [...]
   > mkfifo tapedev
   > chown informix:informix tapedev
   > chmod 770 tapedev

   Then the gunzip command is started:

   Copy

   > gunzip < ontape.gz > tapedev

   This process waits for someone else to read the standard output of the tapedev file.

2. From another console runs a command that uses the standard output of the tapedev file, The contents of the ontape.gz file. In other words, the gunzip < ontape.gz Decompresses the file and sends it to the tapedev gateway, but in reality this special file does nothing until some other process reads its output.

3. Now you can run:

   Copy

   > ontape -p -t /tmp/tapedev

   Before performing the ontape, this process asks several questions.

   1. Please mount tape 1 on PATH_TAPEDEV and press Return to continue ... [Return] In this step, the gunzip command has been closed and must be restarted.

   2. Continue restore? [Return]

   3. Do you want to back up the logs? no [Return]

When the recovery of level 0 ends, it asks if it is also going to recover from a level 1.

1. Do you want to restore level 1 ? no [Return]

Just when Return is made for the first prompt (Please mount ...), the pipe process is closed and you have to re-execute it from the corresponding console:
> gunzip < ontape.gz > tapedev

As of version 10, the ontape can read or write from the standard output, so to put a replica into operation we can simultaneously perform a backup on the standard output and a restoration from the standard entry. If you are backing up and restoring for the sole purpose of replicating a database server, use the -F option to prevent the archive being saved.

1. You must have the rsh server installed on the secondary machine and the rsh client on the primary machine. To install the package can be used in:

   Primary server

   Copy

   Distribuciones mandriva
   $ urpmi rsh
   Resto de distribuciones
   $ rpm -i rsh

   Secondary Server

   Copy

   Distribuciones mandriva
   $ urpmi rsh-server
   Resto de distribuciones
   $ rpm -i rsh-server

   The rsh server is part of the xinetd service. The xinetd service must be active by editing the /etc/xinetd.d/rsh file and change the disable parameter with the no value:

   Copy

   disable = no

   It is then added as a service and put into operation.

   Copy

   $ chkconfig rsh on
   $ service xinetd restar

2. The rsh command requires both servers to be trusted's. Replication also, at the beginning of this document, specifies the steps to follow to create trusted servers. In addition to adding the Ips or names of the desired servers in the /etc/hosts.equiv file, in some OS its necessary to add them also in the file .rhosts.

3. Before running the backup and restore, the onconfig file's TAPEDEV parameter must be pinting to the standard STDIO I/O on both servers (primery and secondary).
   Edit the file $INFORMIXDIR/etc/onconfig

   Copy

   TAPDEDEV 		STDIO

4. Then as an informix user the execution of the backup in the primary machine and restoration "ontape -p" in the secondary machine via rsh is performed.

   Copy

   > ontape -s -L 0 | rsh secondary_host "ontape -p"

5. A problem may occur because of the INFORMIXDIR and INFORMIXSERVER environment variables. If the command does not take the appropriate values, they can be forced by:

   Copy

   >  ontape -s -L 0 | rsh secondary_host "(export INFORMIXDIR=/home/informix/; export INFORMIXSERVER=secondary_dbserver; /home/informix/bin/ontape -p)"

6. Restore the values of the TAPEDEV parameter in the $INFORMIXDIR/etc/onconfig on both servers..

[erp@dbsrv1 ~]$ onstat -

IBM Informix Dynamic Server Version 9.40.UC5     -- On-Line (Prim) -- Up 07:41:49 -- 1470888 Kbytes

On-Line (Prim) indicates that the server is "On-Line" and that there is HDR replication between two BD servers and that this is the "Primary".

[erp@dbsrv1m ~]$ onstat -

IBM Informix Dynamic Server Version 9.40.UC5     -- Read-Only (Sec) -- Up 70 days 16:58:38 -- 1470888 Kbytes

Read-Only (Sec) indicates that the server is in "Read-Only"(consultations only) mode and there is HDR replication between two BD servers and that this is the "Secondary".

To obtain full HDR monitoring information, run the command-line utilities:

• The onstat -g dri option: The following fields are displayed:

  • The database server type (primary, secondary, or standard)
  • The HDR state (on or off)
  • The paired database server. Database manager with which replication is performed. This DB manager must be in the file $INFORMIXDIR/etc/sqlhosts and there must also be an entry in the file /etc/hosts.equiv for the hostname defined in $INFORMIXDIR/etc/sqlhosts for the DB manager.
  • The last HDR checkpoint. Display the logical log identifier (ID) and the page of the last record written in the logs.
  • The values of the HDR configuration parameters:

    • DRINTERVAL: Time in seconds that elapses since an operation is performed until it is sent to the secondary server. In other words, each time the logs are sent to the secondary server.

    • DRTIMEOUT: Time in seconds that elapse before the primary server can connect to the secondary server to send the logs to the file specified in the DRLOSTFOUND parameter.

    • DRLOSTFOUND: Indicates the file where logs that could not be transferred before the time were sent DRTIMEOUT.

  Copy

  $ onstat -g dri
  
  IBM Informix Dynamic Server Version 9.40.UC5     -- Read-Only (Sec) -- Up 70 days 17:00:26 -- 1470888 Kbytes
  
  Data Replication:
    Type         State        Paired server        Last DR CKPT (id/pg)
    secondary    on           ol_dbsrv1                 20651 / 1388
  
    DRINTERVAL   30
    DRTIMEOUT    30
    DRLOSTFOUND  /home/informix/etc/dr.lostfound

• The oncheck -pr option:If your database server is running HDR, the reserved pages PAGE_1ARCH and PAGE_2ARCH store the checkpoint information that HDR uses to synchronize the primary and secondary database servers.

  Copy

  Validating PAGE_1ARCH & PAGE_2ARCH...
            Using archive page PAGE_2ARCH.
  
      Archive Level                  0
      Real Time Archive Began        07/26/2017 05:00:01
      Time Stamp Archive Began       0xc8c4d49d
      Logical Log Unique Id          11771
      Logical Log Position           0x7bf018
  
      Archive Level                  1
      Real Time Archive Began        07/26/2017 15:00:01
      Time Stamp Archive Began       0xc8dab44f
      Logical Log Unique Id          11774
      Logical Log Position           0x1a48018
  
      Archive Level                  2
      Real Time Archive Began        07/26/2017 21:00:00
      Time Stamp Archive Began       0xc8e3eb17
      Logical Log Unique Id          11774
      Logical Log Position           0x21ee018
  
      DR Ckpt Logical Log Id         11802
      DR Ckpt Logical Log Pos        0x12c018
      DR Last Logical Log Id         11802
      DR Last Logical Log Page       300
      DR Last Mode Change            7          Primary mode

If any of the database servers are stopped, it can be restarted normally and the HDR replication will automatically re-activate.

If you need to change settings (which must be done on both servers), or simply stop them, You must keep in mind that when you start them you must do it in the reverse order in which you stopped them. For example, if for first dbsrv1 and then dbsrv1m, you must first start dbsrv1m and then dbsrv1 at startup.

If the primary server could not be used or you want to end HDR replication between the two servers, you can run the following command to pass the secondary server to normal mode.

onmode -d standard

When using HDR replication, you must back up logical logs and dbspaces only on the primary server. However, have everything ready to be able to start the backups on the secondary server in case the database server is changed to standard mode. You must use the same backup tool on both servers. The block size and the tape size, (for both normal ontape and logical logs), must be identical on both servers.

You can not change the mode of the databases to transactional on the primary server while you are using HDR replication. What you can do is to pass a database to non-transactional; However, changes in that database will not be replicated thereafter.

To pass a database to transactional:

1. Stop the HDR Replication, stop the secondary server.

2. Change the database to transactional.

3. Perform a Level 0 ontape on the primary server and retrieve it on the secondary server, as explained in "Putting replication to work for the first time".

You can only add or delete chunks or dbspaces on the primary server. This operation is automatically replicated to the secondary server. This mechanism ensures that the distribution of spaces is consistent between the pair of servers.

The device, link or cooked file must exist on both servers before registering a chunk or dbspace, otherwise replication will be disabled.

This section explains how to manually change the server type in High Availability Data Replication (HDR), from Primary to Secondary and vice versa. The steps explained below only apply when replication has been started with the DRAUTO parameter of the ONCONFIG configuration file with a value of 0.

To follow the steps shown in this section it is advisable to have two open sessions with the informix user one for each server, the primary and the secondary. We assume that the informix instance of the primary server is ol_dbsrv1 and the secondary server is ol_dbsrv2.

• Primary Server:
  Copy

  $ onstat -g dri
  IBM Informix Dynamic Server Version 12.10.FC1B2TL -- On-Line (Prim) -- Up 00:00:21 -- 149720 Kbytes
   
  Data Replication at 0x4c674028:
     Type           State        Paired server        Last DR CKPT (id/pg)    Supports Proxy Writes
     primary        on           ol_dbsrv2                    91 / 4895       NA
   
     DRINTERVAL   30
     DRTIMEOUT    30
     DRAUTO       0
     DRLOSTFOUND  /home/informix/etc/dr.lostfound
     DRIDXAUTO    0
     ENCRYPT_HDR  0
     Backlog      0
     Last Send    2013/10/11 10:53:08
     Last Receive 2013/10/11 10:53:08
     Last Ping    2013/10/11 10:53:06

• Secondary Server:
  Copy

  $ onstat -g dri                                                               
                                                                                                      
   IBM Informix Dynamic Server Version 12.10.FC1B2TL -- Read-Only (Sec) -- Up 00:01:38 -- 157912 Kbytes
                                                                                                       
   Data Replication at 0x4c674028:                                                                     
      Type           State        Paired server        Last DR CKPT (id/pg)    Supports Proxy Writes    
      HDR Secondary  on           ol_dbsrv1                    91 / 4895       N                        
                                                                                                     
      DRINTERVAL   30                                                                                   
      DRTIMEOUT    30                                                                                   
      DRAUTO       0                                                                                    
      DRLOSTFOUND  /home/informix/etc/dr.lostfound                                                      
      DRIDXAUTO    0                                                                                    
      ENCRYPT_HDR  0                                                                                    
      Backlog      0                                                                                    
      Last Send    2013/10/11 10:53:13                                                                  
      Last Receive 2013/10/11 10:53:13                                                                  
      Last Ping    2013/10/11 10:52:57

  Therefore the goal is to put the instance ol_dbsrv2 as primary and ol_dbsrv1 as secondary.

Steps to follow: (IBM documentation)

Current primary server

• Check that the instance is online as a primary server, in case contract does not follow the next steps until remedy the situation.
  Copy

  $ onstat -
  
  IBM Informix Dynamic Server Version 12.10.FC1B2TL -- On-Line (Prim) -- Up 00:12:13 -- 149720 Kbytes

• Stop instance
  Copy

  $ onmode -ky

Current secondary server

• Set the instance to standard mode

  Copy

  $ onmode -d standard

• Set the instance as the primary server

  Copy

  $ onmode -d primary < secondary dbserver name >*

• Stop instance

  Copy

  $ onmode -ky

New secondary server

• Copy

  $ oninit -PHY

  Copy

  Check the message log for these messages: 
  Recovery Mode 
  
  The server status should contain: 
  -- Fast Recovery -- Up

• Copy

  $ onmode -d secondary   < primary dbserver name >*

New Primary Server

• Copy

  $ oninit

In case of a secondary replication server, it is possible to enable ENABLE_HDRSWITCH to automatically connect to the secondary server only in query mode when the primary is not available. When this option is set to true, the secondary server properties are used to connect to the secondary server in an HDR pair, if the primary server is unavailable.

The parameters to be used are:

• ENABLE_HDRSWITCH = true;
• IFXHOST_SECONDARY = secondary host machine;
• INFORMIXSERVER_SECONDARY = secondary server;
• PORTNO_SECONDARY = secondary port number;

The following example shows a connection URL corresponding to the primary server ol_dbsrv1 and secondary ol_dbsrv2:

jdbc:informix-sqli:192.168.10.31:1526/%DBMS%:INFORMIXSERVER=ol_dbsrv1;LOBCACHE=512000;FET_BUF_SIZE=8192;ENABLE_TYPE_CACHE=1;ENABLE_HDRSWITCH=true;
IFXHOST_SECONDARY=192.168.10.38;PORTNO_SECONDARY=1526;INFORMIXSERVER_SECONDARY=ol_dbsrv2'