Avoiding Split Brains

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

 



Hi all,

We've been running a distributed setup for 3 years with no issues.
Recently we switched to a 2-server, replicated setup (soon to be a 4
servers) and keep encountering what I assume are split-brain situations,
eg:

    Brick server1:/brick
    <gfid:85893940-63a8-4fa3-bf83-9e894fe852c7>
    <gfid:8b325ef9-a8d2-4088-a8ae-c73f4b9390fc>
    <gfid:ed815f9b-9a97-4c21-86a1-da203b023cda>
    <gfid:7fdbd6da-b09d-4eaf-a99b-2fbe889d2c5f>
    ...
    Number of entries: 217

    Brick server2:/brick
    Number of entries: 0

a) What does this mean?
b) How do I go about fixing it?

And perhaps more importantly, how to I avoid this happening in the future?
Not once since moving to replication has either of the two servers been
offline or unavailable (to my knowledge).

Is some sort of server/client quorum needed (that I admit I don't fully
understand)? While high-availability would be nice to have, it's not
essential - robustness of the data is.

Thanks

Iain

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users



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

  Powered by Linux