From owner-freebsd-fs@FreeBSD.ORG Sat Jul 3 08:21:21 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 8A596106566C; Sat, 3 Jul 2010 08:21:21 +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 A7A988FC16; Sat, 3 Jul 2010 08:21:20 +0000 (UTC) Received: by bwz12 with SMTP id 12so2411589bwz.13 for ; Sat, 03 Jul 2010 01:21:09 -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=ZFg8AhBARthGdCy4EuEm3YqxQWG9W2QHkDTdajOc2hE=; b=MmTOwi4GURUQiaACo+kn4bZoGF89Fn04DRexrD4HDm0IR8QKfvaBoHrqP0TxPa4weY /w1OPf007NR+2vr0h7HP7hiLuk15K9h67IfR9jt5JOBNeAL13NqcIHQXGcxfMvWJzAp6 O5H0OrCWZKnD8TTTdxKv0tA/VSMHA+i9OXqJ8= 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=B1hxrLKFUY7Sh9oe7wHFmZFzGha+PF6tx9tvV6dGJ7Z9N3A1W6VGvWvMKTo7vzJ8/9 TLsX4R7s6+b9S7L6AI4pqmzYShTcG4K3mhUqMXhTI8k5bLY9aDPXeuAMhKCmiZ9uemM3 5po2K4EOcy36PZRmBBoMuYl1/QHD5iusaefSs= Received: by 10.204.83.204 with SMTP id g12mr93024bkl.25.1278145269327; Sat, 03 Jul 2010 01:21:09 -0700 (PDT) Received: from localhost ([95.69.160.105]) by mx.google.com with ESMTPS id 24sm6839845bkr.19.2010.07.03.01.21.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 01:21:07 -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> <86mxubndrp.fsf@kopusha.home.net> <4C2D7615.5070606@soupacific.com> <861vbm1hpr.fsf@zhuzha.ua1> <4C2D9C62.4050105@soupacific.com> <86wrtez14z.fsf@zhuzha.ua1> <4C2DC801.5080108@soupacific.com> X-Comment-To: hiroshi@soupacific.com Date: Sat, 03 Jul 2010 11:21:05 +0300 In-Reply-To: <4C2DC801.5080108@soupacific.com> (hiroshi@soupacific.com's message of "Fri, 02 Jul 2010 20:05:37 +0900") Message-ID: <86iq4xx9fy.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: Sat, 03 Jul 2010 08:21:21 -0000 On Fri, 02 Jul 2010 20:05:37 +0900 hiroshi@soupacific.com wrote: h> Thanks ! >> >> When ServerB has become master and modified some data, ServerA, before setting >> to primary again, should be set to secondary to synchronize all changes and >> only after this be switched to primary, otherwise you will have split-brain >> and should synchronize full storage recreating provider on secondary. >> h> I understand this idea! and agree with you this situation. h> BUT once we go into split-brain mode, there is no way to solve this h> except hastctl create xxxx. h> hastctl create xxx initialize hast device and not recommend idea!! I h> agree this. h> Even split-brain condition, hastctl status returns as BACKUP. h> I could not find the way to resolve split-brain by script. I don't think resolving split-brain by script is a good idea. You can detect split-brain on primary monitoring provider status and then resolve it manually. It is much better to have scripts/setup that prevent split-brain situations than scripts that resolve it :-) h> But managing ServerB became MASTER, that time we can change advskew to h> prevent booting ServerA keeping as BACKUP. h> Of course before booting SerberA, change advskew manually! But this h> manner can not solve split-brain. h> Is there any idea to solve split-brain condition? You should have a setup so when the master is rebooted after the reboot it checks the status of other node and sets its own role accordingly (so there would not be two masters simultaneously). Software I use in my setup (our home made application) does this well. sysutils/heartbeat should work fine too. As for me carp might not do well for this but I am not very experienced with carp so I can be wrong. -- Mikolaj Golub