Skip to content

System Sync

System Sync replicates system data from one RansNet gateway to another. It serves two distinct purposes:

  • High Availability (HA) — combined with VRRP or route tracking, the secondary unit automatically takes over as primary if the first unit fails, so service continues with minimal disruption.
  • Backup — even without automatic failover, System Sync keeps a continuously up-to-date copy of a unit's data on a second unit, for disaster recovery or manual cutover. In this mode, no automatic role switching is configured — the secondary stays read-only until an administrator manually promotes it.

This feature applies primarily to mfusion, HSG, and mlog models. It's a fixed, minimal-configuration feature by design — an administrator only identifies the peer and (for HA modes) how to determine which unit is primary; what data gets synchronized and how it's transported is handled automatically and isn't a separate set of options to configure.

Overview

System Sync keeps two categories of data identical between the peers:

  • Databases — the admin database, user/account databases, hosts, entities, and other application data used by mfusion, HSG, mlog, and Ads modules.
  • Files — supporting data that isn't stored in a database, including reports, backups, release files, OpenVPN certificates, and WireGuard peer keys (where configured).

A unit's role (primary or secondary) determines the direction of replication and which unit accepts writes:

  • Primary — read/write. Accepts configuration changes, dashboard logins, and application writes.
  • Secondary — read-only. Continuously receives replicated data from the primary; does not accept writes.

Deployment Modes

System Sync supports three deployment modes, depending on whether you need automatic failover and where the two units are located:

Mode Description Role Determination
Localized HA Both units are at the same site, on the same network segment; failover is automatic. VRRP VIP ownership — whichever unit holds the VIP is primary.
Offsite HA Units are at different sites/networks (e.g. DC and DR), each advertising the same mfusion IP (typically a loopback) into a routed network such as BGP; failover is automatic. Routing table — whichever unit currently has the tracked route (via BGP or a tracked static route) is primary.
Backup Only No automatic role switching — the secondary stays permanently read-only, continuously synced, until manually promoted. Useful for disaster recovery where a controlled, deliberate cutover is preferred over automatic failover. Manual — an administrator runs promote/demote on each unit as needed.

Determining System Role

For the two automatic (HA) modes, each unit independently determines its own role by checking whether a tracked condition is currently true locally, at a regular interval — it does not coordinate directly with its peer to decide this.

track-ip x.x.x.x [interval]
track-route x.x.x.x/yy [interval]
Command Checks Use With
track-ip x.x.x.x [interval] Is this address currently present on one of this unit's own interfaces? Localized HA (VRRP)
track-route x.x.x.x/yy [interval] Does this exact prefix currently exist in this unit's routing table? Offsite HA (BGP / tracked static routes)

interval is the poll interval in seconds and is optional (default 30). track-ip and track-route are mutually exclusive — configure whichever one matches your deployment architecture. For Backup Only mode, configure neither — without a tracked condition, a unit never promotes itself automatically, and stays secondary until an administrator runs promote.

Localized HA (VRRP)

For two units at the same location, run VRRP between them and configure track-ip to track the VRRP VIP. Whichever unit currently holds the VIP is primary — VRRP already guarantees exactly one owner at any given time, so this cannot produce a split-brain condition under normal operation.

RansNet Gateway System Sync — Localized High Availability with VRRP

Administrators and applications always reach the pair through the shared VRRP VIP, never a unit's own address. Gateway 1 in the diagram currently owns the VIP and serves as the read/write primary; Gateway 2 continuously receives replicated databases, files, certificates, and keys over System Sync, and takes over automatically if Gateway 1 releases the VIP.

track-ip 10.65.31.197 30

Offsite HA (BGP / Routed)

For units at different sites, each site advertises the same mfusion IP (typically configured on a loopback interface) into a BGP network — or a router elsewhere injects a static route toward whichever site is currently active, using route tracking to withdraw the route on failure. Configure track-route on each unit to check for the presence of that specific prefix in its own routing table:

track-route 10.65.31.0/24 30

The unit that currently has this route in its table (because its own BGP session is up and advertising, or because it's the currently-selected active site) is primary.

Note

track-ip and track-route only read local state (an interface address or a routing-table entry) — this module does not create or withdraw the tracked IP/route itself. Provisioning the VRRP group, BGP session, or tracked static route that makes the condition true or false is configured separately, using the referenced VRRP, BGP, or Tracking features.

Peer Configuration

Identify the peer unit and this unit's own address:

Command Description
remote-ip <ip> mac <mac> The peer unit's IP address and eth0 MAC address.
local-ip <ip> This unit's own IP address, used to bind the local sync services.

Once a unit is in the secondary role, its dashboard is not accessible for login — the database is read-only, and dashboard login requires a database write (recording the login event), which fails on a read-only database.

Tip

For HA modes, always access the dashboard through the shared VIP (localized) or the shared advertised IP (offsite), never through a unit's own individual IP address. This way, the dashboard is always reachable at the same address regardless of which unit currently holds the primary role — the role and the specific unit serving it stay transparent to the administrator.

Firewall Access

Once enable is run, System Sync automatically permits the peer's replication and file-sync traffic through the firewall — restricted to the exact peer IP and the specific ports involved. There is nothing to configure manually here: the access is added when sync is enabled and removed automatically when it's disabled (no enable) or removed (no mfusion sync).

CLI Configuration

Full example — a localized HA pair using VRRP:

mfusion sync
 remote-ip 10.65.31.53 mac 00-50-56-9b-43-fa
 local-ip 10.65.31.56
 track-ip 10.65.31.197 30
 enable
!

Key points:

  • remote-ip 10.65.31.53 mac 00-50-56-9b-43-fa — the peer unit's IP and eth0 MAC address
  • local-ip 10.65.31.56 — this unit's own IP address
  • track-ip 10.65.31.197 30 — the VRRP VIP shared by both units, polled every 30 seconds; whichever unit holds this address is primary
  • enable — activates System Sync using the settings above; run this last, after remote-ip, local-ip, and track-ip/track-route (if used) are all configured

For an offsite pair, replace track-ip with track-route:

mfusion sync
 remote-ip 10.10.20.11 mac 00-50-56-8a-1c-4e
 local-ip 10.10.10.11
 track-route 10.65.31.0/24 30
 enable
!

For Backup Only mode, omit track-ip/track-route entirely — the secondary stays read-only until manually promoted:

mfusion sync
 remote-ip 10.10.20.11 mac 00-50-56-8a-1c-4e
 local-ip 10.10.10.11
 enable
!

Initial Setup

  1. Configure and enable System Sync on the primary unit first.
  2. Configure and enable System Sync on the secondary unit.
  3. On the secondary unit, force an immediate full sync: 
    rejoin
    rejoin reseeds the secondary's data fresh from the primary rather than waiting for the two units to reconcile on their own — use it at initial setup, and any time a unit needs a full resync (e.g. after extended downtime).

Warning

When testing failover, allow enough time for a full sync before promoting the secondary — some data syncs faster than others. If the secondary is promoted to primary while it is only partially synced, the original primary (now secondary) will sync from the newly-promoted unit and can lose any data that had not yet replicated.

Do not rush into a failover test the first time you set up System Sync. Confirm the secondary is fully synced first (see Verification).

Manual Role Control

For Backup Only mode, or to force a controlled cutover in an HA deployment, use these commands directly on each unit:

Command Description
promote Makes this unit primary (read/write) and attaches the peer as its replica.
demote Makes this unit secondary (read-only) and attaches it as a replica of the peer.
rejoin Wipes this unit's local data and reseeds it fresh from the peer — use for initial setup or to recover a unit that has fallen too far out of sync.

Verification

Items to Test Command Expected Outcome
Sync role and status show mfusion sync Shows Sync Role: PRIMARY on the intended primary unit, SECONDARY on the other. Role/Track Consistent: Yes on both units (HA modes).
Replication health show mfusion sync Replication IO: Yes and Replication SQL: Yes on the secondary, with Replication Lag: 0 sec once caught up. Last Replication Err: NONE.
Dashboard access Browse to the shared VIP / advertised IP (HA modes) Dashboard loads and login succeeds — you are always directed to the current primary.
Data sync Create a test record (e.g. an entity or host) on the primary The same record appears on the secondary shortly after.
Failover (HA modes) Remove the tracked IP/route from the primary (e.g. disable its VRRP group, or withdraw its BGP advertisement) The secondary detects the change and promotes itself to primary within the configured poll interval. show mfusion sync on the (new) secondary shows Read Only: Yes.

Example output from a healthy localized HA pair — primary:

DC1-VM56# show mfusion sync
Sync Role:             PRIMARY (holds track IP)
Read Only:             No
Role/Track Consistent: Yes
Replication IO:        n/a
Replication SQL:       n/a
Replication Lag:       n/a sec
Last Replication Err:  NONE
Last File Sync:        2026-09-20T11:49:00+08:00

and secondary:

DC2-VM53# show mfusion sync
Sync Role:             SECONDARY (no track IP)
Read Only:             Yes
Role/Track Consistent: Yes
Replication IO:        Yes
Replication SQL:       Yes
Replication Lag:       0 sec
Last Replication Err:  NONE
Last File Sync:        2026-09-20T11:50:48+08:00

Replication IO/Replication SQL/Replication Lag show n/a on the primary — replication status only applies to a unit currently receiving data as a secondary. Role/Track Consistent: Yes on both confirms each unit's read/write state matches whether it actually holds the tracked IP/route.

Troubleshooting

Symptom Likely Cause Solution
Secondary unit's dashboard shows a database access error Expected behavior — the secondary is read-only, and dashboard login requires a database write Access the dashboard via the primary unit, or via the shared VIP/advertised IP (HA modes) so you're always directed to the current primary.
Replication Lag stays high or Replication IO/Replication SQL shows No Network connectivity issue between the two units, or a genuine data divergence after an abrupt failover Check connectivity between remote-ip/local-ip addresses. If replication cannot recover on its own after a short wait, run rejoin on the affected unit to force a fresh resync.
Both units show SECONDARY, or both show PRIMARY The tracked IP/route condition is not being satisfied correctly on either unit, or both currently satisfy it (e.g. a VRRP or routing misconfiguration) Verify VRRP state with show ip vrrp (localized HA) or the routing table with show ip route (offsite HA). Confirm track-ip/track-route matches the actual VIP/prefix used by your VRRP/BGP configuration.
Data missing on the secondary after failover testing Secondary was promoted before it finished a full sync (see the warning under Initial Setup) Run rejoin on the affected unit to force a full resync, and allow more time before the next failover test.

Best Practices

  • Access via the shared VIP/advertised IP — for HA modes, never bookmark or hardcode a unit's individual IP for dashboard access; always use the tracked IP (VRRP VIP) or advertised address so the current primary is always reached transparently.
  • Don't rush the first failover test — allow a full sync cycle to complete before testing failover, particularly the first time System Sync is configured.
  • Use rejoin after extended downtime — if a secondary has been offline long enough that normal replication cannot catch up cleanly, rejoin forces a full, consistent resync rather than leaving the unit in a partially-synced state.
  • Match the tracking method to the architecture — use track-ip with VRRP for localized HA pairs, track-route with BGP or tracked static routes for offsite HA pairs, and neither for Backup Only mode. Don't mix track-ip and track-route on the same pair.
  • VRRP — virtual IP redundancy for localized HA pairs
  • Tracking — reachability monitoring used to control VRRP participation and static route presence
  • BGP — dynamic route advertisement for offsite HA pairs
  • Static Routes — tracked static routes as an alternative to BGP for offsite HA