Hot migration procedure

This hot migration procedure is supported as of solidDB server version level 7.0 Interim Fix 2 / 7.0 Fix Pack 3. For versions prior to Fix Pack 3, use the hot migration procedure by using the ADMIN COMMAND 'hsb netcopy' command; see the documentation for your current release.

1 If your applications have not been designed to fail over automatically, notify users that they will lose their connections and will need to reconnect to the new primary server.

a Since each of your solidDB servers will operate alone (specifically, in PRIMARY ALONE state) during part of the upgrade operation, make sure that both computers are in a healthy state. For example, both computers should have sufficient free disk space, reliable network connections, and a UPS device in case of power failure.

b Each of the servers will operate in PRIMARY ALONE state for at least a short time (while the other server is being upgraded). While the server is in PRIMARY ALONE state, transactions are stored in the transaction log. You must have enough disk space available for the log file to store all the transactions that will occur while the other server is being upgraded, including the time it takes that other server to catch up after the server is restarted.

c Make sure that a copy of the new software version is available on each computer.

solidDB is delivered as a single installation file. If you do not want to run the installer on your production environment server, install solidDB on a separate server and copy the executables, libraries, and drivers manually to your production server, as applicable for your setup.

Note The upgrade procedure differs depending on whether you are upgrading to a new version level (for example, from Version 101 to Version 200) or applying a fix pack (for example, Version 200 Fix Pack 1 to Version 200 Fix Pack 2). The differences are described in the procedure.

3 If you have a watchdog program, shut down the watchdog temporarily so that it does not run commands that conflict with the commands that you run during the upgrade process. For example, after you disconnect the primary server from the secondary server, you do not want the watchdog to try to reconnect the servers before you upgrade the secondary server.

In the following steps, S1 is the original primary server and S2 is the original secondary server. The state of each server changes as you go through this process.

3 Change the primary server (S1) to operate in PRIMARY ALONE state (if the server has not already automatically switched to that state) and verify that server S1 is in the PRIMARY ALONE state.

Note solidDB is delivered as a single installation file. If you do not want to run the installer on your production environment server, install solidDB on a separate server and copy the executables, libraries, drivers, and license file manually to your production server, as applicable for your setup. If necessary, update also the solid.ini file.

If you are upgrading to a new version level (for example, Version 101 to Version 200), start the solidDB server using the -x autoconvert command-line option.

The -x autoconvert option instructs the server to accept and convert the existing database to the new version level.

If you are applying a new fix pack level (for example, Version 200 Fix Pack 1 to Version 200 Fix Pack 2), you can start the solidDB server normally. Conversion of the database is not needed.

6 Connect the primary server (S1) to the secondary server (S2) by running the following command on the primary server:

Note If the secondary server is running a newer version of the server, you cannot run the ADMIN COMMAND 'hsb connect' command on the secondary server.

This step starts the process by which the secondary server catches up on data changes that occurred while the secondary server was down. Wait for the catchup to complete before continuing.

7 When the servers are connected and caught up, perform a role switch to prepare for shutting down the current primary server (S1):

10 Set the primary server (S2) to operate in the PRIMARY ALONE state, if it has not already automatically switched to that state. Verify that server S2 is in the PRIMARY ALONE state.

▪ If you are upgrading to a new version level (for example, Version 101 to Version 200), start the solidDB server using the -x autoconvert command-line option.

The -x autoconvert option instructs the server to accept and convert the existing database to the new version level.

▪ If you are applying a new fix pack level (for example, Version 200 Fix Pack 1 to Version 200 Fix Pack 2), you can start the solidDB server normally. Conversion of the database is not needed.

The ADMIN COMMAND 'hsb connect' command connects the primary server (S2) to the secondary server (S1) and starts the process by which the new secondary server catches up on data changes that occurred while it was down.

If this step fails, copy the entire database to the secondary server by using the ADMIN COMMAND 'hsb netcopy' command and then try and connect the servers again.

After the new secondary server catches up to the new primary server, your system should be operating normally. Both the new primary and secondary servers have been upgraded and have the most current data.

After the upgrade, you might want to run some test queries to make sure that everything is operating properly.

1 Test that both your primary and secondary servers are working correctly. For example, you might choose the following sequence of operations: