Emmanuel Cecchet wrote:
A RecoveryLog is not recommended but mandatory if you want to recover from failures and add new nodes on-the-fly. The recovery log can be stored in an embedded database in the recovery log or a standalone database. To prevent the controller from being a single point of failure (SPOF) you need a second controller. Each controller has its own recovery log, so that the recovery log is not a SPOF either. You will have to define a distributed virtual database to synchronize activities between controllers and resynchronize recovery logs. More details in the Sequoia documentation.
I guess I'm still not seeing how the RecoveryLog avoids being point of failure. I've looked through the three guides (Administration, Installation, and User) but fail to see where this is clarified.
Right now I have two MySQL servers (let's call them M1 and M2) and a single Sequoia server (let's call it S1) with a virtual database (V1) comprised of both MySQL servers.
If I'm understanding correctly for the RecoveryLog to be fault tolerant it would need to be pointed to yet another virtual database (V2) which would need to be on at least two servers. Assuming I put it on M1 and M2, then when either M1 or M2 fail the RecoveryLog would become degraded and need to be recovered just like the original virtual database (V1) would it not?
If this is covered in the documentation, perhaps someone could point me to what I've missed?
Next step ... configuring the group communication! ;-)
I wanted to get a grasp of how to avoid what I perceive as a single point of failure in the RecoveryLog before proceeding with what seems to be a more complex configuration.
-- Jamin W. Collins _______________________________________________ Sequoia mailing list [email protected] https://forge.continuent.org/mailman/listinfo/sequoia
