[Gluster-users] Synchronous replication, or no?

[Eric Mortensen]

Hi all,

Thanks for the helpful responses everyone, I will look at the mounting
options suggested.

Just a quick question to confirm my understanding. When we all say
replication is synchronous, that does mean that each of the filesystem
operations on appserver1 that write a chunk of bytes to the file does not
return back to the caller until the same chunks of bytes have been written
to the OS filesystem cache/disk on the other appserver/brick, right? Or
does it mean something else?

Jeff: I don't really understand how a write-behind translator could keep
data in memory before flushing to the replication module if the replication
is synchronous. Or put another way, from whose perspective is the
replication synchronous? The gluster daemon or the creating client?

Eric



On Thu, Apr 9, 2015 at 4:07 PM, Vijay Bellur <vbellur at redhat.com> wrote:

> On 04/09/2015 07:33 PM, Jeff Darcy wrote:
>
>> I was under the impression that gluster replication was synchrounous, so
>>> the
>>> appserver would not return back to the client until the created file was
>>> replicated to the other server. But this does not seem to be the case,
>>> because sleeping a little bit always seems to make the read failures go
>>> away. Is there any other reason why a file created is not immediately
>>> available on a second request?
>>>
>>
>> It's quite possible that the replication is synchronous (the bits do hit
>> disk before returning) but that the results are not being seen immediately
>> due to caching at some level.  There are some GlusterFS mount options
>> (especially --negative-timeout) that might be relevant here, but it's also
>> possible that the culprit is somewhere above that in your app servers.
>>
>>
> Might be worth mounting with --entry-timeout=0 too.
>
> -Vijay
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150409/3eccaecc/attachment.html>