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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Recovery daemon checks if it is the recovery master before performing
certain checks. During those checks it's possible that re-election can
change the recmaster. In such a case, the recovery daemon should never
do a database recovery.
This is not complete fix since the recovery master can still change
while the recovery is going on. The correct fix is to abort recovery
if the recovery master changes.
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 Oct 7 17:55:05 CEST 2015 on sn-devel-104
The reason for favouring more connected node is to create a larger
cluster in case of a split brain. In split brain condition, the nodes
are not communicating across partitions and each partition will run its
own election. Among all the partitions, the node which holds the recovery
lock will eventually "win". All the other nodes which won election but
could not grab recovery lock will end up banning themselves.
This also prevents the recovery master role from bouncing between nodes
during startup when the entire cluster is restarted.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
If election occurs during SMB activity, then trying to freeze all the
databases can cause samba/ctdb deadlock which parallel database recovery
is trying to avoid.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Parallel database recovery fixes the samba/ctdb deadlock during recovery.
Many times samba tries to grab multiple record locks in sequence.
Consider a case when samba is already holding a record lock on a database
and tries to get a record lock on second database. If the second record
is not available on the local node, samba asks ctdb to migrate the record.
If recovery occurs at this time (e.g. node becoming inactive), ctdb
cannot freeze all the databases since samba is already holding a lock
and waiting for the second lock. CTDB can process the second record
request only after the recovery is complete, thus causing a deadlock.
In parallel database recovery, each database is frozen and recovered
independent from each other. So as soon as the second database is
recovered, CTDB will resend all the pending migration requests and Samba
can get the second lock. Once samba releases both the locks, ctdb can
freeze the first database and recover it completing recovery process.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This is required for ctdb. This avoids adding dependency on wstatus
and ntstatus to ctdb build.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
