summaryrefslogtreecommitdiff
path: root/source3/lib/dbwrap_ctdb.c
AgeCommit message (Collapse)AuthorFilesLines
2011-03-25s3:dbwrap_ctdb: fix non-locked fetch on persistent db's causing corruptionMichael Adam1-2/+34
When doing a non-locking fetch on a record of a persistent db when no transaction is running, the old behaviour was to fetch locally and do a ctdb call when the record was not found in the local db. The call is useless for persistent dbs anyway since they are only written to using transactions and hence kept in sync, but it is also harmful, because a ctdb call will bump the record RSN when it does actually migrate the record from one node to another. Recently, ctdb has been changed to make all calls do a migration. This uncovered the client misbehaviour for persistent dbs, because now _each_ non-locking fetch will render the persistent db inconsistent: A subsequent transaction which touches the record in question will fail because the RSNs are out of sync. This patch fixes this old bug. Autobuild-User: Michael Adam <obnox@samba.org> Autobuild-Date: Fri Mar 25 01:26:32 CET 2011 on sn-devel-104
2010-08-31s3: messaging_ctdbd_connection() was only called with procid_self()Volker Lendecke1-7/+6
Eventually we'll get this right...
2010-08-06s3: fail db_open_ctdb if ctdb is not aroundVolker Lendecke1-0/+5
2010-07-05s3: Pass procid_self() explicitly to messaging_ctdbd_connection()Volker Lendecke1-4/+7
2010-03-22s3: Add the "ctdb locktime warn threshold" parameterVolker Lendecke1-0/+12
This is mainly a debugging aid for post-mortem analysis in case a cluster file system is slow.
2010-03-05s3: Remove the unused parameter "persistent" from fetch_locked_internalVolker Lendecke1-8/+2
2010-03-05s3: db->persistent==true was handled earlier, make this more obviousVolker Lendecke1-1/+1
2010-02-12s3:dbwrap_ctdb: fix reading/storing of special key __db_sequence_number__Michael Adam1-4/+2
The key for reading and writing was inconsistent due to a off by one data length. Michael
2010-02-12s3:dbwrap_ctdb: exit early when nothing has been written in transaction_commit.Michael Adam1-5/+9
This skips update of the __db_sequence_number__ record when nothing else has been written. There are transactions that are just openend and then nothing is written until transaction_commit is called. This is for instance the case with registry initialization routines: They start a transaction and only write somthing when the registry has not been initialized yet. So this change will skip many db_seqnum bumps and TRANS3_COMMIT roundtrips. Michael
2010-02-12s3:dbwrap_ctdb: fix brown paperbag bug in ctdb_transaction_commit.Michael Adam1-1/+1
I carefully prepared the return value only to "return 0;" at the bottom. :-( This may well have hit us for instance in the nested cancel case and produced random errors. Michael
2010-02-12s3:dbwrap_ctdb: fix logic error in pull_newest_from_marshall_buffer().Michael Adam1-1/+5
The logic bug was that if a record was found in the marshall buffer, then always the ctdb header of tha last record in the marshall buffer was returned, and not the ctdb header of the last occurrence of the requested record. This is fixed by introducing an additional temporary variable. Michael
2010-02-12s3:dbwrap_ctdb: fix an uninitialized variable.Michael Adam1-1/+1
Michael
2010-02-12s3:dbwrap_ctdb: fix two "may be used uninitialized" warningsMichael Adam1-0/+3
Michael
2010-02-12s3:dbwrap_ctdb: fix db_ctdb_fetch_db_seqnum_from_db() when NT_STATUS_NOT_FOUND.Michael Adam1-1/+5
Don't treat this as an error but return seqnum 0 instead. Michael
2010-02-12s3:dbwrap_ctdb: maintain a database sequence number that bumps in transactionsMichael Adam1-5/+116
For persistent databases, 64bit integer is kept in a special record __db_sequence_number__. This record is incremented with each completed transaction. The retry mechanism for failing TRANS3_COMMIT controls inside the db_ctdb_transaction_commit() function now relies one a modified behaviour of ctdbd's treatment of persistent databases in recoveries. Recently, a special treatment for persistent databases had been introduced in ctdb (1.0.108) to work around the problems with the orinal design of persistent transactions. Now with the rewrite we need to revert to the old behaviour that ctdb always takes the newest copies of all records. This change also paves the way for a next step, which will make recovery use the db seqnum to tell which node has the newest copy of a persistent db and use that node's copy. This will greatly reduce the amount of data transferred with each recovery. Michael
2010-02-12s3:dbwrap_ctdb: change db_ctdb_transaction_store() to return NTSTATUS.Michael Adam1-18/+12
The return values calculated by the callers were wrong anyways since the new marshalling code does not set the local tdbs tdb error code. Michael
2010-02-12s3:dbwrap_ctdb: update (C)Michael Adam1-1/+2
Michael
2010-02-12s3:dbwrap_ctdb: start rewrite of transactions using the global lock (g_lock)Michael Adam1-320/+160
This simplifies the transaction code a lot: * transaction_start essentially consists of acquiring a global lock. * No write operations at all are performed on the local database until the transaction is committed: Every store operation is just going into the marshall buffer. * The commit operation calls a new simplified TRANS3_COMMIT control in ctdb which rolls out thae changes to all nodes including the node that is performing the transaction. Michael
2009-12-05s3:dbwrap_ctdb: increase the number of commit retries 5-->100Michael Adam1-1/+1
This is to cope with timeouts when recoveries and transactions collide. Maybe 100 is too hight, but 10 or even 20 have been too low in a very busy environment. Michael
2009-12-05s3:dbwrap_ctdb: increase the rsn of the __transaction_lock__ when storingMichael Adam1-0/+2
so that it is correctly handled by recoveries. Also set the dmaster explicitly. Michael
2009-11-03s3:dbwrap_ctdb: add debug message to transaction_fetch_start()Michael Adam1-0/+4
for the case that another local process has started a transaction bewteen releasing the transaction_lock record and starting the transaction. Michael
2009-11-03s3:dbwrap_ctdb: split combined check in two and add descriptive debugMichael Adam1-1/+14
in db_ctdb_transaction_fetch_start() for error conditions when re-fetching the transaction_lock record inside the transaction Michael
2009-11-03s3:dbwrap_ctdb: fix race condition with concurrent transactions on the same ↵Michael Adam1-0/+12
node. In ctdb_transaction_commit(), when the trans2_commit control fails, there is a race condition in the 1 second sleep between the local transaction_cancel and the call to ctdb_replay_transaction(): The database is not locked, and neither is the transaction_lock record. So another client can start and possibly complete a new transaction in this gap, but only on the same node: The locking of the transaction_lock record on a different node which involves migration of the record to the other node has been disabled by introduction of the transaction_active flag on the db which closes precisely this gap from the start of the commit until the call to TRANS2_FINISH or TRANS2_ERROR. But this mechanism does not cover the case where a process on the same node tries to start a transaction: There is no obstacle to locking the transaction_lock record because the record does not need to be migrated. This commit closes this race condition in ctdb_transaction_fetch_start() by using the new ctdb_ctrl_transaction_active() call to ask the local ctdb daemon whether it has a transaction running on the database. If so, the check is repeated until the running transaction is done. This does introduce an additional call to the local ctdbd when starting transactions, but it does close the (hopefully) last race condition. Michael
2009-11-03s3:dbwrap_ctdb: add new db_ctdb_transaction_active() that calls ↵Michael Adam1-0/+21
CTDB_CONTROL_TRANS2_COMMIT Michael
2009-11-03s3:dbwrap_ctdb: fix a race in starting concurrent transactions on a single nodeMichael Adam1-0/+25
There are two races in concurrent transactions on a single node. One in starting a transaction and one with replay during commit. This commit closes the first race by storing the client pid in the transaction-lock record and comparing the stored pid against its own pid after releasing the lock and refetching the record inside the transaction. Michael
2009-11-03s3:dbwrap_ctdb: use db_ctdb_ltdb_fetch() inside db_ctdb_transaction_fetch_startMichael Adam1-6/+4
Michael
2009-11-03s3:dbwrap_ctdb: use db_ctdb_ltdb_fetch() inside db_ctdb_transaction_fetch()Michael Adam1-16/+6
Michael
2009-11-03s3:dbwrap_ctdb: add a function db_ctdb_ltdb_fetch()Michael Adam1-0/+53
This fetches a record from the db and splits out the ctdb header. Michael
2009-11-03s3:dbrwap_ctdb: add a function db_ctdb_ltdb_store()Michael Adam1-27/+39
and use it in db_ctdb_store() and db_ctdb_transaction_store(). Michael
2009-11-03s3:dbwrap_ctdb: reformat a comment slightly to enhance clearness.Michael Adam1-3/+5
Michael
2009-09-11s3:dbwrap_ctdb: set dmaster in ctdb_transaction_store() also when updating ↵Michael Adam1-1/+1
an existing record not only when creating a record. This matches commit e9194a130327d6b05a8ab90bd976475b0e93b06d from ctdb-master. Michael
2009-05-25s3:dbwrap_ctdb: fix some function header commentsMichael Adam1-3/+12
Michael
2009-03-04s3:dbwrap_ctdb_marshall_add: don't leak the ctdb_rec_data to the outsideMichael Adam1-6/+6
Michael
2009-01-19s3:dbwrap: add get_flags() hook to db_contextStefan Metzmacher1-0/+8
metze
2008-10-18Rename hex_encode to hex_encode_talloc,for consistency with samba 4 and heimdal.Jelmer Vernooij1-2/+2
2008-09-29fixed an (unlikely) memory leakAndrew Tridgell1-0/+1
2008-09-29fixed a segfault on the ctdb destructor codeAndrew Tridgell1-3/+10
2008-08-24Fix some nonempty blank linesVolker Lendecke1-11/+11
(This used to be commit 010c7101e59477f0d5f3bf11c17f474ec6f79cc1)
2008-08-24Fix some C++ warningsVolker Lendecke1-4/+6
(This used to be commit dd9e4e6db04acf20f6ef7705955358c7ca442bbd)
2008-08-13allow nested ctdb transactions in the same manner that they areAndrew Tridgell1-2/+21
allowed for tdb. This is needed for the registry db backend. (This used to be commit 4b04ec29c76df837a7909725bbbf4c79d5abdb4d)
2008-08-13drop retries to 5Andrew Tridgell1-1/+1
(This used to be commit a2f70fc175b748ef160a998d0563c28381ea3466)
2008-08-13use CTDB_CONTROL_TRANS2_COMMIT_RETRY to prevent the counter gettingAndrew Tridgell1-2/+3
out of sync (This used to be commit 571ec7893c8b40959c005d510c039e3f231ffc67)
2008-08-13fixed lots of places that paniced on a failed transaction_commit,Andrew Tridgell1-8/+11
thinking it was a failure of a transaction cancel (This used to be commit 22dbe158ed62ae47bbcb41bba3db345294f75437)
2008-08-13cope with the control failing completely without returning a statusAndrew Tridgell1-12/+18
(This used to be commit fe6a03e7b11cd859fddae5ba924ea5e071b8ccea)
2008-08-13handle two special casesAndrew Tridgell1-16/+42
1) when all nodes write the same value to the record, or when writing a value that is already there, we can skip the write and save ourselves a network transactions 2) when all remote nodes fail an update, and we then fail a replay, we don't need to trigger a recovery. This solves a corner case where we could get into a recovery loop (This used to be commit 2481bfce4307274806584b0d8e295cc7f638e184)
2008-08-13put a limit on the number of retries. I found a case where a recoveryAndrew Tridgell1-0/+12
could lead to it blocking forever (This used to be commit a633390d3a7cb04a7c4e14cba9c533621793287e)
2008-08-13we need to commit, not cancel, on record destructionAndrew Tridgell1-1/+4
(This used to be commit ba64a757f86fb60994e12e81416083ac0fa11c21)
2008-08-13all persistent databases now do all stores via automatic transactionsAndrew Tridgell1-150/+46
(This used to be commit 76fbe56e827193d939676da23a580aa0f9394dd1)
2008-08-13fixed fetch of empty recordsAndrew Tridgell1-6/+11
(This used to be commit 037516f1362c8d64da1d47a0cdaf83198d3eaeaf)
2008-08-13cleanup debugging and fix handling of empty transactionAndrew Tridgell1-13/+11
(This used to be commit 2e85cbe88b3d1674b915f62e02be7d005fddaa39)