As I mentioned in my previous post, I would change the architecture to support multiple DB instances. In fact, the change was fairly simple, as you can see in the following drawing:
As you can see, I added a copy of the complete set of components which interact with the database. In the drawing two databases are connected to the bus, but copying the components can be repeated multiple times to allow more db instances to connect to the bus.
So what are the changes in the scenario?
In the previous design, only one db subscriber requested the sensor data to put it in the database. Again, only one one db publisher was present to publish the query results onto the bus.
In this new design, multiple instances of the db subscriber are reading the sensor data from the bus. They are responsible to pass the information on to their own database that is connected to them. Every database instance has its own publisher to make the data available on the bus again. This means that in normal operation, duplicate data is sent to the bus. However, each db publisher has a different strength on the ORTE bus. Therefore, clients will only receive the data once.
In case a database fails to produce data (for instance, the db connection is broken, or the db is too busy and therefore is not able to produce the data in time) the data from the publisher with the second highest strength is read by the clients.
The great benefit of this design is that no reconnect to a database duplicate is necessary when the master database fails. The second (and third, fourth...) database instance is already up and running and even publishing its data.
Tuesday, May 23, 2006
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment