Handle recovery log database failure
------------------------------------
Key: SEQUOIA-960
URL: https://forge.continuent.org/jira/browse/SEQUOIA-960
Project: Sequoia
Type: Improvement
Components: Core
Versions: Sequoia 2.10.8
Reporter: Mathieu Peltier
In the current state of affairs, a failure of the recovery log database simply
leaves a trace in full_cluster.log. Then, nothing prevents the un-aware user
from causing backend inconsistencies thanks to the dirty recovery log. The
following test case shows one faulty scenario:
- Start cluster and enable all backends
- Get a connection and execute a write request
- Simulate failure on the recovery log database (by stopping the daemon)
- Execute another write request
- Restart recovery log database
- Restore first backend of controller 1 from previous dump
- Enable the backend and check cluster consistency <-- ERROR
AFAIK, when request cannot be stored in recovery log, recovery log should be
marked as dirty to prevent future use. In 2 nodes config, the backend will be
disabled because the recovery log database is collocated with hsqldb, but then
nothing prevents user to enable it back with buggy recovery log.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
