GT.M - Multi Site Replication Support on UNIX

In order to use replication in dual-site or multi-site mode on UNIX, new replication instance files need to be created. A REPLINSTFMT error occurrs if a replication instance file from a previous version of GT.M is used. A FILENOTFND error occurs if the instance file does not exist and replication is attempted.

The name given at the time of creating the instance file uniquely identifies the instance and is stored in the replication instance file.

The instance file serves as a repository of the history of the journal sequence numbers that are generated locally or received from other instances. The history is maintained as a set of records. Every record identifies a range of journal sequence numbers and the name of the root primary instance that generated those journal records. The first history record starts with the current journal sequence number of the instance. When a root primary and secondary communicate, the primary instance name is recorded in the replication instance file history of both the primary and the secondary as the instance that generated the transmitted journal sequence numbers. When a tertiary connects to a secondary, it is still the root primary instance name (not that of the secondary which serves as a propagating primary) that gets recorded in the tertiary instance file since that is the instance that actually generated the records. History records are always added to the tail of the instance file, the only exception being records removed from the tail of the instance file when updates are rolled back from the database as part of a mupip journal –rollback.

This history is crucial to determining the journal sequence numbers through which both instances are synchronized when a primary and secondary (or secondary and tertiary) attempt to connect. This journal sequence number is determined by going back in the history of both the instance files and finding the earliest shared journal sequence number that was generated by the same root primary instance. The receiver server on the secondary continues with normal replication only if the shared journal sequence number determined above matches the current journal sequence number of the secondary instance. Otherwise, a mupip journal –rollback –fetchresync must be performed on the secondary to rollback the secondary to a common synchronization point from which the primary can transmit updates to allow it to catch up. To avoid a possible out-of-sync situation, it is advisable, and safe even if it is not strictly necessary, so it can be unconditionally scripted, to perform a mupip journal -rollback -fetchresync prior to starting any source servers on the secondary instance.

Processes such as source servers, receiver server, and mupip rollback access this history. A REPLINSTNOHIST error message is generated if they attempt to look up a history record corresponding to a sequence number (for example, as part of a -rollback operation) that is less than the earliest sequence number recorded in the instance file.

A replication instance file maintains the current state of the instance and it is necessary to take a backup of this file that is consistent with the snapshot of the database files in the backup. Mupip journal -backup allows for the backup of the instance files at the same time that it backs up the database files.

The replication instance file on the primary stores the information pertaining to each secondary for which a source server is started and the journal sequence number that was last transmitted to that secondary. In prior versions of GT.M, this journal sequence number was maintained as Resync Seqno in the database file headers of all replicated regions and a dse dump -fileheader would display this information. With GT.M V5.1-000, this information is only available in the replication instance file and mupip replic –source –showbacklog command uses this information to display the backlogs for secondary instances.

The instance file has 16 slots to store information pertaining to a maximum of 16 secondary instances. Initially, all the slots are unused. A source server replicating to a secondary for the first time utilizes an unused slot to store the information related to that secondary and any future source server process replicating to the same secondary will update this information.

If an unused slot is not available, the first time the source server starts, the slot for the least recently started secondary is reused, assuming of course that the source server for the secondary is not alive, and the information that is previously stored in that slot is overwritten. Any subsequent mupip replic –source on the preempted secondary instance generates a REPLINSTSECNONE message.

	Preemption of slots is not an issue if the primary does not connect to more than 16 different secondaries throughout its lifetime.

If the replication instance file is damaged or deleted, a new instance file must be created, and all secondaries downstream must be recreated from backups.

An instance name must be specified when the replication instance file is being created using the –name qualifier in the command line.

The name identifies the replication instance to other instances, and it is immutable.

	In this rare instance, a GT.M command from a prior version is not upward compatible in GT.M V5.1-000.

If -name is not specified, mupip uses the environment variable gtm_repl_instname for the name. If that variable is not defined, the command issues a REPLINSTNMUNDEF error message. Using the environment variable allows pre-existing user replication scripts to run without any changes. Explicitly specifying the qualifier in the scripts improves clarity.

