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@xxxxxxxxxxxxxxxxx> wrote:
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.
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.
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.
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@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
--
Raghavendra G
