ifxclone can be used to clone a database server with minimum setup or configuration or quickly add a new node to an existing cluster or ER domain. Successfully cloning a server might still require some post-configuration steps to achieve a better running system. You must run the ifxclone command from the target server.

1 The ifxclone utility

Use the ifxclone utility to clone a server with minimum setup or configuration or quickly add a new node to an existing ER replication domain. When the ifxclone utility is run, most of the setup information is obtained from the server node that is cloned. Successfully cloning a server might still require some post-configuration steps to achieve a better running system.

The source server is the server that contains the data you wish to clone. The target server is the server that is to be loaded with data from the source server.

Execute on target

You must run the ifxclone utility from the target server. The value of FULL_DISK_INIT must be set to 1 in the target server.

DIRECT_IO

The ifxclone utility modifies the value of DIRECT_IO parameter to 0. Please be careful to restore this value with the previous value before doing the ifxclone (review the commented command on the onconfig file).

To run the ifxclone utility on a UNIX computer, you must run the command on the target server. It would be best if you also were a DBSA on the source server.

2 Command syntax

Here are the command-line options for the ifxclone command:

ifxclone -SIPtip # Clone a server

-h –help # Display this output

-S –source=<name> # Name of the source node

-I –sourceIP=<IP> # IP address of source node

-P –sourcePort=<port> # Port number of source server

-t –target=<name> # Name of target server

-i –targetIP=<IP> # IP address of target server

-p –targetPort=<port> # Port number of target server

-d –disposition=[RSS|ER|HDR|SDS] # Clone disposition (default:standard)

-s –size=[tiny|small|medium|large] # Configuration size

-c –configParm=”PARAMETER=VALUE” # Configuration override

-L –useLocal # Use the local config and sqlhost

-T –trusted # No userid/password required

-a –autoconf # Propagate SQLHOSTS and trusted-host records to Enterprise Replication nodes and high-availability replication servers.

-k –createchunkfile # automatically create chunks on the target

EXAMPLE

ifxclone -S ol_source -I <Source IP> -P 9088 -t ol_target -i <Target IP> -p 9088 -T

Info

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 avoid naming our systems “primary” and “secondary” because these are roles that can switch between the servers over time, perhaps for long periods.

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, we 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’);

3 Prerequisites

Perform the following prerequisites before cloning a server:

The source server

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

onmode -wm ENABLE_SNAPSHOT_COPY=1

onmode -wf TEMPTAB_NOLOG=1

onmode -wf LOG_INDEX_BUILDS=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):

˘

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. Then, we will discuss the output during the setup of server2.

The target server

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. Change the value of FULL_DISK_INIT to 1 in ONCONFIG file before cloning the server.
4. Setup the source and local ONEDB_ SQLHOSTS file

The “ifxclone” command cannot set up 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; }’

• Set the following environment variables:

export ONEDB_HOME =/home/onedb

export ONEDB_SERVER=ol_target

export ONEDB_ SQLHOSTS =$ONEDB_HOME/etc/sqlhosts

export ONCONFIG=onconfig

4 Clone an instance in standard mode

You must run the ifxclone utility from the target server.

• Execute ifxclone maintaining the configuration of the target server and without requesting user and password from connection to the source server:

ifxclone -S ol_source -I <Source_IP> -P <PORT> -t ol_target -i <Target_IP> -p <PORT> -T -L

• Execute ifxclone requesting the user and password and the configuration file is generated the same as the origin server by changing the parameter MSGPATH:

ifxclone -S ol_source -I <Source_IP> -P <PORT> -t ol_target -i <Target_IP> -p <PORT> -c “MSGPATH=/home/onedb/tmp/clone.log”

5 Clone an instance in HDR mode

You must run the ifxclone utility from the target server.

• Execute ifxclone maintaining the configuration of the target server and without requesting user and password from connection to the source server:

ifxclone -S ol_source -I <Source_IP> -P <PORT> -t ol_target -i <Target_IP> -p <PORT> -T -L -d HDR

• Execute ifxclone requesting the user and password and the configuration file is generated the same as the origin server by changing the parameter MSGPATH:

ifxclone -S ol_source -I <Source_IP> -P <PORT> -t ol_target -i <Target_IP> -p <PORT> -d HDR -c “MSGPATH=/home/onedb/tmp/clone.log”

6 Clone an instance in RSS mode

You must run the ifxclone utility from the target server.

• Execute ifxclone maintaining the configuration of the target server and without requesting user and password from connection to the source server:

ifxclone -S ol_source -I <Source_IP> -P <PORT> -t ol_target -i <Target_IP> -p <PORT> -T -L -d RSS

• Execute ifxclone requesting the user and password and the configuration file is generated the same as the origin server by changing the parameter MSGPATH:

ifxclone -S ol_source -I <Source_IP> -P <PORT> -t ol_target -i <Target_IP> -p <PORT> -d RSS -c “MSGPATH=/home/onedb/tmp/clone.log”

7 DIRECT_IO

DIRECT_IO

The ifxclone utility modifies the value of DIRECT_IO parameter to 0. Please be careful to restore this value with the previous value before doing the ifxclone (review the commented command on the onconfig file).

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

For Cloning HDR

$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.

For cloning RSS

$onstat –g rss –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”, and show it is paired with server1 and -m option will also display the online.log which would be beneficial for progress or any error it reports

For standard server

$onstat –m –r 1

The server state at the top of each output burst should change from “Initialization”, to “Fast Recovery”, then eventually to “Online”, and –m option will show the online.log for any errors.