The name can be from 1 to 15 characters. Specifying a name longer than 15 characters or an empty string will issue a REPLINSTNMLEN error message.

If an instance file already exists, it is renamed with a timestamp suffix, and a new one is created. This behavior is similar to the manner in which GT.M renames existing journal files while creating new journal files.

Creating an instance file requires standalone access. A REPLINSTSTNDALN message is issued if the instance file is being used (i.e. the journal pool for that instance exists), while attempting to (re)create that instance file.

On a primary instance, a source server process runs for each secondary instance. The –instsecondary qualifier identifies the secondary instance to which a source server replicates the data. In GT.M V5.1-000, the following commands have been modified to include the –instsecondary qualifier. It is mandatory to specify the –instsecondary qualifier while issuing these commands.

   	mupip replic –source –start
   	mupip replic –source –deactivate
   	mupip replic –source –activate
   	mupip replic –source –stopsourcefilter
   	mupip replic –source –changelog
   	mupip replic –source –statslog
   	mupip replic -source -needrestart
	

If the –instsecondary qualifier is not specified, mupip uses the environment variable gtm_repl_instsecondary for the name of the secondary instance. If that variable is not defined, a REPLINSTSECUNDF error is issued.

	In this rare instance, a GT.M command from a prior version is not upward compatible in GT.M V5.1-000.

Specifying a name longer than 15 characters or an empty string issues a REPLINSTSECLEN error message.

The following source server commands now allow the –instsecondary qualifier as an optional qualifier:

	mupip replic –source –checkhealth
	mupip replic –source –showbacklog
	mupip replic –source –shutdown 
	

If the –instsecondary is not specified with the above commands or if the environment variable gtm_repl_instsecondary is not defined, the commands operate on ALL current active and passive source servers.

The secondary instance name needs to be specified explicitly (through the qualifier) or implicitly (through the environment variable) even for starting a passive source server. It is this secondary instance name that the passive source server will later connect to when it is activated.

If the secondary instance is unnamed, for example if the secondary instance is running an older version of GT.M, a dummy name suffices.

The above source server commands excepting the –start command look for an existing slot corresponding to the specified secondary instance in the replication instance file. If none is found, a REPLINSTSECNONE error is issued. In case of –start, GT.M looks for a previously used slot for that secondary instance. Failing that, it looks for an empty slot, and if none is available, it takes over the slot from the least recently used secondary instance. If there are already 16 source servers, there are no open slots, and a SRCSRVTOOMANY error is issued. If the name does not match the name sent by the receiver server on connection, a REPLINSTSECMTCH error is issued.

Defining the environment variable appropriately allows pre-existing user replication scripts to run without any changes. Explicitly specifying the qualifier in the scripts improves clarity.

The following source server commands now support –rootprimary and –propagateprimary qualifiers:

	mupip replic –source –start –secondary=...
 	mupip replic –source –activate
	mupip replic –source –start –passive
 	mupip replic –source –deactivate
 	

These are optional qualifiers. If not specified, a default value of –propagateprimary is used for the passive source server startup command as well as the deactivate command and a default value of –rootprimary is used for the other two commands. These default values enable users who are planning to limit themselves to one primary and multiple secondaries (without any tertiaries) to perform minimal changes, if any, to their replication scripts. However, it is recommended that these qualifiers be specified explicitly in the scripts, for clarity.

The –rootprimary or the –propagateprimary qualifiers are mutually exclusive.

Specifying –rootprimary either explicitly or implicitly enables GT.M updates on the specified replication instance.

Specifying –propagateprimary explicitly or implicitly disables GT.M updates on the replication instance. An attempt by a GT.M process to update a replicated region issues a SCNDDBNOUPD error.

