[Gluster-devel] Which performance translators are risky for MySQL?

[David Sickmiller]

Hi,

I am starting to run MySQL on GlusterFS with AFR.  Being aware that 
databases are deliberate about writing data to the disk instead of 
in-memory buffers, I would like to avoid using translators that risk 
data integrity, or I'd at least like to be aware of any trade-offs I'm 
making.  I've seen that others are indeed using MySQL on GlusterFS but 
haven't seen this particular issue addressed.  I'd like to be able to 
recover from a hardware failure without losing any transactions.

It would seem that the write-behind translator would be out of the 
question, because even hardware write cache is discouraged unless it has 
battery backup.  The Gluster wiki says that write-behind gets disabled 
on files with mandatory locks, but I think MySQL's InnoDB uses advisory 
locks on Linux.

Is io-threads safe?  This sounds possibly similar to write-behind and 
could hold written data in buffers.

I suspect io-cache should be safe, because I believe it's only used for 
reading, although it shouldn't provide much benefit for a well-tuned 
DBMS.  I'm guessing read-ahead should also be safe.

If I increase data-lock-server-count to 2 (the number of bricks I'm 
using), will this effectively give me confirmation that each write was 
successful on both servers?  If so, what happens if one brick is 
unavailable?  Or am I misunderstanding the purpose of this option?

Thanks in advance,
David

--
David Sickmiller
o: 866-636-9605 x 101
c: 517-745-3706
f: 810-632-7275

Career Liaison, LLC -- Applying Done Right
www.careerliaison.com