[Gluster-users] Synchronous replication, or no?

Pranith Kumar Karampuri pkarampu at redhat.com
Thu Apr 9 14:05:31 UTC 2015


On 04/09/2015 07:26 PM, Eric Mortensen wrote:
> Yes that is correct, read from a different mount (different 
> brick/server). The error from the app server when reading is that the 
> file was not found. (The actual error from the OS which leads to the 
> 404 error from the app server is not visible, I will try and log it. I 
> am pretty sure the OS error is file not found, though.)
>
> The fact that if I add a 1 second wait in the (automated) test client 
> between create and read, then everything is fine, that is what leads 
> me to believe that the problem is that the second server (where the 
> read happens) has not been synchronized with the first server.
>
> But this would make no sense if the replication is synchronous, no?
+gluster-users

hi Eric,
       Replication is synchronous, but there are performance translators 
like write-behind which keep the written data in memory before flushing 
to the replication module which in turn send the data to the respective 
bricks synchronously. One more question, are the app servers accessing 
the files directly through the backend filesystem or using a gluster mount?

Pranith
>
> Eric Mortensen
> Appstax Technologies
>
>
> On Thu, Apr 9, 2015 at 3:32 PM, Pranith Kumar Karampuri 
> <pkarampu at redhat.com <mailto:pkarampu at redhat.com>> wrote:
>
>
>     On 04/09/2015 04:39 PM, Eric Mortensen wrote:
>>     We have a Gluster replicated setup with 2 servers. Each server
>>     also runs an app server that functions as a client of the gluster
>>     files. Client access to the appservers are load balanced using
>>     round robin.
>>
>>     Sometimes, when a client creates a new file and then immediately
>>     tries to read it, the read fails because the appserver cannot
>>     find it. If the client sleeps for about 1 second between creating
>>     the file and reading it, the read always succeeds.
>>
>>     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?
>>
>>     I am running 3.6.2 and have not configured anything special
>>     except storage.owner-id and auth.allow.
>
>     If I understand correctly, creates are happening from one mount
>     and reads are happening from another mount?
>
>     What do you mean by read failing? Does it give any error? or the
>     data read is not complete?
>
>     Pranith
>>
>>     Thanks!
>>     Eric Mortensen
>>     Appstax Technologies
>>
>>
>>     _______________________________________________
>>     Gluster-users mailing list
>>     Gluster-users at gluster.org  <mailto:Gluster-users at gluster.org>
>>     http://www.gluster.org/mailman/listinfo/gluster-users
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20150409/f839fff3/attachment.html>


More information about the Gluster-users mailing list