server: create a server variant ctdb_ltdb_store_server() of ctdb_ltdb_store().

This is supposed to contain logic for deleting records that are safe
to delete and scheduling records for deletion. It will be called in
server context for non-persistent databases instead of the standard
ctdb_ltdb_store() function.

daemon: fill ctdb->ctdbd_pid early

test: send SCHEDULE_FOR_DELETION control from randrec test.

client: add accessor function ctdb_header_from_record_handle().

vacuum: add ctdb_local_schedule_for_deletion()

server: implement a new control SCHEDULE_FOR_DELETION to fill the delete_queue.

control: add a new control opcode CTDB_CONTROL_SCHEDULE_FOR_DELETION

control: add macro CHECK_CONTROL_MIN_DATA_SIZE.

This is for the control dispatcher to check whether the input data has
a required minimum size.

vacuum: lower level of hash collision debug message to INFO

vacuum: add statistics output to the fast and full traverse runs.

vacuum: refactor insert_delete_record_data_into_tree() out of add_record_to_delete_tree()

for reuse in filling the delete_queue.

vacuum: change all Vacuum*Interval tunables to default to 10

So, by default we have a fastpath vacuuming every 10 seconds and
full blown db-traverse vacuuming once every 10 minutes.

vacuum: disable full db-traverse vacuuming runs when VacuumFastPathCount == 0

vacuum: Only run full vacuumig (db traverse) every VacuumFastPathCount times.

vacuum: reset the fast path count in the event handle if it exceeds the limit.

vacuum: bump the number of fast-path runs in the vacuum child destructor

vacuum: add a fast_path_count to the vacuum_handle.

Add a tunable VacuumFastPathCount.

This will control how many fast-path vacuuming runs wil have to
be done, before a full vacuuming will be triggered, i.e. one with
a db-traversal.

vacuum: traverse the delete_queue befor traversing the database.

vacuum: add delete_queue_traverse() for traversal of the delete_queue.

vacuum: reduce indentation in add_record_to_delete_tree()

This simplyfies the logical structure a bit by using early return.

vacuum: refactor new add_record_to_delete_tree() out of vacuum_traverse().

This will be reused by the traversal of the delete_queue list.

vacuum: skip adding records to list of records to send to lmaster on lmaster

This list is skipped afterwards when the lists are processed.

vacuum: refactor new add_record_to_vacuum_fetch_list() out of vacuum_traverse().

This is the function that fills the list of records to send to each lmaster
with the VACUUM_FETCH message.

This function will be reused in the traverse function for the delete_queue.

server: rename ctdb_repack_db() to ctdb_vacuum_and_repack_db()

When wiping a database, clear the delete_queue.

vaccum: clear the fast-path vacuuming delete_queue after creating the vacuuming child.

Maybe we should keep a copy for the case that the vacuuming fails?

When attaching to a non-persistent DB, initialize the delete_queue.

Add a delete_queue to the ctdb database context struct.

This list will be filled by the client using a new
delete control. The list will then be used to implement
a fast-path vacuuming that will traverse this list instead
of traversing the database.

call: becoming dmaster in VACUUM_MIGRATION, set the VACUUM_MIGRATED record flag

This temporary flag is used for the local record storage function to
decide whether to delete an empty record which has never been migrated
with data as part of the fast-path vacuuming process or, or to store
the record.

call: hand the submitted record_flags to local record storage function.

call: transfer the record flags in the ctdb call packets.

This way, the MIGRATED_WITH_DATA information can be transported
along with the records. This is important for vacuuming to function
properly.

The record flags are appended to the data section of the ctdb_req_dmaster
and ctdb_reply_dmaster structs.

Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>

server: in the VACUUM_FETCH handler, add the VACUUM_MIGRAION to the call flags

This way, the records coming in via this handler, can be treated appropriately.
Namely, they can be deleted instead of being stored when the meet the fast-path
vacuuming criteria (empty, never migrated with data...)

