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 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.
(This used to be ctdb commit d4ab790c1f679e833eb97816762fcfcee15ccb10)
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.
(This used to be ctdb commit 9bbedf786b26bb074f668b31f29a9032af958673)
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.
(This used to be ctdb commit c11ca778ee90444c44dee0a629cd2eefa3a1f75e)
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>
(This used to be ctdb commit 945187d64cfc7bd30a0c3b0d548cbe582d95dde3)
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...)
(This used to be ctdb commit fb5d832104970320359b3e474eb291ca3d629380)
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.
(This used to be ctdb commit dd2449c422f323f9b5485e45107a9cc5acc09e08)
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.
(This used to be ctdb commit 455cc6616e10b7f09589f9b87cb60f591bb502b0)
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>
(This used to be ctdb commit 101be642e492a3a54231e2e3e6553a59380fe702)
When lmaster is bigger than the biggest recorded node number,
then exit the traverse with error.
(This used to be ctdb commit 3930c7796b72bbf275bbca8aaeceec3e705a964b)
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.
(This used to be ctdb commit 49247df4a47a8a107fa7dd7b187e69e243e6bdbe)
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.
(This used to be ctdb commit 136508e3f4dd0acc210dde938ad59ef38b63d3a1)
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.
(This used to be ctdb commit 0566ef3d6cef809bda204877c493c80ff9eb2c40)
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...
(This used to be ctdb commit b05ccf366df985e0a3365aacc75761ebd438deaf)
Just treat as a nop.
When the database is created later it will get its priority set properly.
(This used to be ctdb commit 05c934b10ad2690be9d75c9033a0b849bf16455d)
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.
(This used to be ctdb commit f7dfeb7143f574c2434f7dd16917380dfd1f4f64)
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.
(This used to be ctdb commit 70ba153b532528bdccea70c5ea28972257f384c1)
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.
(This used to be ctdb commit e886ff24f4e3e250944289db95916b948893d26c)
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.
(This used to be ctdb commit 761cb235193564a0f337d0308f0a9e6de0ef2710)
and stop processing of the update_record replies in order to let
the recovery finish the trans3_commit control.
(This used to be ctdb commit cab95570dc1eefb08abbac5ae411c29f699b51cc)
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.
(This used to be ctdb commit 983c1ca2e18ecd60fca69bfe9e116125cc695857)
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.
(This used to be ctdb commit 12cf0619255b12230843cd8bb49cbfdea376ca2f)
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
(This used to be ctdb commit 62b7fe853db37c0a90e48a0332a3426a8dcb4ed8)
One of which signals that the record has never been migrated to/from a node
while containing data.
This property "has never been migrated while non-zero" is important later
to provide heuristics on which records we might be able to purge
from the tdb files cheaply, i.e. without having to rely on the full-blown
database vacuum.
These records are belived to be very common and the pattern would look like
this :
1, no record exists at all.
2, client opens a file
3, samba requests the record for this file
4, an empty record is created on the LMASTER
5, the empty record is migrated to the DMASTER
6, samba writes a <sharemode> to the record locally and the record grows
7, client finishes working the file and closes the file
8, samba removes the sharemode and the record becomes empty again.
9, much later : vacuuming will delete the record
At stage 8, since the record has never been migrated onto a node wile being
non-zero it would be safe, and much more efficient to just delete the record
completely from the database and hand it back to the LMASTER.
The flags occupy the same uint32_t as was previously used for laccessor/lacount
in the header. For now, make sure the flags only define/use the top 16 bits
of this field so that we are sure we dont collide with bits set to one
from previous generations of the ctdb cluster database prior to this
change in semantics of this word.
This is a rework of Michaels patch :
commit 2af1a47cbe1a608496c8caf3eb0c990eb7259a0d
Author: Michael Adam <obnox@samba.org>
Date: Tue Nov 30 17:00:54 2010 +0100
add a DEFAULT record flag and a MIGRATED_WITH_DATA record flag.
(This used to be ctdb commit e075670dee8e6ecaba54986f87a85be3d0528b6b)