Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Thank you for your explanation. I have found this in change log, Can you explain it to me? In case our backing devices support write barriers and cache flushes, we use these means to ensure data integrity in the presence of volatile disk write caches and power outages. 在 2012-06-04 15:48:36，"Felix Frank" <ff at mpexnet.de> 写道： >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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120604/62eac00e/attachment.htm>