IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Monitoring can fail during recovery due to databases (e.g. registry)
being unavailable. This has been avoided by explicitly disabling
monitoring around recovery via the START_RECOVERY and END_RECOVERY
controls. With this approach only there is still a window between
enabling recovery mode and START_RECOVERY when monitoring could be
attempted. However, explicitly disabling monitoring is unnecessary
because monitoring is not done when a node is in recovery.
So remove the explicit disable/enable of monitoring and rely on
monitoring being skipped when recovery mode is active.
The only possible change of behaviour with this change is that there
is now a window between setting recovery mode to normal and the
END_RECOVERY control where monitoring is enabled. However, at this
point databases would be available and the "recovered" event will
cancel any in-progress monitoring.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This allows to differentiate between the two database models.
ctdb_db_persistent() - replicated and permanent
ctdb_db_volatile() - distributed and temporary
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12857
This simplifies the code and avoids complicated conditions.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
BUG: https://bugzilla.samba.org/show_bug.cgi?id=12857
If the recovery mode is already set to the expected value, there is
nothing to do.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Parallel database recovery freezes databases in parallel and irrespective
of database priority. So drop priority from freeze/thaw code.
Database priority will be dropped completely soon.
Now FREEZE and THAW controls operate on all the databases.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Logging that node has lost election is less useful than knowing which
node has won the election.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Once DB_PUSH_START is processed as part of recovery, push_started
flag tracks if there are multiple attempts to send DB_PUSH_START.
In DB_PUSH_CONFIRM, once the record count is confirmed, all information
related to DB_PUSH should be reset. However, The push_started flag was
not reset when the push_state was reset.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Wed Jun 8 14:31:52 CEST 2016 on sn-devel-144
This makes the API more general. If they are needed in a handler then
they can be in the private data.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This will allow a simplification of the cluster mutex API, so the
private data can be registered when calling ctdb_cluster_mutex().
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
It isn't necessarily a file.
Don't bother changing the control, since it doesn't pervade the code.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
If the recovery lock setting is not consistent with that of the
recovery master then abort.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Deferred attach processing is done unconditionally at this point. It
is then done again if recovery lock checking is done and completes
successfuly. If the recovery lock checking fails then it should not
be done at all.
Move this processing so it is done with the early exit when the
recovery lock is not being used.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
ctdb_recovery_have_lock(), ctdb_recovery_lock(),
ctdb_recovery_unlock() are only used by recovery daemon, so move them
there.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This means that the cluster mutex handle can now be treated as opaque.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
All of the ctdb_cluster_mutex_* infrastucture can now handle an
arbitrary mutex.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The underlying change is to allow the cluster mutex argstring to
optionally contain a helper command. When the argument string starts
with '!' then the first word is the helper command to run. This is
now the standard way of changing the helper from the default.
CTDB_CLUSTER_MUTEX_HELPER show now only be used to change the location
of the default helper when testing.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This is currently just treated as the name of a lock file. However,
it is really some arbitrary arguments to lock helper.
Therefore, it should be parsed and passed as separate arguments to the
lock helper.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Replace the file descriptor for the recovery lock in the CTDB context
with the cluster mutex handle, where non-NULL means locked.
Attempting to take the recovery lock is now asynchronous and no longer
blocks the recovery daemon.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Unlike fcntl(2), some other helper might need to explicitly take
action to release a mutex. This can be done by catching SIGTERM.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This is currently only used to check whether the recovery lock can be
taken. However, name it more generally in anticipation of using it
for general cluster mutex taking and testing.
No functional changes. A couple of debug message simplifications and
code rearrangements.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This is used to reply to the recmode control for all the different
cases. The callers can later be generalised to use a pointer, which
can then be used for recovery lock handling in different contexts.
Note that the handle is now freed in set_recmode_handler() rather than
the callbacks.
There is one difference in behaviour. Deferred attach calls are now
processed in the timeout case, where they weren't before. That's a
bug fix!
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
'0' = Child took the mutex
'1' = Unable to take mutex - contention
'2' = Unable to take mutex - timeout
'3' = Unable to take mutex - error
This is a straightforward API. When the child is generalised to an
external helper then this makes it easier for a helper to be, for
example, a simple script.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Use the more general name "cluster mutex", since we are likely to end
up with more than one cluster-wide lock. There will probably be a
dedicated recovery lock, held only during recovery, and also a second
lock that is held by the master node. Currently one lock is used for
both purposes.
At the moment the struct and functions are involved with setting the
recovery mode. However, they'll be abstracted out to more generally
deal with the cluster mutexes, so "recmode" -> "cluster_mutex". Drop
"set" from names, since this is used to test the lock. Also drop
"ctdb" prefix from functions, since they are local to this file. The
struct will eventually be a long-lived handle that will release the
mutex when freed, so name it accordingly.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
It does not make sense to update this statistic for the timeout case,
since this could skew the statistic. To keep it simple, just update
it for the usual case where there is lock contention, since this is
the usual case. So the daemon statistic measures time to test the
lock and the corresponding recovery daemon statistic measures time to
take the lock.
Additionally, the recovery daemon will eventually use this code to
take the lock, and the method of updating the latency statistic will
need to be pushed further out to a configurable handler that depends
on the calling context.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Tue Feb 23 10:32:06 CET 2016 on sn-devel-144
Have 0 indicate that the lock was taken. This allows non-zero values
to be used to indicate why the lock could not be taken. EACCES means
lock contention.
For now use just EACCES to cover all failures, since
ctdb_recovery_lock() returns a bool and details of other errors will
be lost. ctdb_recovery_lock() will undergo some big changes, so don't
try to fix this now.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This currently returns an incorrect error when the expected number of
bytes are not read. Separate out the different cases to clarify the
logic and avoid reporting the wrong error.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
This is already done before the destructor is assigned.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The callbacks that use this value are only ever called if recovery
mode is being set to NORMAL. So do not check if recmode is NORMAL
either.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
The child process writes the status into the pipe before looping to
wait.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
