Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, please don't forget to CC the list. On 06/04/2012 02:58 AM, 陈楠 wrote: > Thank you! There are volatile write cashes in our I/O system. Does the As long as you're making use of these caches, you *will* loose data on power outage or critical hardware failure. Performance can become unacceptable when you disable them. You can remedy the situation by protective means such as battery backups or (preferable imho) flash memory units on your RAID controllers. > new version has built-in data protection? We have four pairs redundancy As I said - there is no such thing. DRBD does not know (or care) which files, buffers or whatever your application is writing to. All it sees is a stream of blocks. If this stream gets torn, you end up with some data on your secondary, but it's impossible for DRBD to (e.g.) roll back to the last sane filesystem state. > servers, All of them powered off by accident, only one pair servers > works fine, others all crashed. I think there are something wrong with > our applications. I want to know how to adapt drbd mechanism for our > application. Describe your application then. But DRBD's MO cannot be altered much. Usually, the type of application that DRBD lends itself well to is one that can recover from crashes by some means of journal or log. A prominent example is the InnoDB storage engine in MySQL. A MyISAM database will not benefit as much from DRBD, because it will likely be thoroughly corrupted if the primary does crash. HTH, Felix