Skip to content

Replication overview

MiaRec replication copies data from one MiaRec instance to another over HTTPS. It is asynchronous and push-based: jobs on the sending server upload changes to the receiving server's replication API, and the receiving server applies them on arrival. Because every server can be configured both to send and to receive, the topology is multi-master — two sites can replicate to each other, or several sites can push into one central instance.

Typical use cases:

  • Redundant / standby site — keep a second MiaRec instance continuously up to date so it can take over if the primary site fails.
  • Central archive — several recording sites push conversations into one central instance where analytics, QA, and reporting run.
  • Migration — move conversations and configuration from an existing instance to a new one (for example, on-premises to cloud) while the old instance stays in service.

What is replicated

Replication transfers two kinds of data, handled by two different jobs:

  • System configuration — tenants, users, groups, roles, storage targets, processing queues, jobs, custom fields, report templates, evaluation forms, SAML identity providers, tags, topics, clients, AI tasks, integrations, redaction rules, and speech engines. Related child records (license assignments, group members, permissions, per-tenant settings, and so on) travel with their parent records.
  • Conversation data — conversation metadata (always), and optionally audio files, evaluation reports, and transcripts.

How it works

Three building blocks cooperate:

  • Replication slots (sending side) capture configuration changes incrementally. A slot is a named change log: you choose which tables it monitors, and every insert, update, or delete in those tables is recorded until a replication job consumes it. This is what lets the system-configuration job send only what changed instead of rescanning everything.
  • Replication tokens (receiving side) authenticate and constrain incoming replication. A token defines what the remote server may send (which data types), how conflicts are resolved, and where received audio files are stored.
  • Replication jobs (sending side) do the actual work: Replicate System Configuration pushes configuration records, and Replicate Recordings pushes conversations and their files. Both authenticate to the target server with a token ID and secret.

Replication activity is audited on both sides — sent and received records appear in the audit trail.

Note

Replication complements, but does not replace, backups. It keeps another live instance up to date; configuration changes — including deletions — propagate to the receiving side, so it is not a point-in-time recovery mechanism.

Where to go next

  • Configuration — create the receiving-side token and the sending-side slot.
  • Replication jobs — configure and monitor the two jobs, and chain post-processing on the receiving server.