GT.M V5.1-000 does not support the –update qualifier in the mupip replic –source command. In prior GT.M versions, mupip replic –source –deactivate disabled updates while –activate enabled updates. In GT.M V5.1-000, –rootprimary and –propagateprimary control whether updates are enabled or disabled.

	GT.M updates to replicated regions are permitted only on the root primary instance and disabled on ALL other instances (including secondary, tertiary, etc.).

	In this rare instance, a GT.M command from a prior version is not upward compatible in GT.M V5.1-000.

If –rootprimary is specified either explicitly or implicitly and the journal pool already exists and has updates disabled (i.e. journal pool was created by a source server startup command that explicitly or implicitly specified –propagateprimary), a PRIMARYNOTROOT error is issued. To transition a propagating primary instance to a root primary instance without bringing down the journal pool, issue a mupip replic -source -activate -rootprimary for an already running passive source server (start one with -propagateprimary if none is running).

If –propagateprimary is either explicitly or implicitly specified, the journal pool already exists and has updates enabled (i.e. journal pool was created by a source server startup command that explicitly or implicitly specified –rootprimary), a PRIMARYISROOT error is issued. It is not possible to transition a root primary instance to a propagating primary instance without bringing down the journal pool.

If journal pool already exists when source server startup is issued, prior versions of GT.M would issue a “Source Server already exists” error message. In GT.M V5.1-000, multiple source servers can be started from the same replication instance as long as each of them specify a different name for the –instsecondary qualifier. If a source server is started with a secondary instance name that matches the primary instance name, a REPLINSTNMSAME error message is issued. If a source server is started with a secondary instance name that has a corresponding source server already up and running, a SRCSRVEXISTS error message is issued.

On a root primary or propagating primary instance, multiple source servers cannot be started as long as there is one source server actively connected to a dual-site secondary (i.e. a secondary running on a version of GT.M that does not support multi-site functionality). An attempt to do so results in a REPLUPGRADESEC error. If an active source server on an instance finds more than one source server (active or passive) running on that instance at the time it connects to a dual-site secondary it issues a REPLUPGRADESEC error.

On a propagating primary instance, a source server that connects to a dual-site tertiary issues a REPLUPGRADESEC error. In addition, starting an active source server or activating a passive source server in a propagating primary issues a REPLUPGRADEPRI error if the receiver server is actively connected to a dual-site primary.

In an instance, a maximum of 16 active and/or passive source servers are allowed at any point in time. If 16 source servers are already running and another source server startup is attempted, it issues a SRCSRVTOOMANY error message.

To transition an instance from being a root primary to a secondary, it must first be brought back up as a secondary of the current (new) root primary instance. Bringing it up as a secondary causes a lost transaction file to be created. This lost transaction file needs to be applied on the current root primary instance followed by running a mupip replic -source -losttncomplete command on the current root primary instance (as discussed elsewhere, during this time, either the former root primary should be running as a secondary to the current root primary, or the mupip replic -source -losttncomplete command should be separately run on the former root primary). Once the mupip replic -source -losttncomplete command has been run, the former root primary instance can be brought up as the secondary of any propagating primary. An attempt to bring a former root primary up as a secondary of a propagating primary instance prior to the mupip replic -source -losttncomplete command causes the receiver server and the source server (running respectively on the secondary and primary instances) to issue a PRIMARYNOTROOT error, when they first communicate with each other.

	The former root primary instance can be brought up as the secondary of any propagating primary, once a mupip replic -source -losttncomplete command has been successfully run, either on the current (new) primary when the former root primary instance is connected to the current root primary, or when the command has been run separately on both the current primary and the former primary.

If the journal pool has updates enabled (i.e. journal pool was created by a source server startup command that explicitly specified or implicitly assumed –rootprimary), starting the receiver server on that instance issues a PRIMARYISROOT error message.

If the receiver server finds any active source server running on the secondary instance at the time it connects to a primary running a prior version of GT.M, which does not support multi-site replication, it issues a REPLUPGRADEPRI error.

If an instance transitions from being a root primary to a secondary, it is necessary that it be brought up as a secondary of the current root primary instance until a mupip replic -source -losttncomplete command has been run implicitly or explicitly on that instance. Not doing so causes the receiver server and the source server (running respectively on the secondary and primary instances) to issue a PRIMARYNOTROOT error, when they first communicate with each other.

Effective GT.M V5.1-000, the receiver server is an additional process attaching to the journal pool, which, means that the last source server running on any instance should be shutdown only after shutting down the running receiver server. Otherwise, a message is logged in the source server log indicating that the journal pool shared memory was not removed as processes were still attached to it.

If no source server is running for the secondary instance name specified in the activation command (the new -instsecondary qualifier), a SRCSRVNOTEXIST error is issued.

Assuming the passive source server is already running, there are four cases:

If no source server is running for the secondary instance name specified in the activation command (the new -instsecondary qualifier), a SRCSRVNOTEXIST error is issued.

Assuming the active source server is already running, there are four cases.

In the GT.M user documentation, unless the distinction is important in the context, a root primary is referred to simply as primary and a propagating primary is referred to simply as secondary. Note that any secondary can also be a propagating primary.

In order to bring up an instance as a primary, user startup scripts run the same steps they previously did to bring up the instance as primary. In addition, they can now bring up multiple source servers. As before, to create the journal pool, at least one source server must be brought up before any GT.M processes are activated. However, additional source servers can be brought up any time.

In order to bring up an instance as a secondary, user startup scripts run the same steps they previously did to bring up the instance as secondary. In addition, they can now bring up one or more active or passive source servers as well if they want to replicate to a tertiary. Note that the tertiary, if needed, can be brought up at any convenient time before or after the secondary is brought up. The replication stream between the secondary and tertiary is established when both are up & running, and connected to each other.

When a primary or secondary is upgraded to GT.M V5.1-000 and is brought up for the first time, the receiver server startup command on the secondary should additionally specify the –updateresync qualifier. Not specifying this qualifier causes the receiver server to fail at startup with a REPLINSTNOHIST message. The secondary can be shut down and brought up without the -updateresync qualifier only after at least one database update has been sent through the replication pipe and processed by the update process.

In order to bring down an instance that is running as primary ALL source servers (active or passive) running on the instance must be shut down. This means that one needs to first shut down all GT.M, mupip reorg, mupip load etc. processes that could be attached to the journal pool and then shut down all active and/or passive source servers (using individual mupip replic –source –shutdown -instsecondary commands or one mupip replic -source -shutdown command without an -instsecondary qualifier).

In order to bring down an instance that is running as secondary there is no change unless that secondary is also acting as a primary (i.e. that is a propagating primary). In such a case, after shutting down the secondary related servers (receiver server, update process and its helper processes), one also needs to shutdown the primary related servers (all active and/or passive source servers). In the secondary, there should not be any other GT.M or MUPIP processes attached to the journal pool as updates are disabled (they are enabled only on the primary). If there are processes like mupip reorg that operate on the database but do not attach to the journal pool, these processes also need to be brought down and finally a mupip rundown –reg * needs to be performed to ensure the database, journal pool and receive pool shared memory is all rundown.

At shut down, at least one source server – not necessarily, the one originally brought up first – must be the last GT.M process to be shut down, and it cleans up the journal pool when it exits.

Any instance can undergo one of the following four state transitions:

There is no change to the sequence of commands to shutdown a primary or secondary and bring it back as a primary or a secondary other than those already outlined in Starting up an instance or Shutting down an instance.

Some points to note are:

With GT.M V5.1-000, there are minor changes in the procedures used to recover the secondary when the databases/journals get out-of-sync with the primary.

The procedure to recover the secondary was to take an online backup of the primary databases, ship it to the secondary, create fresh journals on the secondary and start the receiver server on the secondary with the -updateresync qualifier. With GT.M V5.1-000, there is an additional step, which is to recreate the replication instance file (at the time fresh journals are created) with the same name, as before. Also, there are more choices in selecting the backup source. One can take an online backup from either the root primary or another secondary.

