From owner-freebsd-fs@FreeBSD.ORG Thu Jul 1 20:33:30 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FA09106564A; Thu, 1 Jul 2010 20:33:30 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id CE8988FC17; Thu, 1 Jul 2010 20:33:28 +0000 (UTC) Received: by bwz12 with SMTP id 12so1411927bwz.13 for ; Thu, 01 Jul 2010 13:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :x-comment-to:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=YPCOPZLL3duf53FRgSAMyl3qQLQydgfjTaYFbSp84KQ=; b=Q/cHdeO7lswtsF6IS8ie2a2bmM/ZMDVuRlToVuU9Ohr0A8l8t3ZqiGeRGWyYfSkXpP 2YcwndW8ImqpOpirMRL+tKkPjg3F1OQz07Xq8z6ygdaX0upsXuZtPJv/dN9l1d+i9qN8 z6fSJsA6K1PCuYdqDgz9ltoBCTxGOpXJyhkI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:x-comment-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=sK09Ux7uP+5sokie9t6qdpSMgARDEw7J8NTWWKjX9I2ni+zf0i5Tsd1TlTvQPWxPgR mOd8apgf25rONijf7mVxy9akocqps5upt+Bz96yaAPCMoaUMiHGi5nB+5uvU8eAqEde1 w970CuwqFICThvFL9indtAX83H/yUuy+w/3Hs= Received: by 10.204.82.130 with SMTP id b2mr47220bkl.12.1278016401315; Thu, 01 Jul 2010 13:33:21 -0700 (PDT) Received: from localhost ([95.69.160.105]) by mx.google.com with ESMTPS id bq20sm13969754bkb.3.2010.07.01.13.33.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Jul 2010 13:33:18 -0700 (PDT) From: Mikolaj Golub To: "hiroshi\@soupacific.com" 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> X-Comment-To: hiroshi@soupacific.com Date: Thu, 01 Jul 2010 23:33:14 +0300 In-Reply-To: <4C2C43D5.1080907@soupacific.com> (hiroshi@soupacific.com's message of "Thu, 01 Jul 2010 16:29:25 +0900") Message-ID: <86mxubndrp.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-fs@freebsd.org, Pawel Jakub Dawidek Subject: Re: HAST and CARP X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 20:33:30 -0000 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