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 using netcopy.
Before you begin
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.
2 Prepare your system and your software for upgrades:
a Since each of your solidDB® servers will be operating 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, it will be storing transactions 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 it 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 node, install solidDB® on a separate node and copy the executables, libraries, and drivers manually to your production node, as applicable for your setup.
Tip: The upgrade procedure differs depending on whether you are upgrading to a new version level (for example, from 7.0 to 100) or applying a fix pack (for example, 7.0 Fix Pack 2 to 7.0 Fix Pack 3). The differences are described in the procedure.
3 If you have a watchdog program, turn it off temporarily so that it does not issue commands that conflict with the commands that you issue during the upgrade process. For example, after you disconnect the Primary from the Secondary, you do not want the watchdog to try to reconnect them before you upgrade the Secondary.
About this task
In the steps below, S1 (“OP”) and S2 (“OS”) represent the original Primary and Secondary servers. Each server’s state changes as you go through this process.
Procedure
1 S1: Disconnect the Primary from the Secondary:
ADMIN COMMAND 'hsb disconnect';
2 S2 OS: Shut down server S2 (Secondary):
ADMIN COMMAND 'shutdown force';
3 S1 OP: Tell server S1 (Primary) to operate in PRIMARY ALONE state if it has not already automatically switched to that state. Verify that server S1 (Primary) is in the PRIMARY ALONE state.
ADMIN COMMAND 'hsb set primary alone'; ADMIN COMMAND 'hsb state';
4 S2 OS: Upgrade server S2 (original Secondary) to the new solidDB® version level.
Note solidDB® is delivered as a single installation file. If you do not want to run the installer on your production environment node, install solidDB® on a separate node and copy the executables, libraries, drivers, and license file manually to your production node, as applicable for your setup. If necessary, update also the solid.ini file.
5 S2 OS: Bring up server S2 (original Secondary).
If you are upgrading to a new version level (for example, 7.0 to 100), start the solidDB® server using the -x autoconvertcommand-line option.
solid -x autoconvert
The -x autoconvertoption 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, 7.0 Fix Pack 2 to 7.0 Fix Pack 3), you can start the solidDB® server normally. Conversion of the database is not needed.
The S2 server comes up in SECONDARY ALONE state.
6 S1 OP: Connect the Primary server to the Secondary:
ADMIN COMMAND 'hsb connect';
Note If the Secondary server is running a newer version of the server, you cannot issue the hsb connectcommand on the Secondary.
This step starts the process by which the Secondary catches up on data changes that occurred while the Secondary was down.
7 S1 OP: Wait for the catchup to complete before continuing.
8 S2: After the servers are connected and caught up, perform a role switch to prepare for shutting down the current Primary (S1 OP):
ADMIN COMMAND ' hsb switch primary';
9 S2: Disconnect the Primary from the Secondary:
ADMIN COMMAND 'hsb disconnect';
10 S1 OP: Shut down server S1 OP (now in Secondary mode):
ADMIN COMMAND 'shutdown force';
Important: The force option aborts all open transactions.
11 S2 OS: Set the new Primary server S2 (old Secondary) 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.
ADMIN COMMAND 'hsb set primary alone'; ADMIN COMMAND 'hsb state';
12 S1 OP: Upgrade server S1 (your original Primary server) to the new solidDB® version level.
Note solidDB® is delivered as a single installation file. If you do not want to run the installer on your production environment node, install solidDB® on a separate node and copy the executables, libraries, drivers, and license file manually to your production node, as applicable for your setup. If necessary, update also the solid.ini file.
13 S1 OP: Bring up server S1.
▪If you are upgrading to a new version level (for example, 7.0 to 100), start the solidDB® server using the -x autoconvert command-line option.
solid -x autoconvert
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, 7.0 Fix Pack 2 to 7.0 Fix Pack 3), you can start the solidDB® server normally. Conversion of the database is not needed.
The S1 OP server comes up in SECONDARY ALONE state.
14 S2 OS: Connect the servers:
ADMIN COMMAND 'hsb connect';
The hsb connect command connects the new Primary server to the new Secondary and starts the process by which the new Secondary catches up on data changes that occurred while it was down.
If this step fails, copy the entire database to the Secondary server using hsb netcopy and then resume from step 12.
Results
After the new Secondary server catches up to the new Primary, your system should be operating normally. Both the new Primary and the new Secondary server have been upgraded and have the most current data.
What to do next
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 server and your Secondary server are working correctly. For example, you might choose the following sequence of operations:
On the Primary:
ADMIN COMMAND 'hsb state'; ADMIN COMMAND 'hsb status catchup';
Issue any type of read-only query.
On the Secondary:
ADMIN COMMAND 'hsb state'; ADMIN COMMAND 'hsb status catchup';