Common Setup (From Source Server)

Some changes and files will be the same on both servers. We will make the changes to the files on “host1” (our “server1” machine), and then “ifxclone” will copy them to the new target host (host2). We are avoiding naming our systems “primary” and “secondary” because these are roles that can switch between the servers over time, and perhaps for long periods of time.

Trusted Server Connection

The primary server must trust the connection from the new database server. We need mutual trust when the roles of the two servers reverse. While you can do this at the OS level, we will assume you want this trust limited to the database service. This can be done by creating a file you identify in the ONCONFIG file’s REMOTE_SERVER_CFG parameter in the $ONEDB_HOME/etc directory. For this example, will create a file named "trusted.hosts" in the "$ONEDB_HOME/etc" directory. This also allows HCL​ OneDB tools to update the trust information later.

Create an empty “trusted.hosts” file, and set the file permissions to limit write access to the instance owner(informix) and group (informix):

cp /dev/null $ONEDB_HOME/etc/trusted.hosts

chmod 640 $ONEDB_HOME/etc/trusted.hosts

Now configure the server to use the new file:

$ onmode -wf REMOTE_SERVER_CFG=trusted.hosts

Enable “ifxclone” and the “sysadmin:admin” function to setup the connectivity information on all servers in the cluster (for now it is just one).

$ onmode -wf CDR_AUTO_DISCOVER=1

You can manually edit the file the first time, but we will execute the “admin” SQL function in the “sysadmin” database using dbaccess to update the REMOTE_SERVER_CFG on all servers in the cluster (I am also adding our current server as trusted so either server can initiate a connection to the other, and this trust information will eventually be copied to our new server too):

execute function sysadmin:admin('cdr add trustedhost', 'host2 informix, host1 informix');

HDR ONCONFIG Changes

Disable temp table logging, and enable snapshot copy to be made by the “ifxclone” command:

$ onmode -wf TEMPTAB_NOLOG=1

$ onmode -wf ENABLE_SNAPSHOT_COPY=1

NOTE:

  1. The TEMPTAB_NOLOG setting is only really required on the secondary. However, when the roles are reversed, leaving this enabled would affect applications that depend on rollback on TEMP Tables. So, either plan to correct immediately after making a new primary or be consistent and don’t rely on TEMP Table transactions.
  2. If you are going to setup an RSS server instead of HDR secondary, we need to enable the logging of index builds. This causes all index creation operations to go through the logs (hope you have automatic log backups configured):

$ onmode -wf LOG_INDEX_BUILDS=1

ONEDB_ SQLHOSTS

The “ifxclone” command will attempt to add the new server to the ONEDB_ SQLHOSTS file, and if it already exists will not properly modify the file to define a server group the way we want. If you already have the entry for the new server we should delete it, or comment it out for now:

Database

server1 onsoctcp host1 9088

# server2 onsoctcp host2 9088

Database Logging Mode

Only databases using logging will be replicated. Databases using buffered logging can lose transactions if the log has not been flushed to disk and the server fails. This same window of vulnerability extends to the replica as well. If all databases are logging, or you don’t need the non-logging databases to be replicated, you can move on to the next step. You can verify the list of the non-logging databases, and those that are using buffered logging by running the following query against the “sysmaster” database table “sysdatabases” using “dbaccess”:

select name, is_buff_log from sysmaster:sysdatabases where is_logging = 0 or is_buff_log = 1;

Notes:

  • Stop the secondary servers
  • Change the logging mode and take a Level 0 backup
  • Restore the secondary from backup (or re-clone)

With Data Replication (DR) you should create all new Databases with some form of logging (ANSI, Unbuffered, or Buffered).

Chunk Path/Device Information

While we are still on server1, you should collect the path information for the chunks since these paths need to exist on the new server. You can collect this with the “onstat -d” command. We will discuss the output during setup of server2.

TARGET SETUP

