Date: Thu, 01 Jul 2010 23:33:14 +0300 From: Mikolaj Golub <to.my.trociny@gmail.com> To: "hiroshi\@soupacific.com" <hiroshi@soupacific.com> Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek <pjd@FreeBSD.org> Subject: Re: HAST and CARP Message-ID: <86mxubndrp.fsf@kopusha.home.net> In-Reply-To: <4C2C43D5.1080907@soupacific.com> (hiroshi@soupacific.com's message of "Thu, 01 Jul 2010 16:29:25 %2B0900") References: <4C139F9C.2090305@soupacific.com> <86iq5oc82y.fsf@kopusha.home.net> <4C14215D.9090304@soupacific.com> <20100613003635.GA60012@icarus.home.lan> <20100613074921.GB1320@garage.freebsd.pl> <4C149A5C.3070401@soupacific.com> <20100613102401.GE1320@garage.freebsd.pl> <86eigavzsg.fsf@kopusha.home.net> <20100614095044.GH1721@garage.freebsd.pl> <868w6hwt2w.fsf@kopusha.home.net> <20100614153746.GN1721@garage.freebsd.pl> <86zkyxvc4v.fsf@kopusha.home.net> <4C2C43D5.1080907@soupacific.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 01 Jul 2010 16:29:25 +0900 hiroshi@soupacific.com wrote: h> SERVERA is master for CARP and HAST h> then boot SERVERB h> ServerB is using CARP and ifstated. h> First CARP state is INIT then BACKUP h> Similar to ucarp's method, vip-down.sh is called. h> vip-down.sh calls carp_down.sh h> Inside is almost same to ucarp_down.sh except delete ucarp staff. h> if I do not put hastctl create xxxx, then hastd refuse connection and h> message says h> Split-brain detected secondary ! Split-brain means that you or your scripts did something wrong: both nodes acted as primary (either simultaneously or one then another but there was no communication between them so both made changes to the data that was not synced to another node). The easy way to get split-brain is to change the role on secondary to primary without changing the role on the primary host, make some changes on the secondary (acting as a primary) and change back its role to secondary. You should check your setup if something like this may happen. Doing 'hastctl create' on every switching is wrong. Note, after 'hastctl create' hast metadata on the disk are lost and synchronization of all blocks from the primary is initiated, which is rather long. You can observe the status of this synchronization looking at "dirty" field of hastctl status output on the primary. You can't switch to failover until synchronization is complete. So you should avoid 'hastctl create' -- this is only for initial setup or repairing your hast. -- Mikolaj Golub
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86mxubndrp.fsf>