Improvement in replication

#1

Hi,

I was thinking about some improvement in replication mechanism. Our application do only few writes (mostly reads), but those writes are important for us - objects rating, profile modifications. So in current implementation when master node dies, there is only a chance to read data from slave and all writes fails.

I was thinking about special version of one master / one slave only cluster. The main idea is to take over master role by slave when original master dies. Now, after master is recovered it becomes slave and at startup, before serving any queries, it tries to catch up with current master.

The main problem with solution is to choose master when both nodes are down and we start whole cluster. One of possible solution is to choose the one with higher "transaction" or "log" number.

What do you guys think about this?

#2

Another problem is that when a master dies it may have some updates that have not been delivered to the slave yet, and therefore, if the slave accepts write operations they may be based on a state, which is not the most up to date. At least for some applications this is unacceptable.

Introducing more sophisticated replication is certainly a goal for next ObjectDB versions. Thank you for this idea. It is an interesting direction and it should be considered in future versions.

ObjectDB Support
#3

The case you are talking about is when transaction is in progress and you replicate every single write operation, right?. I think that this can be solved with some user action. The idea is to throw some kind of exception, when master dies, so the user knows that transaction failed. On slave server (and only on them) there can be some kind of timeout for replicated transaction. So in case when master dies in the middle of transaction, client will get exception and can replay transaction on new master. Old transactions from slave 'phase' will gradually timeout after switching to master.

This isn't the most beautiful solution, but for this particular functionality can work quite well.

#4

Actually the problem is when a transaction succeeds, and on the client commit returns, but the master dies before the update is propagated to the slave. Currently commit doesn't wait for confirmations from all the slaves that they got the update since this could slow transactions.

ObjectDB Support

Reply