Optionally, to reduce network bandwidth and system load on the primary from which the new instance has to catch up, the mupip journal -recover -forward command was used to apply updates from journal files created on the primary subsequent to the backup before bringing the new instance up as a secondary. This procedure is now changed.

The new procedure to bring up a secondary instance from a backup is described below:

A mupip journal -rollback -fetchresync command is now always required whenever a secondary is brought up. Consider the case where A is replicating to B and C; B is replicating to D and C is replicating to E. After a failover in which B becomes the new primary, C needs to use the -fetchresync qualifier before coming up as a secondary to B. D continues operating normally. In the event C's -fetchresync requires it to rollback some transactions, E (and any other instances that are part of a tree with C as its root) also need to be brought down, and a mupip journal -rollback -fetchresync performed, before it can be brought back up again. When the original primary, A, becomes a new secondary (to B), it first needs to execute a mupip journal -rollback -fetchresync before it can become the secondary. These mupip journal -rollback -fetchresync commands potentially generate lost transaction files on the respective secondaries, but the only one that needs to be applied to B is the lost transaction file from A, the original primary. The format of the lost transaction file has therefore been altered to make it easy to distinguish whether the file needs to be sent to the new primary for reprocessing.

A new field in the first line of the lost transaction file identifies a lost transaction file that needs to be applied. Previously, the first line featured the format of the file as the first and only field and it was a string of the form GDSJEXnn where nn was the existing format of the lost transaction file.

The current version features multiple fields in the first line. These are as follows:

Except following a failover when the backlog is zero, whenever a former primary comes up as a new secondary, there is a lost transaction file. This lost transaction file should be applied at the new primary as soon as practicable, as, there could be additional lost transaction files in the event of other failovers, e.g., triggered by a failure of the new primary, before the lost transaction file is processed. These additional lost transaction files can complicate the logic needed for lost transaction processing.

Lost transactions can be applied on the new primary either manually or in a semi-automated fashion using the M-intrinsic function $ZQGBLMOD(). If $ZQGBLMOD() is used, two additional steps ( mupip replicate -source -needrestart and mupip replicate -source -losttncomplete ) are to be performed as part of lost transaction processing, regardless of whether replication is configured in dual-site or multi-site mode. Failure to run these steps can cause $ZQGBLMOD() to return false negatives that in turn can result in application data consistency issues.

MUPIP REPLIC –SOURCE –NEEDREST[ART]

The mupip replic –source –needrestart command should be invoked once for each lost transaction file that needs to be applied. It should be invoked on the new primary before applying lost transactions from that file. The –instsecondary qualifier needs to be specified in this command to provide the instance name of the secondary where this lost transaction file were generated. If not, the environment variable gtm_repl_instsecondary is implicitly assumed to hold the name of the secondary instance. If that is not defined either, a REPLINSTSECUNDF error is issued.

 mupip replic –source –needrestart –instsecondary=...
 

The purpose of this command is to check whether the primary ever communicated with the specified secondary instance (if the receiver server or a fetchresync rollback on the secondary instance communicated with the source server) since the primary was brought up. If so, this command displays the message SECONDARY INSTANCE xxxx DOES NOT NEED TO BE RESTARTED indicating that the secondary instance did communicate with the primary and hence does not need to be restarted. If not, this command displays the message SECONDARY INSTANCE xxxx NEEDS TO BE RESTARTED FIRST. In this case, the specified replication instance needs to be brought up as a secondary before the lost transactions from this file are applied. Failure to do so before applying the corresponding lost transactions causes $ZQGBLMOD() to return false negatives which can result in application data inconsistencies as mentioned earlier.

In the event the lost transaction file was generated from the same instance to which it is to be applied, a mupip replicate -source -needrestart command is not required, and if attempted results in a REPLINSTNMSAME error.

