Francois Gnu writes:
Is the mdb database protected against any power cut?
Yes, if the filesystem and operating system are so protected and you don't use mdb's dbnosync option.
Is the mechanism of recovery mdb database working fine?
MDB needs no recovery. You may lose the last commit or two, but the database will be consistent if the filesystem is correct.
However, note that your OS and harddisk may both be lying when they claim they've really written your data. MDB does not attempt to deal with data which got broken that way. Some databases do try.
The OS part should be tunable with OS/filesystem parameters. Basically fsync() or fdatasync() need to actually write to disk. Harddisk writes get secured with builtin batteries to keep the disk going long enough to save the cache, RAID/SAN setups and I don't know what else. (I'm way out of date with this stuff.)
Explanation:
A database commit needs to be flushed to disk, and the data involved needs to be written in the right order (data before metadata). Which needs of physical seeks on the disk, and doing a lot of those can slow down not just the program doing it but the entire system - since other disk I/O may need to wait for these seeks too.
To speed things up, normal file operations just write to caches in the OS and can return success before the cache has been written to disk. MDB calls fdatasync() to flush this to disk before returning success.
But so do plenty of other programs, which can slow the system right back down. So to speed things up again, fdatasync() may ALSO be lying. And probably your harddisk too. It caches written data and returns success which actually just means "Got it, this'll get written".