CTDB and Recovery lock

[Partha Sarathi]

Thanks Martin for a brief note on it. The cluster wide mutex make more
sense now.  I noticed this is been used in Zookeeper too

https://issues.apache.org/jira/browse/CASSANDRA-704


Regards,
--Partha

On Wed, Nov 18, 2015 at 12:18 AM, Martin Schwenke <martin at meltin.net> wrote:

> Hi Partha,
>
> On Tue, 17 Nov 2015 14:00:11 -0800, Partha Sarathi
> <parthasarathi.bl at gmail.com> wrote:
>
> > > > Also we don't have our Clustered Filesystem with Posix locking
> > > > support but we do have Consensus/Conspiracy service available in
> > > > cluster, is it possible to make use of that infrastructure to
> > > > mimic the recovery file lock mechanism ?
>
> > > Not today.  Hopefully soon.  As I untangle some of this I will make the
> > > "exclusive" lock code call out to a configurable helper program.
>
> > Thanks a lot Martin for your detailed answers.
> >
> > Now I am more interested about the "configurable helper program" you
> > mentioned  which replaces the recovery lock mechanism. May I know little
> > more about it ?.
>
> We are thinking of an executable similar to the current
> ctdb_event_helper.  This would take some file descriptors for status
> and logging, and whatever other arguments are needed - for the fcntl(2)
> helper the only other argument would probably be the filename.
>
> The behaviour would be something like this:
>
> * If the cluster-wide mutex can be taken then write 0 to the status file
>   descriptor and hold the mutex until terminated with a signal or the
>   parent exits.
>
> * If the cluster-wide mutex can't be taken then write non-0 (or nothing)
>   to the status file descriptor, potentially write some messages to the
>   logging file descriptor, and exit.  It would probably make sense to
>   write an errno to the status file descriptor so CTDB can tell if
>   there was contention for the mutex (e.g. EACCES or EAGAIN) or some
>   other error.  We would need some sort of convention - I won't invent
>   it now.  :-)
>
> * When CTDB wants to release the mutex it could send SIGTERM.
>
> * If the parent exits then release the mutex and exit.
>
> How does that sound?
>
> As I said, there is probably a bit more untangling to do before this
> can be implemented.  I hope this can be done before Samba 4.4 is
> released in March 2016.
>
> peace & happiness,
> martin
>



-- 
Thanks & Regards
-Partha