An initial startup of an application instance has no prior status. There are two ways to bring up an LMS application: bring up the originating instance followed by the replicating instance, or bring both up at the same time.
Single-Site
When launching a multi-site application as a conventional single-site, versus launching it as a single-site for which a replicating instance will be launched later, always establish the Journal Pool before any M processes access the database. Bring up the Source Server in passive mode to create the Journal Pool. Then bring up the application. Later, switch the Source Server to active mode when the replicating instance comes up.
Perform database recovery/rollback to the last consistent state, since the system may previously have crashed. If the database was shut down cleanly, the recovery/rollback to the last consistent state is essentially a "no-op." This operation restores the database to the last committed transaction. (This assumes there is no media damage.)
Create new journal files.
Start the Source Server in passive mode.
Start the application servers.
If the state of the database indicates that batch operations were in process, restart batch operations.
Dual-site - Concurrent Startup
FIS does not recommend concurrent startup of instances in an LMS configuration because of the possibility of a network or timing problem resulting in multiple originating or replicating instances. However, in a dual-site configuration it is possible to concurrently startup the originating and replicating instance. The steps are as follows:
Use an external agent to identify the originating and replicating instances and then bring up both sites simultaneously.
Ensure that both databases are logically identical and have the same journal sequence number. (When starting up, an instance considers its journal sequence number to be the maximum reg_seqno of any replicated region. Thus, if the originating instance and its replicating instance do not have identical files, that is if they are logically identical but configured differently, ensure that at least one region on the replicating instance has reg_seqno and resync_seqno the same as the largest reg_seqno on the originating instance.) No rollback/recovery should be required on either site.
If there is any possibility that the two are not identical, do not bring both up concurrently.
Single-Site to Multi-Site
FIS recommends you to bring up the application as a single-site first and then bring up any replicating instances.
Replicating Instance Starts after a Shut Down or Crash
If the replicated regions are untouched after a shutdown or crash, simply restart the replicating instance. It automatically catches up with the originating instance. Perform the following steps to start a replicating instance after a shutdown operation or a crash:
Recover/rollback database to last consistent state.
Create new journal files.
First start the passive Source Server and then the Receiver Server.
Start the passive application servers, if appropriate.
Replicating Instance Starts from a copy of Originating Instance
In this scenario, the database used to start up a replicating instance is logically identical to the database with which the originating instance started up, and has the same journal sequence number. When the replicating instance starts, all transactions applied to the originating instance replicate to the replicating instance as it catches up with the originating instance.
Perform the following steps to start a replicating instance from a copy of the originating instance:
Load/restore the database files.
Recreate the replication instance file.
Turn replication on.
Start passive Source Server, and then the Receiver Server.
Start the passive application servers, if appropriate.
Preserve all journal files on the originating instance along with back pointers. This is because the Source Server goes to the journal file to read transactions that are no longer in the journal pool.
![[Note]](images/note.jpg) | |
Cease all GT.M activity in the replicating instance and RUNDOWN any open database files before copying database files onto a replicating instance, or creating new database files and loading them with extracts from the originating instance. |
Replicating Instance Starts from Backup of Originating Instance
The more common scenario for bringing up a replicating instance is to take a backup of the originating instance and bring it up as a replicating instance. If the backup is a comprehensive backup, the file headers store the journal sequence numbers.
The backup should use the -newjnlfiles switch of MUPIP backup to create new journal files. Once the replicating instance becomes operational, the Source Server does not need to go back prior to the backup to find transactions to send to the replicating instance.
Perform the following steps to start a replicating instance from the backup of an originating instance:
Load/restore the database. If the replicating database is not from a comprehensive or database backup from the originating instance, set the journal sequence number from the originating at the instant of the backup for at least one replicated region on the replicating instance.
Create new journal files without back pointers to previous generations of journal files with the -noprevjnlfile flag. Since this database represents the beginning of this instance, it is not meaningful to have a previous generation journal file.
Start the passive Source Server and then the Receiver Server with the -updateresync qualifier, along with the other startup qualifiers for the Receiver Server. As the originating instance stores the last journal sequence number transmitted to a replicating instance, this qualifier is required to force replication to start from the actual journal sequence number in the replicating instance. Without -updateresync, the Receiver Server may refuse to start replication because the journal sequence number in the replicating instance may be higher than what the originating instance expects.
Start the passive application servers, if appropriate.
Since the originating instance should not need to be rolled back to a state prior to the start of the backup, the generation link on the originating instance can be cut in the journal files created by the online backup command on the originating instance. Use MUPIP SET -jnlfile <jnl_file> -noprevjnlfile to cut the previous generation link for the journal file. Use the -bypass qualifier to override the standalone requirements of the SET command.