Documentation:Slave and History Server

The MDriven Server can be used to scale out to many Slave servers to swallow extreme loads of requests - or it may be scaled out geographically to reduce latency for user clusters.

Setting up a slave server is easy.

Start by setting your master in mode Master and Ensure you have the MDrivenServerSynk table in the database.

The MDrivenServerSynk table will hold the commitpackages until they are trunced away by the MaxQueueLengthInDays Setting.

It is actually beneficial to have the server in Master mode even if you do not have any slaves - since a MasterServer will load Refresh-data from MDrivenServerSynk. This means that your client refresh will not suffer from server restarts as it does otherwise (without MDrivenServerSynk commit packages are hold in memory only and will be lost on server restart - leaving a possibility for clients not seeing other clients changes when using refresh).

(There is always exactly 1 master in a cluster of MDriven Servers (You can have many clusters - 1 master each))

To get a new slave running it is best to take a backup of your master db and restore that as the slave db. The Slave-logic of MDriven is then used to keep the slave up to date with the master after this point.

In this example the Master is in a db called MtDev – and the slave will be in a database called MtDevSlave. The slave also needs the MDrivenServerSynk - so best is to set up the master first, then backup, then restore to slave.

In this example both databases reside on the same db-server – this is however not super smart if the aim was to reduce load on the db-server. The normal approach is to put slaves on separate machines and possibly far apart and close to a specific user cluster in order to reduce latency for data read.

Once we have the MtDevSlave database in place we set up an MDrivenServer that use it.

(Follow instruction to set up MDriven Server)

We must then set up the MtDevSlave MDriven server to be a slave:

We must tell the slave who is master, and how we access it – user and pwd (Note: user and pwd are both case sensitive).

To get everything going we need to have the first version of the model – this is the only time we need to think about the model for the slave – after this point the slave will get the new model from the master if the master changes model.

We can do this with this button named “Get model from master”:

The slave can run in 3 different modes:

ReadOnlySlave will accept write requests but will reroute these to the master – and the data will enter the slave via the MDrivenServerSynk mechanism in a short while.

ReadWriteSlave will accept write requests to local slave – this is a somewhat strange mode – the slave can get new state of its own – that may be overwritten by master changes.

HistorySlave will use the Master-model but before applying it to the slave it will set each class to Versioned in the model. This instructs the framework to add timestamps to all data written – and it also makes the framework to only insert new versions and never update existing versions on every data row in the db.

HistorySlave creates a vault of all changes ever done from the start time to now. You can use special ocl operators like oclAtTime on this model – and you can start the MDriven Designer prototype in History aware mode to access data herein:

The HistorySlave has the same good side effects as following a CQRS-pattern - all history is retained.