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