add a new record flag CTDB_REC_FLAG_VACUUM_MIGRATED.

This is to be used internally. The purpose is to flag a record
as been migrated by a VACUUM_MIGRATION, which is triggered by
a VACUUM_FETCH message as part of the vacuuming. The local store
routine will base its decision whether to delete or to store
the record (among other things) upon the value of this flag.

This flag should never be stored in the local database copies.

call: Move definition of call flags down to the definition of the flags field.

call: add new call flag CTDB_CALL_FLAG_VACUUM_MIGRATION

This is to be used when the CTDB_SRVID_VACUUM_FETCH message
triggers the migration of deleted records to the lmaster.
The lmaster can then delete records that have not been
migrated with data instead of storing them.

recoverd: in a recovery, set the MIGRATED_WITH_DATA flag on all records

Those records that are kept after recovery, are non-empty, and
stored identically on all nodes. So this is as if they had been
migrated with data.

Pair-Programmed-With: Stefan Metzmacher <metze@samba.org>

server: when we migrate off a record with data, set the MIGRATED_WITH_DATA flag

vacuum: check lmaster against num_nodes instead of vnn_map->size

When lmaster is bigger than the biggest recorded node number,
then exit the traverse with error.

vacuum: reduce indentation of the loop sending VACUUM_FETCH controls

This slightly improves the code structure in that loop.

vacuum: correctly send TRY_DELETE_RECORDS ctrl to all active nodes

Originally, the control was sent to all records in the vnn_map, but
there was something still missing here:
When a node can not become lmaster (via CTDB_CAPABILITY_LMASTER=no)
then it will not be part of the vnn_map. So such a node would
be active but never receive the TRY_DELETE_RECORDS control from a
vacuuming run.

This is fixed in this change by correctly building the list of
active nodes first in the same way that the recovery process does it.

vacuum: in ctdb_vacuum_db, fix the length of the array of vacuum fetch lists

This patch fixes segfaults in the vacuum child when at least one
node has been stopped or removed from the cluster:

The size of the vnn_map is only the number of active nodes
(that can be lmaster). But the node numbers that are referenced
by the vnn_map spread over all configured nodes.

Since the array of vacuum fetch lists is referenced by the
key's lmaster's node number later on, the array needs to
be of size num_nodes instad of vnn_map->size.

Fix typos in a comment in vacuum_traverse.

tests: fix segfault in store test when connection to ctdbd failed.

tests: fix segfault in fetch_one test when connection to ctdbd fails

tests: fix segfault in fetch test when connection to ctdb failed.

tests: fix segfault in randrec test when connection to daemon fails.

gitignore: add tags file

gitignore: add vi swap files

Restart recovery dameon if it looks like it hung.
Dont shutdown ctdbd completely, that only makes the problem worse.

If/when the recovery daemon terminates unexpectedly, try to restart it again from the main daemon instead of just shutting down the main deamon too.

While it does not address the reason for recovery daemon shutting down, it reduces the impact of such issues and makes the system more robust.

new version 1.2.23

ATTACH_DB: simplify the code slightly and change the semantics to only
refuse a db attach during recovery IF we can associate the request from a
genuine real client instead of deciding this on whether client_id is zero or

This will suppress/avoid messages like these :
DB Attach to database %s refused. Can not match clientid...

New version 1.2.22.

recover: finish pending trans3 commits when a recovery is finished.

When the end_recovery control is received, pending trans3 commits are
finished. During the recovery, all the actions like persistent_callback
and persistent_store_timeout had been disabled to let the recovery do
its job. After the recover is completed, send the reply to the waiting
clients.

persistent: add ctdb_persistent_finish_trans3_commits().

This function walks all databases and checks for running trans3 commits.
It sends replies to all of them (with error code) and ends them.
To be called when a recovery finishes.

daemon: correctly end a running trans3_commit if the client disconnects.

persistent: add a client context to the persistent_stat and track the db_id

The db_id is tracked in the client context as an indication that a
transaction commit is in progress. This is cleared in the persistent_state
talloc destructor.

This is in order to properly treat running trans3_commits if the client
disconnects.

persistent: reject trans3_control when a commit is already active.

This should actually never happen.

persistent: allocate the persistent state in the ctdb_db struct in trans3_commit

Make sure that ctdb_db->persistent_state is correctly NULL-ed when
the state is freed. This way, we can use ctdb_db->persistent_state
as an indication for whether a transaction commit is currently
running.

persistent: add a ctdb_db context to the ctdb_persistent_state struct.

persistent: add a ctdb_persistent_state member to the ctdb_db context.

To be used for tracking running transaction commits through recoveries.

persistent_callback: print "no error message given" instead of "(null)"

persistent: reduce indentation for the finishing moves in ctdb_persistent_callback

persistent: if a node failed to update_record, trigger a recovery

and stop processing of the update_record replies in order to let
the recovery finish the trans3_commit control.

persistent_store_timout: do not really time out the trans3_commit control in recovery

If a recovery was started, then all further processing of the update_record
controls sent by the trans3_commit control and timing them out is disabled.
The recovery should trigger sending the reply for the update record control
when finished.

persistent_callback: ignore the update-recordreturn code of remote node in recovery

If a recovery was started, then all further processing of the update_record
controls sent by the trans3_commit control is disabled. The recovery should
trigger sending the reply for the update record control when finished.

Deferred attach : at early startup, defer any db attach calls until we are out of recovery.

New version 1.2.21

ctdb_req_dmaster from non-master

If we find a situatior where we get a stray packet with the wrong
dmaster, dont suicide with ctdb_fatal() since this is too disruptive.
Just drop the stray packet and force a recovery to make sure all is good again.

CQ S1022004

Revert "Dont allow client processes to attach to databases while we are still in recovery mode."

This reverts commit faf3b1542fd27b3ad32ac7b362ef39d8cb0b05ff.

git pull ... 1.2-splitbrain
does not do what I think it does.
Revert patch and pull it into the right branch instead.

Dont allow client processes to attach to databases while we are still in recovery mode.

The exception is the local recovery daemon which needs to be able to attach (==create) any missing databases during recovery. This process requires the use of the attach control.

New version 1.2.20

We default to non-deterministic ip now where ips are "sticky" and dont change
too much.
This means we can simplify the way we add ips significantly and stop
trying to move them.

We also check if the node already hosts the ip, in which case we used to return an error. Instead just print an error string but return 0, ok.
This makes it easier to script, and works around broken scripts.

CQ1021034

New version 1.2.19

If the node is stopped,   put a log entry in /var/log/* to indicate this is why we never become ready

LockWait congestion.

Add a dlist to track all active lockwait child processes.
Everytime creating a new lockwait handle, check if there is already an
active lockwait process for this database/key and if so,
send the new request straight to the overflow queue.

This means we will only have one active lockwaic child process for a certain key,
even if there were thousands of fetch-lock requests for this key.

When the lockwait processing finishes for the original request, the processing in d_overflow() will automagically process all remaining keys as well.

Add back a --nosetsched argument to make it easier to run under gdb

Compile fix

ctdb_lockwait: create overflow queue.

Once we have more than 200 children waiting on a particular db, don't create
any more.  Just put them on an overflow queue, and when a child gets a lock
search that queue to see if others were after the same lock (they probably
were).

Add a new test tool that fetch locks a record and then blocks until it receives
user input to unlock the record again.

60.nfs
Dont update the statd settings that often.
When we have very many nodes and very many ips, this would generate
a lot of unnessecary load on the system

TDB : Fix for a deadlock with transaction lock and lockall/lockallmark
causing ctdbd hangs

ctdb: hold transaction locks during freeze, mark during recover.

Make the ctdb parent "mark" the transaction lock once the child process
has frozen/locked the entire database.
This stops the ctdb daemon from using  a blocking fcntl() locking on the tdb during the
read traverse during recovery.

CQ 1021388

tdb: expose transaction lock infrastructure for ctdb

tdb_traverse_read() grabs the transaction lock.  This can cause ctdbd
(which uses it) to block when it should not; expose mark and normal
variants of this lock, so ctdbd's child (the recovery daemon) can
acquire it and the ctdbd parent can mark it was held.

New version 1.2.17

change Christinas previous patch to only perform the check/logging
if we are the main ctdb daemon.
Other daemons/child processes are not guaranteed to get events on regular basis
so those should not be checked.

improve timing issue detections

the original "Time jumped" messages are too coarse to interpret
exactly what was going wrong inside of CTDB.

This patch removes the original logs and adds two other logs that
differentiate between the time it took to work on an event and
the time it took to get the next event.

LIBCTDB: add support for traverse

We can not always rely on the recovery daemon pinging us in a timely manner
so we need a "ticker" in the main ctdbd daemon too to ensure we get at least one event to process every second.

This will improve the accuracy of "Time jumped" messages and remove false positives when the recovery daemon is "slow".

ADDIP failure

Found during automatic regression testing.
We do not allow the takeip/releaseip events to be executed during a recovery.

All of "ctdb addip, ctdb delip, ctdb moveip" use and force these events to
trigger to perform the ip assignments required.

If these commands collide with a recovery, these commands could fail since we do
not allow takeip/releaseip events to trigger during the recovery.
While it is easy to just try running hte command again, this is suboptimal for script use.

Change these commands to retry these operations a few times until either successfull or until we give up.
This makes the commands much easier to use in scripts.

IPALLOCATION : If the node is held pinned down in "init" state
by external services failing to start, or blocking CTDBD from finishing the startup phase,
we can encounter a situation where we have not yet fully initialized, but a
remote recovery master tries to release a certain ip clusterwide.

In this situation the node that is pinned down in init/startup phase
would fail to perform the release of the ip address since we are not yet fully operational and not yet host any valid interfaces.

In this situation, we just need to remain unhealthy, there is on need to
also ban the node.

Remove the autobanning for this condition and just let the node remain in
unhealthy mode.
Banning is overkill in this situation when the system is broken and just
draws attention to ctdbd instead of the root cause.

Eventscripts: lower the fail/restart limits for nfsd.

We were potentially leaving a node unable to serve requests for too
long.

Signed-off-by: Martin Schwenke <martin@meltin.net>

Eventscripts: use "startstop_nfs restart" to reconfigure NFS.

This was defaulting to just "service nfs restart", which doesn't have
the workarounds we need.

Signed-off-by: Martin Schwenke <martin@meltin.net>

Eventscripts: only autostart during a monitor event.

Otherwise we might short-circuit events that are run only once and
actually need to do something.

Signed-off-by: Martin Schwenke <martin@meltin.net>

Eventscripts: print a message when reconfiguring a service.

Otherwise there can be strange error messages from services
stopping/starting, without any context.

Signed-off-by: Martin Schwenke <martin@meltin.net>

Eventscripts: work around NFS restart failure under load.

"service nfs restart" can fail.  To stop nfsd it sends a SIGINT and
nfsd might take a while to process it if the system is loaded.
Starting nfsd may then fail because resources are still in use.

This does some /proc magic to tell nfsd to do no more processing.  It
then runs service stop, kills nfsd with SIGKILL, and then runs service
start.  This is much less likely to fail.

Signed-off-by: Martin Schwenke <martin@meltin.net>

TYPO

STATD is 100027    not 1000247

LIBCTDB uninitialized inqueue element

From Michael Anderson,
initialize the inqueue element of the ctdb structure to NULL,
else it might be used uninitialized and cause a segv.

recoverd: avoid triggering a full recovery if just some ip allocation
has failed.
We dont need to rebuild the databases in this situation, we just
need to try again to sort out the ip address allocations.