Re: [Moosefs-users] Moosefs automated failover with ucarp

[Thomas S H. <tha...@gm...>]

The assumption here is that there is a priority, there is no priority with
this failover setup. If B becomes the master then it has priority, and when
A comes back it becomes a metalogger and starts syncing data. If B then goes
 down then the setup.sh script will remove the old metadata on A, back it
up, and only restore from the metalogger data, this ensures that the new
changes the happened on B are now running on A.

This question makes more sense as to why you asked some of your earlier
questions, the thing about this failover mechanism is that there is no
single priority master, if there is then we have issues syncing back
information, like you pointed out. Instead it operates more like
an anonymous failover cluster, all of the machines are effectively the same,
and all of them need to be configured hardware wise to act as mfsmasters.

On Mon, Dec 27, 2010 at 9:17 AM, Leonid Satanovsky <leo...@ar...>wrote:

> Thank you for answering!...
> But there are still some more questions. One of which is the fillowing:
>
> It is about carp nodes priority.
> Let me consider the following scenario:
> 1) Host A runs master.
>   Host B runs metalogger.
>
> 2) Host As' carp iface goes down, host B gets the carp managed addres and
> starts running master.
>
> 3) After a while host As' carp interface goes up, host A it becomes master
> (e.g., it has the bigger priority),
> Q:
>  a) How does A synchronyse all the changes that were made to the FS, while
> the B was the master?...
>  b) If it is doesn't isn't the only way to solve the problem is make all
> the carp nodes of equal priority
>     (so that the host coming up starts metalogger to sync the data)?
>
>
>
> ----- Original Message ----- From: "Thomas S Hatch" <tha...@gm...>
> To: "Leonid Satanovsky" <leo...@ar...>; "moosefs-users" <
> moo...@li...>
> Sent: Monday, December 27, 2010 7:05 PM
> Subject: Re: [Moosefs-users] Moosefs automated failover with ucarp
>
>
>
>  As for your first question, when the failover occurs we want it to use the
>> metalogger data. There is a chance that the machine which is the failover
>> used to be a master, and that it has old metadata. The mv command is to
>> ensure that only metalogs are being used by mfsmetarestore and not
>> metadata
>> that would be old and from a a previous run as the mfsmaster.
>>
>> As for your second question, you are correct in that the contents of the
>> setup.sh could be executed inline in the vip-up script, so long as they
>> are
>> executed in the background, but you do need everything in the setup.sh to
>> be
>> executed, otherwise many conflicts can arise!
>>
>> And finally, yes, in the vip-down could probably use a few lines to
>> shutdown
>> the mfsmaster.
>>
>> -Tom Hatch
>>
>> On Mon, Dec 27, 2010 at 8:44 AM, Leonid Satanovsky <leo...@ar...
>> >wrote:
>>
>>  Greetings!
>>> Have reviewed the HOWTO, and there are two questions:
>>> 1)
>>>  You do the following:
>>>
>>>  <...>
>>>  mv $MFS/changelog.* $MFS/metadata.* $MFS/tmp/
>>>
>>>  service mfsmetalogger stop
>>>  mfsmetarestore -a   #!# BUT, On what files will it work if all the
>>> metadata and changelog files are "gone" to the "${MFS}/tmp" folder?
>>>
>>>  if [ -e $MFS/metadata.mfs ]    #!# The file will not be there, I think,
>>> cos' you have moved it to "${MFS}/tmp" folder
>>>
>>>  <...>
>>> _______________________________________________________________________
>>> 2) The second on is for all the audience:
>>> Isn't it just enough (or is it correct?...) to do the following:
>>>
>>> ------/ucarp-down-----
>>> #!/bin/sh
>>>
>>> <....>
>>>
>>> (
>>>      mfsmaster stop
>>>      mfsmetarestore -a   # DO WE NEED THIS?
>>>      mfsmetalogger start
>>> ) &
>>>
>>> ______________________________________________________________
>>>
>>> ------/ucarp-up-----
>>>
>>>
>>> #!/bin/sh
>>>
>>> <....>
>>>
>>> (
>>>      mfsmetalogger stop
>>>      killall -9 mfsmetalogger
>>>      mfsmetarestore -a          # DO WE NEED THIS?
>>>      mfsmaster start
>>> ) &
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Thomas S Hatch" <tha...@gm...>
>>> To: "moosefs-users" <moo...@li...>
>>> Sent: Friday, December 24, 2010 8:11 AM
>>>
>>> Subject: [Moosefs-users] Moosefs automated failover with ucarp
>>>
>>>
>>>  Sorry, this has taken me a while, my present service deployment has been
>>>
>>>> very demanding, and heck, it needs 1.6.19 anyway!
>>>>
>>>> I wrote it in asciidoc, enjoy!
>>>>
>>>> (Consider this file to be Copyright Thomas S Hatch under the FDL
>>>> licence,
>>>> or
>>>> whatever the MooseFS developers prefer blah blah blah...)
>>>>
>>>> -Thomas S Hatch
>>>>
>>>>
>>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>> Learn how Oracle Real Application Clusters (RAC) One Node allows
>>>> customers
>>>> to consolidate database storage, standardize their database environment,
>>>> and,
>>>> should the need arise, upgrade to a full multi-node Oracle RAC database
>>>> without downtime or disruption
>>>> http://p.sf.net/sfu/oracle-sfdevnl
>>>>
>>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------------------
>>>
>>>
>>>  _______________________________________________
>>>
>>>> moosefs-users mailing list
>>>> moo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/moosefs-users
>>>>
>>>>
>>>>
>>>
>>
>