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

[Raghavendra G]

Hi David,

I think you're worried about the situation wherein  the application
receives a "write complete" response from glusterfs, but glusterfs is still
holding data in its buffers waiting to write to the backend filesystem at a
later point in time. If thats the case, only write-behind does delay writes.


On Sat, Jan 31, 2009 at 11:21 AM, David Sickmiller
<david at careerliaison.com>wrote:

> 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.


io-threads is different from write-behind. The write system call does not
return in the application, till the data is written on the backend
filesystem.


>
>
> 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.


Yes, they are safe. But since they cache the data, if multiple clients are
writing to same server, consider tuning cache timeouts to suit your purpose.


>
>
> 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?


Whenever afr returns an error code saying write to be complete, its indeed
complete on all its children. data-lock-server-count ensures data integrity.
If you're very much concerned about data integrity, having
data-lock-server-count equal to the number of children of afr is good, but
it comes at the expense of reduced performance.


>
>
> 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
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20090202/b57265cc/attachment-0003.html>