With GT.M replication, you can create a logical multi-site (LMS) configuration for mission critical applications that must always be available not only in face of unplanned events (such as system or data center failures) but also in the face of planned events such as computing platform upgrades, OS upgrades, GT.M upgrades and even application upgrades. Deploying an LMS configuration should take into account available network capacities, operational preferences, risk assessments, and business continuity requirements.

The L in LMS stands for Logical--all instances in an LMS configuration are logically equivalent in that under quiescent conditions, all instances have not only the same database state but also the same path through state space. A replicating instance is not an exact copy of the originating instance. Rather, a replicating instance receives the same update records (M Sets or Kills) for an M global node on the originating instance. These M global variable nodes are independent of the underlying database configuration, operating system, application version, or even GT.M version. An originating instance may have data in its database that is relevant only locally. For example, the database may store the ids of currently active processes. These process ids are meaningless on other instances and indeed are also meaningless on the same instance after a reboot. There is nothing to be gained by replicating these M global variable nodes to other instances. Other global variables may be scratch global variables--variable in the temporary working space that hold information valid only till the completion of a task. You can place these in one or more separate database regions that are neither replicated nor journaled.

GT.M replication mechanism is designed in such a way that a network failure between instances will not stop an application from being available-which is a limitation of techniques such as high availability clustering^[4]. There are mechanisms in place for edge cases like processing "in flight" transactions and common cases like handling backlog of updates after recovery from a network failure. While it is not possible to provide absolute continuity of business in our imperfect universe, an LMS configuration gives you the flexibility to choose application configurations that match your investment to a risk level that best meets the business needs of your organization.

By definition, "in-flight" transactions are those transactions that have been committed (or hardened, or made Durable) on an originating instance (or a propagating instance) but not yet transmitted to a replicating instance.