Most, if not all, of the new server configuration can be handled by “ifxclone”:

  1. Copies the REMOTE_SERVER_CFG trusted host information
  2. Copies the ONCONFIG: Due to the number of configuration parameters that need to be the same, it is probably easiest to let “ifxclone” copy the ONCONFIG from the original server. Otherwise you need to verify each of the ONCONFIG parameters which must be identical (listed in the Administrators Reference) have been correctly set. If needed you can have “ifxclone” override some settings using the “-c” option.
  3. Setup the source and local ONEDB_ SQLHOSTS file

The “ifxclone” command cannot setup the symlinks to raw devices, or chunkfiles if they are in directories that do not exist.

Create Needed Directories and Symlinks to Raw Devices

All dbspace chunk paths used on the primary must be the same on our new server. You will need to create the matching symlinks to the corresponding physical devices. For cooked files, the “ifxclone” can create the missing chunk files automatically, even for the root dbspace, but it will not create the parent directories. The parent directories for those paths must already exist for “ifxclone” to successfully create the chunk files.

You can find the paths in the “onstat -d” output from “server1”. For this example, “onstat -d” produced the following output, showing that the chunk paths are all under the “/chunkdir” directory:

Then, for each of those paths, make sure the parent directories exist with adequate permissions. The above example only needs the “/chunkdir” directory to exist. It also must have the ownership, and permissions, so you will need to do these operations as root/administrator:

$ mkdir /chunkdir

$ chown informix:informix /chunkdir

$ chmod 770 /chunkdir

Under those directories you can manually create the needed raw device symlinks (need permission of 660, same as any cooked files you choose to create manually.)

If the list of chunks is long, you can collect the paths via the following command on “server1”, and use the output to create a script to handle the above steps for creating the required parent directories:

$ onstat -d | awk '$NF ~ /\// { print $NF; }'

Run “ifxclone”:

The “ifxclone” will make “server1” a primary, perform “fake” backup of “server1”, and restore it to “server2” as a new HDR secondary. All changes to logged spaces on “server1” will be continually applied to “server2”. The “ifxclone” will add the secondary to the ONEDB_ SQLHOSTS file on the “source” server, and copy the “source” server’s ONCONFIG information to the target:

$ ifxclone --source=server1 --sourceIP=host1 --sourcePort=9088 \

--target=server2 --targetIP=host2 --targetPort=9088 \

--trusted \

--createchunkfile \

--disposition=HDR \

--autoconf

Check the Progress

To monitor the Data Replication Information and message log, run the following (Ctrl-C to break out):

$ onstat -g dri -m -r 1

The server state at the top of each output burst should change from “Initialization”, to “Fast Recovery”, then eventually to “Read-Only (Sec)”, and show it is paired with server1 and the Data Replication state is “on”:

Server Failed to Initialize?

If the server failed to initialize, check the message log for errors. Correct any missing “paths”, or permissions on the filesystem, or any other changes needed to the ONCONFIG file. Then rerun the “ifxclone” command, but you must add “--useLocal” so you don’t overwrite any changes you fixed in the local ONCONFIG.

ONEDB_ SQLHOSTS is Updated

The “autoconf” option added a “group” to the server ONEDB_ SQLHOSTS file, and assigned each server in the group using the “g=” option. The group name is the name of the source server but with “g_” prepended. The ONEDB_ SQLHOSTS file from our example contains three lines now:

g_server1 group - -i=1

server1 onsoctcp host1 9088 g=g_server1

server2 onsoctcp host2 9088 g=g_server1

Verify Backup Device Configuration

Verify the ONCONFIG LTAPEDEV and TAPEDEV values (copied from server1 to server2) exist and have the correct permissions (RWX for owner and group) on the new server. This will ensure that any automatic and manual backups run as intended. If you need to change them on the secondary later, you can use “onmode -wf” command while the server is running to update the value.

Copying the alarmprogram.sh ensures that the same automatic log backup configuration is used on server2. In the event server2 becomes the primary, the log backups are already configured for operation.