Re: Synchronous replication, or no?

Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> · Thu, 09 Apr 2015 19:35:31 +0530



    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@xxxxxxxxxx>
          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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
              
              
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users