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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://www.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
http://www.gluster.org/mailman/listinfo/gluster-users
