See all results

    Gluesync Module · Disaster recovery

    Disaster Recovery

    Run a standby Core Hub on a second site. It follows the active site continuously and takes over the same pipelines from the same positions, by planned switchover at zero data loss or by failover when a site is lost.

    See how it works Talk to our team
    Disaster Recovery
    Settings · Disaster Recovery

    Disaster Recovery

    The state of the two sites and how closely the standby site follows the active one.

    This siteActive
    Nodesite-a
    StateServing
    Epoch7
    Build8c1f2e7a
    Peer siteStandby
    Nodesite-b
    StateFollowing site-a
    Epoch7
    Build8c1f2e7a
    ReplicationAll in sync
    DatabaseActive txidStandby txidStatus
    Gluesync (pipelines and configuration) 000000000000003b 000000000000003b In sync
    Notifications 00000000000001f2 00000000000001f2 In sync
    Metrics 00000000001a4c7e 00000000001a4c7e In sync
    AI brain 0000000000000009 0000000000000009 In sync
    Data comparison 000000000000002d 000000000000002d In sync
    Chronos scheduler 0000000000000061 0000000000000061 In sync
    1. 01 Active site runs the pipelines
    2. 02 Standby site follows every database
    3. 03 Switch over or fail over in seconds

    Why Disaster Recovery

    Losing a site should not mean rebuilding Gluesync

    01 / One site

    Core Hub holds the state

    Pipelines, connections, users, checkpoints and schedules live with Core Hub. When its site goes down, every pipeline it runs stops with it.

    02 / Backups

    A restore is not a takeover

    A nightly backup brings back yesterday's configuration and yesterday's positions. The changes in between have to be found, replayed or re-snapshotted by hand.

    03 / The platform outcome

    A second site, ready to serve

    The standby Core Hub holds a copy that follows the active one about a second behind, and resumes the same pipelines from the positions the targets confirmed.

    How it works

    Two Core Hubs, one active at a time

    1. 01

      Active

      One site runs the pipelines

      The active Core Hub serves the Control Plane, the API and MCP, and runs every pipeline as usual.

    2. 02

      Standby

      The other site follows

      The standby Core Hub receives every database change from the active one over a single encrypted channel. It opens no source connections and runs nothing until it takes over.

    3. 03

      Takeover

      The role moves, the pipelines follow

      A planned switchover or a failover makes the standby active, and it resumes the pipelines from the last positions their targets confirmed. The previous site rejoins as standby when it returns.

    Capabilities

    Replicate, switch over, fail over

    Disaster Recovery pairs two Core Hubs at two sites. Replication runs directly between them: no shared storage, no object storage and no extra cluster to operate.

    Replication

    Every Core Hub database, continuously

    Pipelines, notifications, metrics, AI brain, data comparison and Chronos

    The active site streams each of its six databases to the standby at the transaction level, so whatever Core Hub writes reaches the other site about a second later. The Disaster Recovery tab shows what the active site has shipped against what the standby has applied, database by database.

    • Core Hub to Core Hub over one key-pinned, encrypted channel
    • Chronos schedules replicated with the rest
    • Per-database status: shipped and applied transaction, in sync or behind
    Disaster Recovery
    Settings · Disaster Recovery

    Disaster Recovery

    The state of the two sites and how closely the standby site follows the active one.

    ReplicationAll in sync

    What the active site has shipped against what the standby site has applied, for each database.

    DatabaseActive txidStandby txidStatus
    Gluesync (pipelines and configuration) 000000000000003b 000000000000003b In sync
    Notifications 00000000000001f2 00000000000001f2 In sync
    Metrics 00000000001a4c7e 00000000001a4c7e In sync
    AI brain 0000000000000009 0000000000000009 In sync
    Data comparison 000000000000002d 000000000000002d In sync
    Chronos scheduler 0000000000000061 0000000000000061 In sync

    Planned switchover

    Move the active role with zero data loss

    For maintenance, upgrades and site drills

    Start the switchover from the active site. It stops the writes, replicates the last changes, and hands the role over with a SHA-256 digest of every database. The standby takes over only when each of its copies matches, then the old site restarts as standby.

    • Four visible steps, from stopping the writes to restarting as standby
    • Every database verified by digest before the handover is accepted
    • Last switchover verification kept on the Disaster Recovery tab
    Disaster Recovery
    Settings · Disaster Recovery

    Disaster Recovery

    The state of the two sites and how closely the standby site follows the active one.

    This siteActive
    Nodesite-a
    StateServing
    Epoch7
    Build8c1f2e7a
    Peer siteStandby
    Nodesite-b
    StateFollowing site-a
    Epoch7
    Build8c1f2e7a
    Last switchover verification

    After a switchover the new active site compares its databases with the ones the previous active site handed over.

    Epoch7
    From nodesite-b
    Verified atOct 31, 2026, 6:12:08 AM

    All 6 databases identical

    DatabaseRowsDigest
    Gluesync (pipelines and configuration)2149b1e47c0a2d5
    Notifications1,8734f08d3e61b7a
    Metrics48,512c27a90f5e384
    AI brain961d6b58a9f02c
    Data comparison37e53f0c7d81b4
    Chronos scheduler587a94b2e0c6d1

    Failover

    Manual by default, automatic with a witness

    Never two active sites

    With manual failover, an operator promotes the standby once the active site is confirmed down. With witness mode, a third Core Hub holds a lease: the standby takes over by itself when the active site loses it, and the active site stops serving before that can happen, so both sites never write to the same targets.

    • Witness: a Core Hub in witness mode, holding no pipelines
    • Epoch fencing: a returning site steps down and follows
    • Every promotion starts a new epoch on its own replication history
    Disaster Recovery
    Settings · Disaster Recovery

    Disaster Recovery

    The state of the two sites and how closely the standby site follows the active one.

    This siteActive
    Nodesite-a
    StateServing
    Epoch7
    Build8c1f2e7a
    FailoverWitness

    The active site renews a lease held by a witness. If the lease expires, the standby site takes over by itself.

    Witness URLhttp://witness:1719
    Lease holdersite-a
    Lease epoch7
    Last renewed4 s ago
    Lease TTL30 s

    Takeover

    Pipelines resume where the targets stopped

    No gaps, no manual replay

    The standby resumes each pipeline from the position its target confirmed. Changes delivered again across the takeover are absorbed by the upsert write path, so the target converges on the source.

    • PostgreSQL replication slots confirm only what the target stored
    • MySQL and MariaDB binlog positions rewound to the oldest confirmed position
    • Users, tokens and connections work on the new site as they did on the old one

    Operations

    Upgrade a pair one site at a time

    Standby first, then switch over

    Gluesync Control upgrades the standby while the active site keeps running, then a planned switchover moves the pipelines to the new build. The site that handed over keeps a rollback point with its exact state, so the pair can return to the previous build.

    • The Disaster Recovery tab shows the build of each site
    • A standby never takes over databases newer than its build
    • Node-local settings per site, never replicated to the peer

    Explore the platform

    Continue exploring Gluesync

    Disaster Recovery protects the Core Hub that runs your pipelines. Pair it with Validator to check targets after a takeover, and with Chronos to keep schedules running on the new site.

    Schedules and events

    Chronos schedules travel to the standby site with everything else and keep running after a takeover.

    Explore Schedules and events →

    Validator

    After a takeover, compare any entity with its target and reconcile the differences.

    Explore Validator →

    Core Hub MCP server

    Check the state of both sites and every pipeline from any MCP client after a switchover.

    Explore Core Hub MCP server →

    Gluesync

    Real-time CDC replication. Disaster recovery keeps it running when a whole site is lost.

    Explore Gluesync →

    Resources

    Guides, roadmap and support

    Roadmap

    Public Roadmap

    What we're building next. Submit feature requests.

    View roadmap ↗
    Support

    Support

    Access technical support and operational assistance.

    Get support →
    Status

    Service Status

    Real-time platform availability and incident history.

    Check status ↗

    Plan a second site for Gluesync

    Talk with the MOLO17 team about adding Disaster Recovery to your Gluesync subscription, or start a free trial.

    Request a free trial Talk to our team