Basic application startup for each system is similar. The steps are modified for each scenario.
-
Determine current and prior system status (primary/secondary).
-
Perform necessary database recovery/rollback. Different failure modes have different recovery scenarios, which may include rollback of previously committed transactions for subsequent processing. Reconcile rolled back transactions automatically or manually.
-
Create new journal files. Although not required, this will simplify system administration.
-
Start the GT.M replication Source Server for this instance. For logical dual-site operation, you should bring up the Source Server on the secondary to establish the Journal Pool. In case of a failover, the new primary will need the Journal Pool to be established to replicate data to the new secondary. On the secondary, bring up the Source Server in passive mode. On the primary, bring up the Source Server in active mode.
-
Start the GT.M Receiver Server if this is the secondary instance.
-
If starting up as primary, start the application servers. The application servers can also be started on the secondary to facilitate a faster failover; however, it must be guaranteed that they do not perform updates of any replicated region on the secondary. GT.M replication does not explicitly check for this condition because when replication is being used as a real-time data feed from one application to another (as opposed to logical dual-site operation), concurrent updates to replicated regions on the secondary must be allowed.
-
If starting up as primary, and the state of the database indicates that batch operations were in process when the system went down, restart batch operations.
An initial startup of an application instance has no prior status. There are two ways to bring up a logical dual-site application: bring up the primary followed by the secondary, or bring both up at the same time.
When launching a dual-site application as a conventional single-site, versus launching it as a single-site for which a secondary will be launched later, the only difference is that the Journal Pool must be established 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 secondary 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. 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.
An external agent must determine which is primary and which is secondary when bringing up both sites simultaneously.
Both databases must be 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 primary and secondary do not have identical files, that is if they are logically identical but configured differently, ensure that at least one region on the secondary has reg_seqno and resync_seqno the same as the largest reg_seqno on the primary.) No rollback/recovery should be required on either site. If there is any possibility that the two are not identical, do not try to bring both up concurrently.
![[Note]](images/note.png)
|
Note |
|---|---|
|
Fidelity does not recommend starting both systems concurrently because of the possibility of a network or timing problem resulting in two primaries or two secondaries. |
Fidelity's recommended approach is to bring up the application as a single-site, and then bring up the secondary. Enable failover once the secondary catches up with the primary.
If restarting the secondary after a shut down, or after a crash that left the replicated regions untouched, simply starting it up will cause the primary to send transactions to it. It will automatically catch up once the Receiver Server is started. Do the following:
-
Recover/rollback database to last consistent state.
-
Create new journal files.
-
Start passive Source Server, and then the Receiver Server.
-
Start the passive application servers, if appropriate.
In this scenario, the database used to start up the secondary is logically identical to the database with which the primary started up, and has the same journal sequence number. When the secondary starts up, all transactions applied to the primary replicate to the secondary, while the secondary "catches up" with the primary. Do the following:
-
Load/restore the database.
-
Create new journal files.
-
Start passive Source Server, and then the Receiver Server.
-
Start the passive application servers, if appropriate.
Since the Source Server goes to the journal file to read transactions that are no longer in the journal pool, preserve all journal files on the primary along with the back pointers. This scenario is most applicable when it is not expected that the primary will be operational long before the secondary is up.
|
|
Note |
|---|---|
|
All GT.M activity in the secondary instance must cease and any open database files must be run down before copying database files onto the secondary, or creating new database files and loading them with the extracts from the primary. |
The more common scenario for bringing up the secondary from the primary is to take a backup from the primary, transfer it to the secondary, and bring up the secondary. If the backup is a comprehensive backup, the file headers will store the journal sequence numbers.
The backup should use the /NEWJNLFILES switch of MUPIP backup to create new journal files. Once the secondary becomes operational, the Source Server will not need to go back prior to the backup to find transactions to send to the secondary.
Perform the following steps:
-
Load/restore the database. If the secondary database is not the comprehensive or database backup from the primary set, the journal sequence number from the primary at the instant of the backup must be set in the database file for at least one replicated region on the secondary.
-
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. Since the primary stores the last journal sequence number transmitted to the secondary, this qualifier is required to force replication to start from the actual journal sequence number in the secondary database. If it is not used, the Receiver Server may refuse to start replication since the journal sequence number in the secondary will be ahead of the journal sequence number at which the primary expects it to be.
-
Start the passive application servers, if appropriate.
-
Since the primary should not need to be rolled back to a state prior to the start of the backup, the generation link on the primary can be cut in the journal files created by the online backup command on the primary system. Use MUPIP SET /JNLFILE <JNL_FILE> /NOPREVJNLFILE to cut the generation link for the journal file <jnl_file><JNL_FILE>. Use the /BYPASS qualifier to override the standalone requirements of the set comma