On Mon, Dec 9, 2013 at 11:14 AM, pwalker <pwal...@navinet.net> wrote: > Having a quick look it doesn't seem like ReadOptions are used for this > function so no verifyChecksums flag is passed in right? >
Yep.. perhaps we should. > Was hoping that on initialization of the masterLevelDBClient we would be > able to validate the datastore at that point and if it was invalid fall > over? It might be impractical to check for all corruption at startup since that might significantly delay the startup process. > Is that the expected behavior of those parameters or is it completely > distinct from the replication process as they are used in the non-replicated > leveldb adapter as well? The replication bits added to leveldb replicate files at the block level and don't really check the integrity of the files it's transferring. Perhaps if we do detect consistency problem with a master we should just stop replication and mark it's data files as being inconsistent so that it does not try to become a master in the future. That still would require that one of the slaves data files be consistent to be able to recover from the failure. -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
