On 11/28/2012 10:27 AM, At?f CEYLAN wrote:> My first question: if GlusterFS was start before than the imap/pop3 server
> can't be map 993 and 995 ports by imap/pop3 server. Because GlusterFS
use them.
> I didn't understand why it use these ports?
Like many other system programs, GlusterFS tries to use ports below 1024 which
are supposed to be privileged, hunting downward until it finds one that's
available. If this is a problem for you, I suggest looking into the
"portreserve" command.
> Second, one of two debian was crash and boot up again. When it was start,
> GlusterFS heal process was start. But a few minutes later written below
records
> into the log and GlusterFS native client (or FUSE) was crash.
>
> [2012-11-28 12:11:33.763486] E
> [afr-self-heal-data.c:763:afr_sh_data_fxattrop_fstat_done]
0-m3-replicate-0:
> Unable to self-heal contents of
> '/domains/1/abc.com/info/Maildir/dovecot.index.log' (possible
split-brain).
> Please delete the file from all but the preferred subvolume.
> [2012-11-28 12:11:33.763659] E
> [afr-self-heal-common.c:2160:afr_self_heal_completion_cbk]
0-m3-replicate-0:
> background meta-data data self-heal failed on
> /domains/1/O/abc.com/info/Maildir/dovecot.index.log
> [2012-11-28 12:11:33.763927] W [afr-open.c:213:afr_open] 0-m3-replicate-0:
> failed to open as split brain seen, returning EIO
> [2012-11-28 12:11:33.763958] W [fuse-bridge.c:1948:fuse_readv_cbk]
> 0-glusterfs-fuse: 432877: READ =-1 (Input/output error)
> [2012-11-28 12:11:33.764039] W [afr-open.c:213:afr_open] 0-m3-replicate-0:
> failed to open as split brain seen, returning EIO
> [2012-11-28 12:11:33.764062] W [fuse-bridge.c:1948:fuse_readv_cbk]
> 0-glusterfs-fuse: 432878: READ =-1 (Input/output error)
> [2012-11-28 12:11:33.764062] W [fuse-bridge.c:1948:fuse_readv_cbk]
> 0-glusterfs-fuse: 432878: READ =-1 (Input/output error)
> [2012-11-28 12:11:36.274580] E
> [afr-self-heal-data.c:763:afr_sh_data_fxattrop_fstat_done]
0-m3-replicate-0:
> Unable to self-heal contents of
> '/domains/xxx.com/info/Maildir/dovecot.index.log' (possible
split-brain).
> Please delete the file from all but the preferred subvolume.
> [2012-11-28 12:11:36.274781] E
> [afr-self-heal-common.c:2160:afr_self_heal_completion_cbk]
0-m3-replicate-0:
> background meta-data data self-heal failed on
> /domains/xxx.com/info/Maildir/dovecot.index.log
The phrase "split brain" means that we detected changes to both
replicas, and
it would be unsafe to let one override the other (i.e. might lost data) so we
keep our hands off until the user has a chance to intervene. This can happen
in two distinct ways:
* Network partition: client A can only reach replica X, client B can only reach
replica Y, both make changes which end up causing split brain.
* Multiple failures over time. X goes down, changes occur only on Y, then Y
goes down and X comes up (or X comes up and Y goes down before self-heal is
finished) so changes only occur at X.
The quorum feature should address both of these, at the expense of returning
errors if an insufficient number of replicas are available (so it works best
with replica count >= 3).
It's also usually worth figuring out why such problems happened in the first
place. Do you have a lot of network problems or server failures? Are these
servers widely separated? Either is likely to cause problems not only with
GlusterFS but with any distributed filesystem, so it's a good idea to
address
such issues or at least mention them when reporting problems.