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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
Attempt to make common code independent and free from ctdb_context.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
The functions defined in common/system_*.c depend on the functions
defined in common/system_common.c. So keep them together.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
These headers are used by the server code and should not be marked public.
Samba builds against the in-tree version of the headers and should not
be built with externally installed CTDB.
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>
The same structure is required in new controls for database transactions.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Instead of marking all the databases with priority, mark only the database
which is currently being processed.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
This changes the locking behaviour when the databases are frozen.
Instead of a single lock helper locking all databases with a priority,
a lock helper is launched for every database.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
These variables are used for state information related to freezing
databases. Instead use the API functions to check if the databases
are frozen.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
Use ctdb->freeze_mode only in ctdb_freeze.c and use the functions to
check if databases are frozen everywhere else.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>
The pending calls are migration requests received from clients (over unix
domain socket) which are under processing. After a recovery is finished,
any requests which are under processing will be dropped since they do
not belong to the current generation. All the pending call requests
are resent with new generation to restart record migrations.
This is in preparation for parallel database recovery.
Signed-off-by: Amitay Isaacs <amitay@gmail.com>
Reviewed-by: Martin Schwenke <martin@meltin.net>