On 11/04/13 16:10, Josh Fisher wrote:
> On 11/4/2013 1:27 PM, Phil Stracchino wrote:
>> Honestly, based upon experience as a DBA at a hosting company that hosts
>> MANY customers using MySQL, my first advice on using MySQL on top of
>> DRBD would be "Just don't."  I could cite lists of customers who have
>> had complete unrecoverable DB losses as a result of problems or
>> interactions involving DRBD, and had to rebuild from DB backups.  If
>> you're going to cluster MySQL, use a shared-nothing configuration if you
>> possibly can.
> 
> Interesting. I am curious as to what DRBD replication mode was used. In 
> mode C (synchronous replication) a write operation does not complete 
> until it has been written to both nodes, so is essentially network 
> RAID-1 and guaranteed not to lose data in the event of a forced 
> fail-over. It is of course slower, so some may be tempted to use mode A 
> (asynchronous replication) which can and will lose data in the event of 
> a fail-over. Mode A is faster and reasonable for some uses, but only 
> mode C should ever be used for database storage. I have been using MySQL 
> on DRBD in mode C for quite some time and have seen drive failures, NIC 
> failures, and node failures without any data loss or db problems I could 
> attribute to DRBD.

Disclaimer, I'm not an expert on DRBD.  But it is entirely possible that
an inappropriate DRBD mode may have been in use.  In at least one of the
cases I know about, though, the problem was not a failure of DRBD per
se, it was that someone accidentally started up mysqld on the second
node, which normally would not be allowed to happen because the second
instance accessing the same filesystem would not be allowed to lock the
InnoDB tablespace.  In the DRBD situation, though, there was nothing
whatsoever locking the tablespace on the local machine, so it quite
cheerfully allowed both mysqlds to write to their own local instances of
the tablespace on the replicated filesystem, whereupon the two mysqlds
proceeded to destroy the tablespace by making it internally inconsistent.


-- 
  Phil Stracchino, CDK#2     DoD#299792458     ICBM: 43.5607, -71.355
  alaric AT caerllewys DOT net   alaric AT metrocast DOT net   phil AT 
co.ordinate DOT org
  Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater
                 It's not the years, it's the mileage.

------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users