Our survey just takes a minute to complete. We appreciate your input!

So if you choose to ignore all warnings and put ReiserFS on dual-Primary DRBD, and mount it from two nodes, you’ve just signed up for wrecking your data. And when that happens, don’t come whining. And don’t blame DRBD or any other of the technologies you may be choosing to employ while ignoring the documentation.

So if you plan to attend Plumbers or just happen to be in the area, please submit your talk! Miniconference talks are not expected to be full-blown presentations. Instead, you can float an idea in just a 5-10 minute talk and then stimulate a vibrant group discussion.

Even if you are not attending, you can still help! We are always eager to hear from our user community. What HA problems are you currently facing that the existing Linux clustering stack does not solve? How well does your application integrate with HA? Where can we improve? What’s already good, and can be made better? What sucks?

Feel free to comment below. Or send us an email on one of the mailing lists. Or grab us in #linux-ha or #linux-cluster on freenode. Make yourself heard!

I want to reiterate and stress that point here: if your application can’t reliably survive a node crash, it won’t successfully fail over on a replicated (or shared, for that matter) data device. But if it can, and DRBD is replicating synchronously, then DRBD won’t break it. In other words: try pulling the power plug on your machine while your app is running, and power back on. If your application recovers to a consistent state, you’re clear. If it doesn’t, don’t bother adding DRBD until you fix that.

You must fix any layer in your stack that isn’t crash safe, if you even want to start thinking about high availability. ext2, which Baron mentions in his post, isn’t crash safe. MySQL with a database using the MyISAM storage engine isn’t crash safe. KVM with virtual block devices in cache=writeback mode isn’t crash safe. Running on a RAID controller with the write cache enabled when its battery is dead isn’t crash safe.

Thus, if you want high availability, use ext3. Or ext4. Or any journaling file system. Use InnoDB for MySQL. Use cache=none for KVM. And check those batteries. It’s that simple.

November 9-12, were are doing our DRBD Total training in one of Europe’s finest cities, Berlin. Berlin is easily reached by air or rail, and our training location is directly next to historical Allied Checkpoint Charlie on Friedrichstraße. Training is exclusively in English, and covers DRBD, the Heartbeat/Corosync/Pacemaker cluster stack, and a number of high availability applications.

I hear you say, “November? Then why are you telling me this now?” Well guess what, there is a 15% early bird discount off the standard price if you register before August 31. So register quickly and grab your chance! Our classes usually sell out fast.

By the way: if you do speak German, we also have a German-language training coming up in Vienna in September. Take a look!

When upgrading from Heartbeat 2.1.3, this webinar recording may come in handy. The webinar covers an upgrade to squeeze, but the upgrade procedure is identical if you’re staying on lenny.

I do apologize for the less-than-optimal sound quality. I did the recording myself with my laptop mike, so unfortunately there’s quite a bit of clipping in the audio track. I hope my ramblings are still somewhat audible.

• Upgrading to Pacemaker on Debian squeeze tells you all there is to know about upgrading to the Pacemaker cluster manager on the upcoming Debian release, “squeeze”.
• High Availability for Oracle databases shows you how to leverage the Linux cluster stack to deploy highly available Oracle databases.

Like our live webinars, the recordings are of course free of charge. Enjoy!

If you’re in Berlin, drop by! Admission is free.