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 callback is called for every node where the control failed (or timed out)
when we issue the start recovery control from recovery master,
set any node that fails as a culprit so it will eventually be banned
(This used to be ctdb commit 72f89bac13cbe8c3ca3e7a942469cd2ff25abba2)
note that we dont actually send the ipv6 "gratious arp" on the wire just yet.
(since ipv6 doesnt use arp)
but all the infrastructure is there when we implement sending raw neig.disc. packets
(This used to be ctdb commit b87fab857bc9b3537527be93b7f68484502d6b84)
ctdb_attach() so that we can pass TDB_NOSYNC when we attach to
a persistent database and want fast unsafe writes instead of
slow but safe tdb_transaction writes.
enhance the ctdb_persistent test suite to test both safe and unsafe writes
(This used to be ctdb commit 4948574f5a290434f3edd0c052cf13f3645deec4)
use the timelimit argument to the persistent writer to run the test for
30 seconds by default
(This used to be ctdb commit 181318fea6886c40d0aff02d0de777f28ffeddce)
so that we have n persistent writers on n nodes,
all writers writing persistently to the same record.
each writer on a node has its own "counter" in this record that is incremented by one in each iteration.
the persistent writer on node 0 also checks that all the counters in the record are increasing monotonically and if they are not, flagging it as an ERROR.
(This used to be ctdb commit 00006222ece63ae3b7f3477646232ae5bbeee6f4)
delete all persistent databases when the test starts
(the tests only uses test databases in a special test directory)
do not set up any public addresses in the tests
wait until there are no disconnected or unhealthy nodes when starting the
test daemons instead of waiting for the recovery mode to change.
we do want to wait until the system has recovered and ALL nodes are ok.
(This used to be ctdb commit dfe0c44c1e8e9dab790686c5ba798986d04bf218)
since these two controls (UPDATE_RECORD and PERSISTENT_STORE) can respond
asynchronously to the control, we can not allocate the state variable as a child off ctdb_req_control instead we must allocate state as a child off ctdb itself
and steal ctdb_req_control so it becomes a child of state.
othervise both ctdb_req_control and also state will be released immediately after we have finished setting up the async reply and returned.
(This used to be ctdb commit 6f6de0becd179be9eb9a6bf70562b090205ce196)
With these patches, ctdbd will enforce and (by default) always use
tdb_transactions when updating/writing records to a persistent database.
This might come with a small performance degratation since transactions
are slower than no transactions at all.
If a client, such as samba wants to use a persistent database but does NOT
want to pay the performance penalty, it can specify TDB_NOSYNC as the
srvid parameter in the ctdb_control() for CTDB_CONTROL_DB_ATTACH_PERSISTENT.
In this case CTDBD will remember that "this database is not that important"
so I can use unsafe (no transaction) tdb_stores to write the updates.
It will be faster than the default (always use transaction) but less crash safe.
(This used to be ctdb commit 3d85d2cf669686f89cacdc481eaa97aef1ba62c0)
for stores into persistent databases, ALWAYS use a lockwait child take out the lock for the record and never the daemon itself.
(This used to be ctdb commit 7fb6cf549de1b5e9ac5a3e4483c7591850ea2464)
the address might be a public address on a different node so no need to fiull up the logs with thoise messages
(This used to be ctdb commit c8181476748395fe6ec5284c49e9d37b882d15ea)
in those cases we accept that we couldnt get a transaction and then just writes the data "unsafely" anyway.
(This used to be ctdb commit 56af7df33456bf10d19b97cb005257720ac0b610)
stored yet.
Fix a cosmetic and annoying warning message when running "service ctdb start" and supress printing out that "warning your ls command to find the persistent databases didnt find any" ...
(This used to be ctdb commit d32b16a4e5ecc31563c6f2767e7d483f3d980284)
just disable the monitoring during the "startrecovery" event and enable it again once recovery has completed
(This used to be ctdb commit 68029894f80804c9f31fc90ed0c1b58f75812c3d)
since this event wont run unless the recovery mode is normal but we
can not know what the recovery mode will be in the future on a remote node
so since we issue these commands that will execute in the future at some other node
it is pointless to try to check if it worked or not
in particular if "failure to successfully run the eventscript" would then trigger a full new recovery which is disruptive and expensive.
(This used to be ctdb commit 2c292039a0139dcf5bb2bd964eb6f8902d094c50)
