To start HSB replication, the databases on the Primary and Secondary must be identical. The secondary database must be an exact copy of the primary database. The process of making the databases of a HotStandby system identical is called HotStandby synchronization.
The Primary and Secondary must be synchronized, for example, in the following situations:
▪The Secondary is new and does not yet have a copy of the Primary database to start with.
▪The Secondary was not running for awhile and its copy of the data is not up-to-date.
▪Both the “Primary” and the “Secondary” were running in Primary Alone state at the same time, and thus have conflicting data.
▪The Secondary disk drive fails, or the file is corrupted and must be replaced.
There are two main ways of synchronizing the data on the servers: catchup and full copy.
Catchup
Catchup can be used if and only if the Primary server has stored a copy of all of the transactions that the Secondary server “missed” while the servers were disconnected. If the Primary has stored all those transactions, when it is reconnected to the Secondary, it automatically forwards those transactions to the Secondary so that the Secondary can catch up with the Primary.
The solidDB® server stores transactions (to forward to the Secondary) only while it is in the PRIMARY ALONE state, not while it is in the STANDALONE state or is operating as a non-HotStandby server. Therefore, if the server has been in STANDALONE state or has been operating as a non-HotStandby server since it last was connected with the Secondary, it does not have all the transactions and cannot do catchup. Instead, you must do a full copy.
There is no explicit catchup command. The servers try to catch up automatically when you connect them using the ADMIN COMMAND 'hotstandby connect' command.
When the Primary and Secondary are connected, they automatically check to see whether the Primary server has data in its transaction logs to send to the Secondary. If the data is there, the servers automatically attempt to catch up.
During the catchup process, the Primary and Secondary servers stay in PRIMARY ALONE and SECONDARY ALONE states. Clients can continue to submit queries and commit transactions. The catchup process is transparent to the client applications.
If the servers recognize that the Primary and Secondary databases are not identical even after the transactions are copied from the Primary to the Secondary, you will get an error message.
If catchup fails (or if you know ahead of time that it will not work because the Primary server was in STANDALONE state, for example), you must do a full copy.
Catchup applies only when the Secondary has already been running in SECONDARY ACTIVE state at some point. If you have a brand new Secondary server, and even if the Primary was running in PRIMARY ALONE state and has stored all transactions since the time that the Primary itself started, you must do a full copy to give the Secondary its initial copy of the database.
A full copy is just what its name implies: copying all the data from the Primary to the Secondary. Full copy is made by copying the database files themselves.
Full copy is used in the following situations:
▪The Secondary server is brand new and is getting its initial copy of the Primary database.
▪The Primary server has written transactions when it was not in the PRIMARY ALONE state, and therefore catchup is not possible.
▪The Secondary database is corrupted or missing.
▪The Secondary is diskless and has failed. When a Secondary diskless server is started after a failure, the diskless server requires a complete copy of the database by using the hotstandby netcopy command. Unlike a disk-based Secondary, the Secondary diskless server cannot read the transaction log and apply the changes that occurred while it was inoperable.
▪The Primary server has all of the data that is needed for catchup, but catchup is expected to take longer than copying the current data files.
CAUTION: If the Secondary server has old database files, a full copy writes over those old files. If for any reason the files on the Secondary contain data that was not in the Primary (for example, if both servers were operating in PRIMARY ALONE state at the same time), that data is lost.
There are two HotStandby commands that can do a full copy, that is, they copy the database files from the Primary to the Secondary. You can use either of the following commands:
The netcopy operation copies the database over the network to a Secondary server that is running and can receive the files over the network. The copy operation copies the database files to a specified disk drive directory that is visible to the Primary server. The secondary server must not be running during the copy operation. The netcopy command is usually preferable to the copy command, so most of the examples show only netcopy, not copy.
1 Secondary is down for a long time so the Primary stops using the transaction log to store details of the secondary. The log is still used for local recovery.
2 Secondary is down for a long time so the primary stops using the transaction log to store data for the secondary. The log is still used for local recovery.
3 Primary database is copied to the secondary node and the primary starts writing to the transaction log.
4 Database is copied and the primary sends transaction log file changes to the secondary.
Note The preceding diagram oversimplifies the usage of the transaction log. In the first part of the diagram, when the Primary and Secondary are not connected, the Primary actually continues to write data to the transaction log, but keeps only enough data for recovery, not enough to allow the Secondary to catch up with all the changes since the connection was broken.
Using a watchdog to synchronize servers
The commands synchronize servers manually can also be used by a watchdog program to synchronize servers automatically.
If catchup is sufficient, all that the watchdog must do is monitor the Secondary to see when it comes up, and then issue the command to connect the Primary to the Secondary. If a full copy is required, the watchdog can instruct the Primary server to do a netcopy operation. A full copy writes over any data on the Secondary.
Copying a primary database to a secondary over the network
To send a copy of the database file from the Primary server to the Secondary server, use the netcopy command. The Secondary server must already be running.
Before you begin
▪To start the netcopy operation, the Primary server must be in PRIMARY ALONE state.
▪To use data compression during the netcopy operation, set the HotStandby.NetcopyRpcCompressparameter to yes.
About this task
There are two main situations in which you use netcopy to create a copy of the database for the Secondary server:
▪You want to create a database for a brand-new Secondary that has never had one before. This method is also used to copy a database to a diskless Secondary, since after a failure it loses its entire database and must be treated as a brand-new Secondary.
▪You want to replace an existing Secondary database. For example, one that has been corrupted.
Procedure
To start the netcopy operation, issue the following command:
ADMIN COMMAND 'hotstandby netcopy';
When the Primary does a netcopy, the Primary uses the connect string that is specified in the [HotStandby]section of solid.ini.
When you execute the hotstandby netcopy command, a database checkpoint is created before the copy of the Primary database is sent to the Secondary.
The Primary continues accepting transactions and connections during the netcopy (however, any ADMIN COMMAND that changes the server state are rejected.) The Secondary does not continue accepting transactions and connections. When the netcopy starts, if the Secondary has any open connections or transactions, it rolls back the open transactions and disconnect from its clients, it starts receiving the netcopy. While the Secondary receives the netcopy, the Secondary communicates only with the Primary server.
When the netcopy is completed successfully, the Secondary state changes to SECONDARY ALONE (if it was not already in that state).
The Primary server stays in the PRIMARY ALONE state during the netcopy operation. After the netcopy is completed, the Primary server continues to stay in the same state. Before you can resume full hot standby operations, you must connect the Primary and Secondary servers. Connecting the servers sets the Primary server to PRIMARY ACTIVE state. For information about connecting the servers, see Connecting HotStandby servers.
Normally, when you start the solidDB® server, it prompts you to create a new database if there is not already a database. However, if the server is a Secondary server, it must use a copy of the Primary database rather than create its own database. Therefore, when you start a Secondary server that does not have an existing database, you must give it a command-line parameter to tell it to wait to receive a copy of the database from the Primary. The command-line parameter is ‑x backupserver. For example, you start the Secondary server with the command:
solid -x backupserver
The space between the -x and backupserver is optional.
The -x backupserver command-line parameter sets the server into netcopy listening mode (also called backup listening mode). In the netcopy listening mode, the only possible operation for the Secondary server is to receive a database copy from the Primary server. The Secondary does not respond to any other command, and it does not even accept a connection request from a client program such as solsql, your application, or a watchdog program.
If there is a Secondary database, you can start the server in a normal way. The server starts in the SECONDARY ALONE state.
After the Secondary has been started with -x backupserver, or is in the SECONDARY ALONE state, you can execute the netcopy command on the Primary.
First, make sure that the Primary is in PRIMARY ALONE state. Then, issue the following command on the Primary:
ADMIN COMMAND 'hsb netcopy';
On the Primary, the hotstandby netcopy command uses the connect string that is defined with the Connect parameter in the solid.ini configuration file to connect to the Secondary server. After the servers are connected, the Primary copies the database files through the network link. In the netcopy listening mode, the Secondary server attempts to open the Secondary database only after it has received a new database copy through the hotstandby netcopy command at the Primary.
This procedure creates the Secondary database copy:
1 Ensure that you have configured the solid.ini file so that it is valid for the HotStandby configuration. For more information about the Connect parameter, which defines the connect string, see Defining primary and secondary node HotStandby configuration.
The connect string is used to connect to the Secondary server from the Primary and to copy the database files over the network.
2 Start the Primary server.
3 Start the Secondary server in netcopy listening mode by executing the following command:
solid -x backupserver
Or, alternatively, start the Secondary server with an existing database.
4 Set the Primary server to PRIMARY ALONE state if it is not already in that state:
ADMIN COMMAND 'hotstandby set primary alone';
5 Issue the following command at the Primary server:
ADMIN COMMAND 'hotstandby netcopy';
6 After the netcopy has completed, you can connect the two servers and start (or resume) full hot standby operation by issuing the command:
ADMIN COMMAND ‘hotstandby connect';
When the Secondary server receives a new copy of the database through the network link, it opens the Secondary database. After the servers are connected (with the hsb connect command), the Secondary server runs in its normal SECONDARY ACTIVE state and is ready to accept user transactions from the Primary.
If HAC is used, the procedure to get the Primary server database copied to the Secondary is as follows:
▪Ensure that the servers have the correct Connect parameters.
▪Ensure that the HAC in Primary node has the PreferredPrimary=Yes parameter set in solidhac.ini, and that the HAC in the Secondary node does not. For further information of configuring HACs see Configuring HA Controller and HA Manager.
▪Start the HAC instances, or optionally set HACs to the AUTOMATIC mode.
Note If netcopy is sent to a server that is in the SECONDARY ALONE state, the existing database is overwritten with the copied database. Netcopy is useful if you want to resynchronize databases or repair a corrupted Secondary database.
Replacing an existing database on the secondary server
Although netcopy is used primarily to send a database to a Secondary that has never had a database before, netcopy can be used in other situations as well. For example, if the Secondary copy of the database is corrupted, for example, after a disk drive failure, you can send the Secondary a copy of the Primary database by using the netcopy command.
Before you begin
If you are replacing an existing database, then the Secondary server does not have to be in “netcopy listening mode”; in other words, you do not have to start the Secondary server with -x backupserver.
Procedure
1 Make sure that the Primary is in PRIMARY ALONE state and the Secondary is in SECONDARY ALONE state.
2 Issue the following command to the Primary:
ADMIN COMMAND 'hotstandby netcopy';
After netcopy completes, the Primary server is in PRIMARY ALONE state and the Secondary server is automatically put into SECONDARY ALONE state (if it was not already in that state).
If you do a netcopy while the Secondary is in SECONDARY ALONE state, and if any clients are connected to the Secondary (to do read-only queries), then the Secondary server rolls back any open transactions and breaks any client connections. Once the netcopy is completed, the Secondary server remains in the SECONDARY ALONE state.
3 The servers do not connect automatically: To connect the servers, issue the following command:
When you start a netcopy command, it runs asynchronously in the background. The servers do not display a message when the netcopy completes; instead, you have to monitor the status of the netcopy.
About this task
The servers do not display a message even if the netcopy fails due to a problem such as a network error.
Procedure
Issue the following command at the Primary server:
ADMIN COMMAND 'hotstandby status copy';
Note The command uses the keyword copy, not netcopy. The same command is used for both the copyand netcopyoperations.
The command displays a status message that indicates whether the netcopy was successful, is still in progress, or failed.
Copying a database file from the primary server to a specified directory
If the directory that the Secondary uses for the database is visible to the Primary, you can use the hotstandby copy command to copy the database from the Primary to the Secondary.
Before you begin
This task is only possible in cases where the Primary and Secondary servers can see some of the same disk drives and therefore can read and write some of the same directories.
CAUTION: Before you issue the hotstandby copy command, shut down the Secondary server. The Secondary server must not try to access the database file while the Primary is writing that file.
Note The Primary server must be in PRIMARY ALONE state when you issue the hotstandby copycommand, and the Primary server remains in that state during (and after) the command.
About this task
The key difference between the hotstandby copy command and the hotstandby netcopy command is that the netcopy command can be used only when the Secondary is running. The copy command can be used only when the Secondary server is not running. Performance-wise, there is no significant difference between the two database copy methods.
Procedure
1 To copy the file by using hotstandby copy, issue the following command at the Primary server:
ADMIN COMMAND 'hotstandby copy[directory_name]';
where directory_name is the name of the directory that you want to copy the file to. The format of the directory name is operating system dependent. The directory name is optional. If you do not specify a directory name, then the server uses the value that is specified by the HotStandby.CopyDirectory parameter.
When you issue the hotstandby copy command, the server creates a checkpoint and makes a copy of the Primary database before it sends the copy to the Secondary.
Since the server is in PRIMARY ALONE state, transaction processing on the Primary continues normally during the copy command, and the Primary stores the transactions in the transaction log so that they can be forwarded to the Secondary later.
2 After a copy operation, the Secondary is still down. You must bring it back up and then issue the hotstandby connect command to connect the two servers.
When the Primary database is connected to the Secondary using the administrative command hotstandby connect, the Primary and Secondary servers automatically perform “catchup” to bring the Secondary up-to-date.
After the Primary is connected to the Secondary, the Primary server and Secondary server automatically start performing catchup. During catchup, the Primary server brings the Secondary database up-to-date by copying the Primary transaction log to the Secondary. Then the Secondary rolls forward the transaction log and updates its copy of the database.
