Cross-site Replication Concepts

Cross-site replication is a feature that is used for disaster recovery. Using cross-site replication, you can dynamically backup your primary metaspace to a passive metaspace located at a remote site.

The objective of cross-site replication is to maintain two sites in different geographical locations with the same set of data. If a disaster strikes, the remote site or the Disaster Recovery (DR) site should be able to take over for the local or the primary site with very little data being affected.

As you transact with the primary site, you can plan for your data to get backed up on the DR site asynchronously. The replication happens in one direction that is from the primary site to the DR site.

With the help of cross-site replication, you can replicate the following to a DR site:
  • PUT and TAKE operations happening on all spaces of a metaspace
  • Transactions
Cross-site replication can be incorporated into new or existing deployments of ActiveSpaces using the following components:
  • as-router executable that is responsible for transmitting PUT and TAKE operations and transactions between sites.
  • command-line options in the as-agent executable.
  • as-admin commands.
  • Java APIs.

Planning Cross-site Replication

To implement cross-site replication effectively, plan the following:
  • Identify a primary site, or the local site. The metaspace on the local site becomes the primary metaspace. This site is usually active. If you have an existing ActiveSpaces system, the existing system would be your primary site. At any point in the discussion of cross-site replication, the terms active and local site are used to refer to the primary site.
  • Identify a DR site, or the remote site, that is in a different geographical location. The metaspace on the remote site that is used for the fail-over becomes the secondary metaspace. This site is usually passive. At any point in the discussion of cross-site replication, the terms passive, remote, or secondary site are used to refer to the DR site.
  • Both, the primary and secondary metaspace must have the same name, but can have different discovery URLs.
  • Both the primary and secondary metaspaces must have the same spaces defined with the same fields and keys.
  • Typically, both metaspace clusters are mirror images of each other with the same number of as-agents, as-routers, space replication factor, and persistence modes. But, this can vary between sites as long as the differences between sites meets your disaster recovery requirements. Cross-site messages contain the operation to be performed and the data. No checking is done to ensure the space definitions between sites match. So as long as the space definitions on the DR site can handle the data being sent from the primary site, other properties of the space definitions, such as persistence, replication, or min seeder count, on the DR site can be varied to suit your needs.
  • Determine the number of as-routers to run which keeps the number of pending operations waiting to be sent to the remote site to a minimum.
  • Determine a strategy for switching your clients to using the secondary metaspace and back again as the need arises.

  • Determine a strategy for loading and synchronizing data between the primary and secondary metaspaces when both metaspaces are first brought up or when one of the metaspaces is taken down and then brought back up.

Cross-site Replication Between Two Sites
Cross-site Replicattion

Limitations

  • Multi-site replication is not supported.
  • Active-Active mode of replication is not supported. Only Active-Passive mode of replication is supported where in the primary site is active and the DR site is passive.
  • Security is not supported.
  • Cross-site replication is unidirectional. Replication occurs only from the primary site to the DR site.
  • Cross-site replication cannot be used with space routing. These two features are mutually exclusive.
  • Selection of individual spaces to be replicated is not supported.
  • Automatic failover is not supported. Switching over to using your DR site as the primary site is a manual process.
  • Space creation on one site is not automatically duplicated on the other site. For cross-site replication to succeed, each space must be predefined on both, the primary and DR site.
  • Cross-site replication only replicates PUT and TAKE operations and transactions across sites. It does not automatically create metaspaces, members, spaces, and so on, on the DR site. This process must be done separately for each site involved in cross-site replication.
Warning: For spaces with LRU and no persistence defined, when tuples are evicted from the local site, there is no guarantee that the same set of keys are evicted from the remote site.