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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When a node gets banned, it should go into recovery and freeze all
databases. We rely on the recovery daemon to detect the banned state
and put the node in recovery and freeze all databases.
Recent change in b4357a79d9 took explicit
freezing out of banning code but left the setting of recovery mode
to ACTIVE. Recovery daemon will freeze databases only if the recovery
mode is NORMAL. Recovery mode set to ACTIVE is an indication that the
freeze has started.
Do not set the recovery mode to ACTIVE in banning. Let recovery daemon
take care of it.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Fri Oct 30 10:32:38 CET 2015 on sn-devel-104
This groups function prototypes for common client/server functions in
common/common.h and removes them from ctdb_private.h.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
When building standalone ctdb from git repo, samba_version_file correctly
includes git sha in VERSION string. When building standalone ctdb from
tarball, samba_version_file puts UNKNOWN in the VERSION string.
Use the packaged include/ctdb_version.h file to set the correct git sha.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Instead of includes.h, include the required header files explicitly.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This groups function prototypes for system specific functions in
common/system.h and removes them from ctdb_private.h.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
While 0000 is possible from the UNIX/POSIX point of view,
these permissions create problems in an environment with
selinux enabled, which is more strict.
This aligns the perms of the read only tracking db with other
internal dbs.
BUG: https://bugzilla.samba.org/show_bug.cgi?id=11577
Signed-off-by: Michael Adam <obnox@samba.org>
Reviewed-by: Amitay Isaacs <amitay@gmail.com>
Autobuild-User(master): Amitay Isaacs <amitay@samba.org>
Autobuild-Date(master): Wed Oct 28 06:13:09 CET 2015 on sn-devel-104
Centrally define all the default capabilities to make the defaults
crystal clear. Capability-related command-line options now have a
direct correspondence rather than a reverse correspondence.
Signed-off-by: Martin Schwenke <martin@meltin.net>
Reviewed-by: Michael Adam <obnox@samba.org>
Once the databases are recovered, all the pending calls are resent.
If the vnnmap is not updated, then the nodes can redirect calls to nodes
that are not part of the new vnnmap.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Autobuild-User(master): Martin Schwenke <martins@samba.org>
Autobuild-Date(master): Fri Oct 16 09:31:34 CEST 2015 on sn-devel-104
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>
In the parallel database recovery model, all the database will not remain
frozen at the same time. So relax the condition to check if recovery
is active.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Before setting recovery mode to normal, confirm that all the databases are
recovered by matching the database generation with the global generation.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
CTDB verifies the generation in the packet header matches that of the
current generation. However, that check now needs to be done where
database context is available. So add in the check in handlers for
database requests (CTDB_REQ_CALL, CTDB_REQ_DMASTER, CTDB_REPLY_DMASTER
and CTDB_REPLY_CALL).
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
The database generation for each database is updated only during recovery.
After recovery is complete the database generation would be the same as
the global generation.
The database generation is required for parallel database recovery.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
It's possible that the databases can get attached after initial freeze.
This typically happens during startup as CTDB will only attach persistent
databases and go in to startup freeze. During recovery, the recovery
master will attach all the missing databases and then send freeze
controls.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Since the banning code does not call this function anymore, it can be
made static.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Once the node is marked as banned, the recovery daemon on that node will
start freezing the databases anyway. This check happens every second
in recovery daemon, so the delay in freezing the databases on ban would
be a second.
The main reason for freezing databases is to prevent any database access
from samba clients. However, banning code also drops the public IPs
and thus disconnecting the clients. In addition, the generation gets
set to INVALID_GENERATION, thus database record migration requests on
that node will not be processed.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This cascades the global transaction controls to individual database
transaction operations. This ensures that the individual database state
is correctly set when processing global transaction controls.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
