You can verify that a configured MDrivenServer slave receives master changes and handles client refreshes by generating a small, repeated update on the master and observing it from a client connected to the slave.
What this test verifies
This procedure tests the expected short delay between a committed change on the master and the same change becoming available from a slave. It is intended for a standard slave configuration, not a HistorySlave.
A slave keeps its local database updated by obtaining committed update packages from the master through MDrivenServerSynk. Because this transport takes time, a client reading from the slave can briefly show older data after another client has saved a change to the master. This is expected behavior.
For the architecture, replication behavior, and slave modes, see Documentation:Slave and History Server and Documentation:Scaling MDrivenServer for multiple reasons.
Before you begin
Confirm the following before running the test:
- You have exactly one MDrivenServer configured as the master.
- The master database contains the
MDrivenServerSynktable. - The slave database was created from a backup of the master database and the slave is configured to contact the master.
- The slave has obtained its initial model from the master by using Get model from master. After this initial step, the slave obtains model changes from the master when required.
- You know which application URL or connection each test client uses: master or slave.
- You have test data containing a Company that the clients can display and update.
If the slave is not yet configured, complete Documentation:Slave and History Server before continuing. Do not use two databases on the same database server when your purpose is to test database load reduction; that arrangement is suitable only for a basic functional test.
Test topology
Use three clients so that you can create changes and observe their arrival independently.
| Client | Connect to | Purpose |
|---|---|---|
| Application instance 1 | Master | Repeatedly changes and saves a Company name. |
| Application instance 2 | Master | Produces additional committed changes and confirms that multiple clients can update the master. |
| MDriven Designer Prototyper | Slave | Refreshes and observes changes after the slave has received them. |
You can use two application instances against the master and one MDriven Designer Prototyper session against the slave, as in the example described on this page. The important distinction is that the writer clients commit changes to the master and the observer reads through the slave.
Run the replication test
- Start two application instances connected to the master.
- Start the MDriven Designer Prototyper connected to the slave.
- In each application instance, open the same Company data so that the changed name is visible.
- In the Prototyper, open the same Company data and keep it visible.
- Trigger a repeated update and save from one or both master-connected application instances.
- Refresh the slave-connected Prototyper and observe the Company name.
- Repeat the update and refresh several times.
Expected result
The master-connected clients show their committed changes first. The Prototyper connected to the slave receives those changes after the slave has collected and applied the corresponding update package from the master.
The slave-connected view can therefore appear less smooth, or "choppier," during repeated refreshes. For example, if the master clients repeatedly change Company.Name, a slave refresh may temporarily show the previous name before it shows the latest committed value. This delay is the visible effect of transport through MDrivenServerSynk; it is not evidence that the slave is failing.
Given time and working connectivity between the slave and master, the slave should reach the same content as the master.
Example repeated update action
The following action changes the current Company name, resets it after the name becomes longer than 10 characters, refreshes the ViewModel, and saves it. Here, vCurrent_Details is the current-detail ViewModel value and selfVM is the current ViewModel.
vCurrent_Details.Company.Name:=vCurrent_Details.Company.Name+'x';
if vCurrent_Details.Company.Name->length>10 then
vCurrent_Details.Company.Name:='C'
else
''
endif;
selfVM.Refresh;
selfVM.Save
For example, a Company named C becomes Cx, then Cxx, and so on. After the name exceeds 10 characters, the action sets it back to C. This makes changes easy to recognize while you repeat the test.
Test a save submitted through the slave
If your slave uses ReadOnlySlave mode, you can also test its write routing behavior.
- Connect a client to the ReadOnlySlave.
- Change a visible Company name and save.
- Confirm that the change becomes available from the master.
- Refresh the slave-connected client until it shows the committed change.
A ReadOnlySlave accepts a write request but routes it to the master. The committed change then returns to the slave through MDrivenServerSynk, so the slave-connected client may not show the change immediately after saving.
Troubleshoot unexpected results
| Observation | Check |
|---|---|
| The slave never shows a master change. | Confirm that the slave can reach the master, that its master address and credentials are correct, and that the master is running in Master mode with MDrivenServerSynk available.
|
| A save through a ReadOnlySlave does not complete. | Check connectivity from the slave to the master. When a slave cannot reach the master, users cannot save through that slave and it cannot receive updates. |
| The slave cannot apply new changes after a model update. | Confirm that the slave can obtain the required model from the master. Slave and master must use the compatible model needed for each committed update package. |
| The slave view is briefly behind the master during repeated updates. | This is expected. Continue refreshing and verify that the slave converges on the master data. |
Do not treat a brief replication delay as a transaction conflict. A ReadWriteSlave can accept local writes, but its local state can later be overwritten by master changes. Use that mode only when you understand this behavior; it is not required for this test.