You can use MDrivenServer Master and Slave modes to scale read access across locations, while keeping one authoritative writer; this page is for administrators planning or operating an MDrivenServer cluster.
What a Master and Slave cluster does
A cluster has exactly one Master MDrivenServer and zero or more Slave MDrivenServers. You can operate multiple independent clusters, but each cluster has one Master.
Use a cluster when users read data more often than they write it, or when users are geographically distant from the primary server. For example, users in two regions can read from a nearby Slave database, while all accepted writes remain coordinated through the Master.
The Master records committed changes in the MDrivenServerSynk table. Slaves retrieve those committed change packages and apply them to their own databases. This is replication with a short delay: a read from a Slave can temporarily show an older state than a read from the Master.
Choose a server mode
| Mode | Use it for | Write behavior | Data behavior |
|---|---|---|---|
| Normal | A standalone MDrivenServer that is not participating as a Master or Slave. | Handles writes locally. | Commit packages are held in memory unless the server is configured as a Master with MDrivenServerSynk.
|
| Master | The authoritative server in a cluster. | Accepts the cluster's authoritative writes and distributes committed changes. | Persists commit packages in MDrivenServerSynk for Slaves to retrieve.
|
| ReadOnlySlave | Regional or load-distribution nodes where local reads are the main goal. | Accepts a write request but routes it to the Master. The resulting change subsequently returns to the Slave through synchronization. | Reads are local; changed data arrives after synchronization. |
| ReadWriteSlave | A specialized scenario where a Slave accepts writes locally. | Accepts writes to its local database. | The Slave can develop a state of its own that Master changes may overwrite. Use this mode only when you understand this consequence. |
| HistorySlave | A separate database for temporal analysis of changes. | Receives data from the Master through synchronization. | Uses the Master model, with classes made versioned before the model is applied. Data changes are retained as versions rather than updates to existing rows. |
Why configure a Master even without Slaves
Configure a server as Master and ensure MDrivenServerSynk even when you do not currently need a Slave.
A Master reloads refresh data from MDrivenServerSynk. Without that table, commit packages exist only in server memory. A server restart then loses those packages, which can leave clients using refresh without visibility of changes made by other clients. With the table in place, commit packages are stored with the database and are included in database backup and restore operations.
The Master retains commit packages until they are removed according to the MaxQueueLengthInDays setting. Size this retention period to allow Slaves enough time to reconnect and catch up.
How synchronization works
Synchronization is initiated by the Slave. The Master accepts write requests and returns committed update packages when a Slave asks for them.
- A user reads data from a Slave's local database.
- If the user saves through a ReadOnlySlave, that Slave routes the write to the Master.
- The Master commits the business-data change and its synchronization package together.
- The Slave polls for available packages and merges them into its own database.
- The Slave then exposes the new state to its local users.
For example, a user connected to a regional ReadOnlySlave changes a customer's name. The write goes to the Master. Until the Slave retrieves and applies that committed package, another local read on that Slave may still show the previous name. This short delay is expected behavior; see Test Slave Server Setup.
If a Slave cannot reach the Master, users of that Slave cannot save through the Master and the Slave cannot receive new updates. When connectivity returns, synchronization resumes.
Set up a standard Slave
Follow the MDrivenServer installation guidance before configuring the cluster. Keep the Master and every Slave on compatible infrastructure and ensure that each Slave can reach the Master using the configured credentials.
- On the primary MDrivenServer, ensure that
MDrivenServerSynkexists. - Change the primary server mode from Normal to Master.
- Create a backup of the Master database after the synchronization table is present.
- Restore that backup as the database for the new Slave. For example, restore Master database
MtDevasMtDevSlave. - Configure a new MDrivenServer instance to use the restored Slave database.
- Set that instance to the required Slave mode, normally ReadOnlySlave.
- Configure the Slave with the Master MDrivenServer address and the Master user name and password. Both the user name and password are case-sensitive.
- Use Get model from master to obtain the initial model version on the Slave.
- Make a change on the Master and verify that it appears on the Slave after synchronization. Use Test Slave Server Setup for a focused verification procedure.
Taking the initial Slave database from a Master backup gives the Slave the same starting data, model state, and MDrivenServerSynk table structure. After that point, Slave synchronization keeps the database current.
Model changes in a cluster
A commit package is created in the context of a particular model version. Therefore, a Slave must not apply packages using a different model from the Master.
The Master stores a model checksum with each persisted commit package. If a Slave detects that its model differs from the model used for an incoming package, it requests the required model from the Master, evolves its database, and then applies the package. This lets you deploy model changes to the Master and have Slaves obtain the matching model and evolve automatically.
Do not treat this as model-definition history. The automatic mechanism keeps nodes aligned with the current required model so they can apply data changes.
Placement and capacity considerations
Put Slaves where they improve read latency or separate read load. Restoring a Slave database on the same database server as the Master is useful for evaluation, but it does not reduce load on that database server. To distribute database load or reduce regional latency, place Slave databases on separate machines and, where appropriate, nearer to the users they serve.
A Master/ReadOnlySlave design improves read distribution, not unrestricted write throughput. Writes still converge on the Master. If an application requires independent write scaling, divide the workload into separate systems or subsystems rather than expecting one Master/Slave cluster to remove the single authoritative-write path.
History Slave
A HistorySlave is a specialized Slave that retains versions of data so you can inspect the evolution of data using the current model. It is useful for support, debugging, and investigating how data reached its current state.
A HistorySlave is history of data, not history of model definitions. If a current model no longer represents a prior definition, historic data that depends on that removed definition cannot remain representable indefinitely. Keep model-definition history in source control, and use database backups when you need complete snapshots of both data and definition at a point in time.
For the full configuration procedure, versioning-table behavior, exclusion and retention tagged values, and history culling, see Documentation:Setting up a History slave. For the intended use and limitations of temporal history, see Documentation:Purpose of History Server.