Re: Problems running AFR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Matt,

Just checked in a fix, please see if it fixes the problem.

Regarding your question of re-sync after a node has been
brought down, as of now you need to manage it with rsync
utility, but in future this will be automated by glusterfs itself.

Thanks for notifying the bug,
Krishna

On 4/19/07, Matt Bennett <bennett.matthew@xxxxxxxxx> wrote:
Hello list,

Using 1.3.0-pre-2.3, I have configured a two server, single client
setup following [1]. Apart from the IP addresses, my config files are
identical to those in the user guide.

Both servers and client start and run happily. If I write to the
mounted filesystem with the client, the file I created appears in
/home/export on server1 and /home/afr-export on server2 (and visa
versa).

The problem comes when I take one of the servers down. If I take down
server1, the client can no longer write to the mounted filesystem - it
gives me the error "Transport endpoint is not connected", and the
client logs contain this:

[Apr 19 16:37:19] [ERROR/tcp-client.c:284/tcp_connect()]
tcp/client:non-blocking connect() returned: 111 (Connection refused)
[Apr 19 16:37:19] [ERROR/client-protocol.c:183/client_protocol_xfer()]
protocol/client: client_protocol_xfer: :transport_submit failed
[Apr 19 16:37:19]
[DEBUG/client-protocol.c:2543/client_protocol_cleanup()]
protocol/client:cleaning up state in transport object 0x8076f08
[Apr 19 16:37:19] [DEBUG/tcp-client.c:174/tcp_connect()] transport:
tcp: :try_connect: socket fd = 9
[Apr 19 16:37:19] [DEBUG/tcp-client.c:196/tcp_connect()] transport:
tcp: :try_connect: finalized on port `1021'
[Apr 19 16:37:19] [DEBUG/tcp-client.c:255/tcp_connect()]
tcp/client:connect on 9 in progress (non-blocking)
[Apr 19 16:37:19] [DEBUG/tcp-client.c:293/tcp_connect()]
tcp/client:connection on 9 still in progress - try later
[Apr 19 16:37:19] [ERROR/client-protocol.c:183/client_protocol_xfer()]
protocol/client: client_protocol_xfer: :transport_submit failed
[Apr 19 16:37:19]
[DEBUG/client-protocol.c:2543/client_protocol_cleanup()]
protocol/client:cleaning up state in transport object 0x8076f08
[Apr 19 16:37:19] [ERROR/tcp-client.c:284/tcp_connect()]
tcp/client:non-blocking connect() returned: 111 (Connection refused)
[Apr 19 16:37:19] [ERROR/client-protocol.c:183/client_protocol_xfer()]
protocol/client: client_protocol_xfer: :transport_submit failed
[Apr 19 16:37:19]
[DEBUG/client-protocol.c:2543/client_protocol_cleanup()]
protocol/client:cleaning up state in transport object 0x8076f08
[Apr 19 16:37:19] [DEBUG/tcp-client.c:174/tcp_connect()] transport:
tcp: :try_connect: socket fd = 9
[Apr 19 16:37:19] [DEBUG/tcp-client.c:196/tcp_connect()] transport:
tcp: :try_connect: finalized on port `1021'
[Apr 19 16:37:19] [DEBUG/tcp-client.c:255/tcp_connect()]
tcp/client:connect on 9 in progress (non-blocking)
[Apr 19 16:37:19] [DEBUG/tcp-client.c:293/tcp_connect()]
tcp/client:connection on 9 still in progress - try later
[Apr 19 16:37:19] [ERROR/client-protocol.c:183/client_protocol_xfer()]
protocol/client: client_protocol_xfer: :transport_submit failed
[Apr 19 16:37:19]
[DEBUG/client-protocol.c:2543/client_protocol_cleanup()]
protocol/client:cleaning up state in transport object 0x8076f08

If, however, I take down server2, then this problem doesn't occur.
Writes happen as normal, but obviously don't appear in
/home/afr-export on server1.

This brings me on to my next question - when does the resync happen
between servers? When I bring server2 back up again, files written to
server1 during the downtime are not copied to server2.

Is there a particular way to force the resync?

Many thanks,
Matt.














[1] http://www.gluster.org/docs/index.php/GlusterFS_User_Guide#AFR_Example_in_Clustered_Mode


_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel





[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux