Promoting and monitoring replication

Promoting and monitoring replication

This page covers checking on the state of your replicated volumes and promoting a secondary volume to primary — the operation you'd use for a planned failover, a DR test, or a real recovery after losing the primary system. See Replication for what primary/secondary roles and promotion mean conceptually.

Checking replication status

Listing replication shows every replicated volume, its role (primary/secondary), and — per remote system it's paired with — the connection status and how far in sync it is. Use this before you promote anything, to make sure the volume you're about to fail over to is actually current.

Using the web interface

Open Application Volumes > Replication. The list shows every replicated volume; use the toolbar to filter to a specific application/volume, or to show only primary or only secondary volumes.

Using the CLI

replication continuous list [--application=<name> --volume=<name>] [--filterSecondary|--filterPrimary]

Option	Description
--application=<name>	Filter by application name.
--volume=<name>	Filter by volume name.
--filterSecondary	Show only secondary volumes.
--filterPrimary	Show only primary volumes.

Examples

List every continuously-replicated volume:

replication continuous list

List only the volumes that are currently secondary on this system — a useful check before a mass promotion:

replication continuous list --filterSecondary

Check the replication status of one specific volume:

replication continuous list --application billing --volume orders

Waiting for sync to finish

replication continuous wait_sync is a scripting convenience: it blocks and returns nothing until every matching replication pair reaches 100% sync, then exits. Use it in a script before a planned promotion, to make sure you're not about to fail over to a volume that's still catching up.

Using the CLI

replication continuous wait_sync [--application=<name> --volume=<name>]

Option	Description
--application=<name>	Wait for this application only.
--volume=<name>	Wait for this volume only.

Example — wait for orders to fully sync before scripting a promotion:

replication continuous wait_sync --application billing --volume orders

Promoting a secondary volume to primary

Promoting switches a secondary volume's role to primary (and the current remote primary becomes secondary). You can select what to promote three ways: specific volumes (--application/--volume), one or more entire consistency groups by ID (--cgids), or every secondary volume on this system at once (--allSecondaryVolumes, typically used for a full site failover). Promoting by consistency group or with --allSecondaryVolumes ensures everything that needs to move together — like a database and its log — is transitioned in the same operation.

You can also migrate paired client-facing floating IPs to this system as part of the same promotion, so clients can reconnect through the same address immediately after the cutover — either specific inactive floating IPs (--inactiveFloatingIpsToActivate) or all of them (--activateAllInactiveFloatingIps). See Floating IPs for how floating IP pairing works in general.

What --force actually does here

Without --force, StorONE refuses to promote a volume unless it's confirmed up to date and the replication link to it is connected. --force skips both of those checks — you can promote a volume that's behind or disconnected, which is exactly what you'd need to do during a real disaster recovery where the old primary system (and its more current data) is gone and unreachable. Used this way, --force isn't just skipping a confirmation prompt; it's a deliberate "promote anyway, accepting the data loss" decision.

Using the web interface

1. Open Application Volumes > Replication.
2. Select the secondary volume(s) (or consistency group) and click Promote to Primary.
3. Under Secondary Volume or Consistency Group Selection, confirm the Application/Volume, Consistency Groups, or All Secondary Volumes selection.
4. Under Floating IPs Selection, optionally choose specific Inactive Floating IPs to Activate, or Activate All Inactive Floating IPs.
5. Confirm the promotion — read the warning carefully if any selected volume isn't up to date.

Using the CLI

replication continuous promote_primary
    (--application=<name> --volume=<name...>)|--cgids=<numbers...>|--allSecondaryVolumes
   [--inactiveFloatingIpsToActivate=<name...>|--activateAllInactiveFloatingIps]
   [--force]

Option	Description
--application=<name>	Application the secondary volume resides in.
--volume=<name...>	Secondary volumes to switch to primary (and the remote primary volume to secondary).
--cgids=<numbers...>	Transition specific consistency groups by ID.
--allSecondaryVolumes	Transition all secondary volumes to primary.
--inactiveFloatingIpsToActivate=<name...>	Migrate the IPs to these paired inactive floating IPs.
--activateAllInactiveFloatingIps	Migrate the IPs to all paired inactive floating IPs.
--force	Skip the confirmation prompt, and allow the transition to proceed even if the volume is not up to date or the replication link is disconnected.

Examples

Promote a specific continuously-replicated volume during a planned DR test, once it's confirmed in sync:

replication continuous promote_primary --application billing --volume orders

Force-promote every secondary volume on this system during an actual disaster recovery, when the original primary system is gone, and bring the client-facing floating IPs along with it:

replication continuous promote_primary --allSecondaryVolumes --activateAllInactiveFloatingIps --force

Promote a whole consistency group in one operation:

replication continuous promote_primary --cgids 42

---

See also: Replication · Starting and stopping replication · Replication witness · Floating IPs