It is necessary for the secondary instance (specified in the -needrestart command) to be brought up as an immediate secondary of the current primary. If it is brought up as a tertiary to the current primary (through a different intermediate secondary instance), the -needrestart command unconditionally considers the tertiary instance as not having communicated with the primary even though the tertiary might be up and running.

	The source server on the primary and/or receiver server or fetchresync rollback on that particular secondary need not be up and running at the time this command is run. However, it is adequate if they were up at some point in time after the primary instance was brought up.

This command protects against a case where the primary instance when the lost transaction file is generated is different from the primary instance when the lost transactions are applied (note that even though they can never be different in case of a dual-site configuration, use of this command is nevertheless still required).

$ZQGBLMOD() relies on two fields in the database file header of the primary instance to be set appropriately. Prior versions of GT.M displayed one of these fields as Resync Trans (using the dse dump –fileheader command). This is now changed to Zqgblmod Trans in GT.M V5.1-000. A new field Zqgblmod Seqno has been introduced in GT.M V5.1-000 and it is displayed by the dse dump -fileheader command.

In a dual-site configuration, there are only two instances and both of them participate in the determination of the journal sequence number to which to roll back the secondary when a rollback –fetchresync is run. This makes it possible for both the instances to record the same sequence number information (Zqgblmod Seqno and the corresponding transaction number Zqgblmod Trans) in their respective file headers at the same time that lost transactions are generated without requiring any additional commands.

In a multi-site configuration, there are more than two instances, and no instances other than the primary and secondary involved in the rollback –fetchresync participate in the sequence number determination. Hence, they do not have their Zqgblmod Seqno (and hence Zqgblmod Trans) set when that particular lost transaction file is generated. If any of the non-participating instances is brought up as the new primary and that particular lost transaction file is applied on the primary, the return values of $ZQGBLMOD() will be unreliable since the reference point (Zqgblmod Trans) was not set appropriately. Hence, this command checks whether the secondary instance where the lost transaction was previously generated has communicated with the current primary instance after it came up as the primary. If it is affirmative, the Zqgblmod Seqno and Zqgblmod Trans fields would have been appropriately set and hence $ZQGBLMOD() values will be correct.

The -needrestart qualifier is incompatible with all source server qualifiers except -instsecondary.

  mupip replic –source –losttncomplete
  

This command is used to display or edit the contents of the replication instance file. The instance file name should be specified as the last parameter in this command. Not specifying the instance file name causes a MUPCLIERR error to be issued. Although editing the instance file does not require standalone access to the instance file, it should be avoided as far as possible when concurrent processes are reading/writing from/to it.

This command issues a FILENOTFND error if the instance file is not found and a REPLINSTFMT error message if the replication instance file was created by a GT.M version prior to V5.1-000.

The -editinstance qualifier is incompatible with other mupip replic qualifiers i.e. -receiver, -source, -updateproc, -updhelper, or -instance_create. To display the contents of the instance file use the -show qualifier i.e. a mupip replic –edit –show <instance-file> command. This command displays each of the following sections.

If an optional -detail qualifier is additionally specified, all fields within each section are displayed along with their offset from the beginning of the file and the size of each field. This is used when there is a need to edit the instance file. To edit any displayed field, use the -change qualifier. In addition, one can specify the offset to change using the -offset qualifier, the size of the change using the -size qualifier and the new value with the -value qualifier.

The entire command to effect any edits is mupip replic –edit –change –offset= -size= -value= <instance-file>.

The -size qualifier can be either 1, 2, 4, or 8 indicating the bytes to be changed. Specifying any other values causes a SIZENOTVALID8 error to be issued.

The -offset qualifier takes a hexadecimal value that is a multiple of the size qualifier; otherwise, an appropriate error message is issued. Similarly, if the offset specified is greater than the size of the instance file, an appropriate error message is issued.

The -value qualifier specifies the new hexadecimal value at the specified offset. Not specifying the -value qualifier displays the current value at the specified offset and does not perform any changes. Specifying –value makes the changes and both the old and new values are displayed.

The -detail qualifier is incompatible with –change. Only one of -change or -show can be specified in a single command line. The -offset, -size and -value qualifiers are only compatible with -change.

	The instance file should be edited only when so instructed by Fidelity GT.M Support.

