Slave and History Server
No edit summary
(Automatically adding template at the end of the page.)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
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.
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.
Setting up a slave server is easy. Read more here on [[setting up a History slave]] or on the [[Purpose of History Server|purpose of the History Server.]]


Start by setting your master in mode Master and Ensure you have the MDrivenServerSynk table in the database.
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.
The MDrivenServerSynk table will hold the commit packages until they are truncated 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).
It is 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 held in memory only and will be lost on server restart - leaving a possibility for clients to not see 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))
(There is always exactly 1 master in a cluster of MDriven Servers (You can have many clusters - 1 master each))
[[File:2018-06-06 22h41 45.png|none|thumb|485x485px]]
[[File:2018-06-06 22h41 45.png|none|thumb|485x485px]]
[[File:2018-06-06 22h42 57.png|none|thumb|583x583px]]
[[File:2018-06-06 22h42 57.png|none|thumb|583x583px]]
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.
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 it is best to set up the master first, then backup, and restore to the slave.
* In this example, both databases reside on the same DB-server – this is however not smart if the aim was to reduce the load on the DB-server. The normal approach is to put slaves on separate machines - possibly far apart - close to a specific user cluster to reduce latency for data-read.
Once we have the MtDevSlave database in place, we set up an MDrivenServer that uses it.


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.
Follow the instructions to set up MDriven Server.


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.
We must set up the MtDevSlave MDriven Server to be a slave:
 
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:
[[File:2018-06-06 22h44 15.png|none|thumb|602x602px]]
[[File:2018-06-06 22h44 15.png|none|thumb|602x602px]]
We must tell the slave who is master, and how we access it – user and pwd (Note: user and pwd are both case sensitive).
We must tell the slave who is master, and how we access it – user and password (Note: user and password 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.
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 the model.


We can do this with this button named “Get model from master”:
We can do this with this button named “Get model from master”:
Line 35: Line 32:
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.
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.
ReadWriteSlave will accept write requests to local the slave. This is a somewhat strange mode – the slave can get a 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 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 also makes the framework insert only 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:
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 start the MDriven Designer prototype in History aware mode to access the data herein:
[[File:2018-06-06 22h48 04.png|none|thumb|504x504px]]The HistorySlave has the same good side effects as following a CQRS-pattern - all history is retained.
[[File:2018-06-06 22h48 04.png|none|thumb|504x504px]]The HistorySlave has the same good side effects as following a CQRS pattern - all history is retained.
[[Category:MDriven Server]]
{{Edited|July|12|2024}}

Latest revision as of 15:46, 10 February 2024

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. Read more here on setting up a History slave or on the purpose of the History Server.

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

The MDrivenServerSynk table will hold the commit packages until they are truncated away by the MaxQueueLengthInDays Setting.

It is 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 held in memory only and will be lost on server restart - leaving a possibility for clients to not see 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))

2018-06-06 22h41 45.png
2018-06-06 22h42 57.png

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 it is best to set up the master first, then backup, and restore to the slave.
  • In this example, both databases reside on the same DB-server – this is however not smart if the aim was to reduce the load on the DB-server. The normal approach is to put slaves on separate machines - possibly far apart - close to a specific user cluster to reduce latency for data-read.

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

Follow the instructions to set up MDriven Server.

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

2018-06-06 22h44 15.png

We must tell the slave who is master, and how we access it – user and password (Note: user and password 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 the model.

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

2018-06-06 22h45 23.png

The slave can run in 3 different modes:

2018-06-06 22h46 28.png

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 the slave. This is a somewhat strange mode – the slave can get a 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 also makes the framework insert only 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 start the MDriven Designer prototype in History aware mode to access the data herein:

2018-06-06 22h48 04.png

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

This page was edited 114 days ago on 02/10/2024. What links here