383 words

Improvement in replication

#1
2012-01-03 11:27

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?

lwalkowski
lwalkowski's picture
Joined on 2010-08-25
User Post #67
#2
2012-01-03 21:44

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
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #839
#3
2012-01-03 22:01

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.

lwalkowski
lwalkowski's picture
Joined on 2010-08-25
User Post #68
#4
2012-01-05 00:32

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
ObjectDB - Fast Object Database for Java (JPA/JDO)
support
support's picture
Joined on 2010-05-03
User Post #840

Post Reply

Please read carefully the posting instructions - before posting to the ObjectDB website.

  • You may have to disable pop up blocking in order to use the toolbar (e.g. in Chrome).
  • Use ctrl + right click to open the browser context menu in the editing area (e.g. for using a browser spell checker).
  • To insert formatted lines (e.g. Java code, stack trace) - select a style in the toolbar and then insert the text in the new created block.
  • Avoid overflow of published source code examples by breaking long lines.
  • You may mark in paragraph code words (e.g. class names) with the code style (can be applied by ctrl + D).
  • Long stack traces (> 50 lines) and complex source examples (> 100 lines) should be posted as attachments.
Attachments:
Maximum file size: 32 MB
Cancel