The mupip replic -source -jnlpool command allows one to display and edit the contents of the journal pool. The -show qualifier displays the contents of the journal pool. The optional qualifier -detail prints offsets and size of each field.

Mupip replic -source -jnlpool -show –detail displays the contents of the journal pool along with the offsets.

The -change qualifier allows one to edit the journal pool contents. The additional qualifiers -offset, -size, -value specify the actual changes as in the mupip replic –edit[instance] command.

The -detail qualifier is incompatible with –change. Only one of -change or -show can be specified in a single command line. The -offset, -size and -value qualifiers are only compatible with -change.

	This command should be used only when so instructed by Fidelity GT.M Support.

In previous versions, dse dump -fileheader printed the field Resync Seqno, which represented the journal sequence number up to which both the primary and secondary are synchronized. With logical dual-site, there were only two instances at any point in time and hence from the perspective of each instance there is only one other instance. This made it possible to store the synchronization point with respect to the other instance in the database file headers of each instance. With multi-site, a given instance can act as a primary for more than one secondary instance and each secondary can be synchronized at different sequence numbers with respect to the primary. This information has been moved to the replication instance file where it is maintained separately for each secondary instance. In GT.M V5.1-000, dse dump -fileheader no longer prints the Resync Seqno field.

In prior versions of GT.M, Resync Trans was printed on the same line as Resync Seqno. This field is named Zqgblmod Trans in GT.M V5.1-000 and it serves as the reference transaction number for the M function $ZQGBLMOD(). In addition, the journal sequence number corresponding to Zqgblmod Trans is displayed in the place earlier occupied by Resync Seqno as Zqgblmod Seqno.

Thus, the last line of the dse dump -fileheader output will change from:

  Resync Seqno           0x0000000000000001  Resync Trans    0x0000000000000001
  

to

  Zqgblmod Seqno         0x0000000000000001  Zqgblmod Trans  0x0000000000000001
  

Due to the changes discussed in DSE DUMP -FILE, the dse change -fileheader command no longer supports the -resync_seqno and -resync_tn qualifiers. Instead, it supports -zqgblmod_seqno and -zqgblmod_tn in order to modify the Zqgblmod Seqno and Zqgblmod Trans fields of the database file header, respectively.

	In this rare instance, a GT.M command from a prior version is not upward compatible in GT.M V5.1-000.

If an instance transitions from being a root primary to a secondary, it is necessary that it be brought up as a secondary of the current root primary instance until a mupip replic -source -losttncomplete command has been run implicitly or explicitly on that instance. Not doing so, causes a PRIMARYNOTROOT error to be issued by any mupip journal -rollback -fetchresync command that is run on this former primary instance trying to start up as a tertiary. The source server on the propagating primary instance that the rollback communicates with also issues the same error. Note that once a mupip replic -source -losttncomplete command has been successfully run on the instance, the rollback command can be run to enable bringing up the instance as a tertiary instance.

With GT.M V5.1-000, mupip backup has the ability to take a consistent online or offline backup of the replication instance file through a new optional qualifier -replinstance=<destination-file-or-directory>.

If a destination directory is specified, the instance file is backed up in the destination directory with the same name as the instance file. This qualifier can be specified along with a list of database regions to backup in which case a consistent backup of the instance file as well as all the database regions specified is obtained as of the start of the backup. This qualifier can also be specified without any other database regions in which case only the replication instance file is backed up. In this case, none of the other mupip backup qualifiers is applicable.

Before using any features of the multi-site version of GT.M, both the primary and secondary in the existing dual-site configuration must be upgraded to the new version of GT.M that supports multi-site replication. This GT.M version upgrade can be done using a rolling software upgrade procedure that provides continuous application availability during the upgrade as discussed in the documentation and as summarized below.

Assuming that Site A and Site B are the two sites and that Site A is the primary before the upgrade, here are the steps to perform the rolling upgrade: