From 409ede2d1f15cebc3f8cb57e5074d5997da587fa Mon Sep 17 00:00:00 2001 From: Andreas Schneider Date: Mon, 3 Apr 2023 09:48:38 +0200 Subject: [PATCH] ctdb:doc: Fix code spelling Best reviewed with: `git show --word-diff`. Signed-off-by: Andreas Schneider Reviewed-by: Andrew Bartlett --- ctdb/doc/ctdb-tunables.7.xml | 2 +- ctdb/doc/ctdb.1.xml | 16 ++++++++-------- ctdb/doc/readonlyrecords.txt | 4 ++-- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/ctdb/doc/ctdb-tunables.7.xml b/ctdb/doc/ctdb-tunables.7.xml index 700709eb86f..df7b0ea9dc9 100644 --- a/ctdb/doc/ctdb-tunables.7.xml +++ b/ctdb/doc/ctdb-tunables.7.xml @@ -131,7 +131,7 @@ MonitorInterval=20 DatabaseMaxDead Default: 5 - Maximum number of dead records per hash chain for the tdb databses + Maximum number of dead records per hash chain for the tdb databases managed by ctdb. diff --git a/ctdb/doc/ctdb.1.xml b/ctdb/doc/ctdb.1.xml index 6f9a1764ee4..65c254762eb 100644 --- a/ctdb/doc/ctdb.1.xml +++ b/ctdb/doc/ctdb.1.xml @@ -252,8 +252,8 @@ Generation - The generation id is a number that indicates the current generation - of a cluster instance. Each time a cluster goes through a + The generation id is a number that indicates the current generation + of a cluster instance. Each time a cluster goes through a reconfiguration or a recovery its generation id will be changed. @@ -299,11 +299,11 @@ RECOVERY - The cluster databases have all been frozen, pausing all services while the cluster awaits a recovery process to complete. A recovery process should finish within seconds. If a cluster is stuck in the RECOVERY state this would indicate a cluster malfunction which needs to be investigated. - Once the leader detects an inconsistency, for example a node - becomes disconnected/connected, the recovery daemon will trigger a + Once the leader detects an inconsistency, for example a node + becomes disconnected/connected, the recovery daemon will trigger a cluster recovery process, where all databases are remerged across the cluster. When this process starts, the leader will first - "freeze" all databases to prevent applications such as samba from + "freeze" all databases to prevent applications such as samba from accessing the databases and it will also mark the recovery mode as RECOVERY. @@ -321,7 +321,7 @@ This is the cluster node that is currently designated as the leader. This node is responsible of monitoring the consistency of the cluster and to perform the actual - recovery process when reqired. + recovery process when required. Only one node at a time can be the designated leader. Which @@ -1127,7 +1127,7 @@ DB Statistics: locking.tdb This command is used to administratively STOP a node in the cluster. A STOPPED node is connected to the cluster but will not host any - public ip addresse, nor does it participate in the VNNMAP. + public ip addresses, nor does it participate in the VNNMAP. The difference between a DISABLED node and a STOPPED node is that a STOPPED node does not host any parts of the database which means that a recovery is required to stop/continue nodes. @@ -1183,7 +1183,7 @@ DB Statistics: locking.tdb specific node. - In order to manually override the "automatic" distribution of public + In order to manually override the "automatic" distribution of public ip addresses that ctdb normally provides, this command only works when you have changed the tunables for the daemon to: diff --git a/ctdb/doc/readonlyrecords.txt b/ctdb/doc/readonlyrecords.txt index cc6d7ee269d..e7be1c313b2 100644 --- a/ctdb/doc/readonlyrecords.txt +++ b/ctdb/doc/readonlyrecords.txt @@ -121,7 +121,7 @@ very many readonly requests. The ctdb_db structure is expanded so that it contains one extra TDB database for each -normal, non-persistent datbase. +normal, non-persistent database. This new database is used for tracking delegations for the records. A record in the normal database that has "HAVE_DELEGATION" set will always have a corresponding record at the same key. This record contains the set of all nodes that @@ -334,7 +334,7 @@ Non-readonly enabled daemons fetching records from Readonly enabled daemons: Non-readonly enabled daemons do not know, and never set the WANT_READONLY flag so these daemons will always request a full migration for a full fetch-lock for all records. Thus a request from a non-readonly enabled daemon will always cause any existing delegations to be immediately revoked. Access will work but performance may be harmed since there will be a lot of revoking of delegations. Readonly enabled daemons fetching records with WANT_READONLY from non-readonly enabled daemons: -Non-readonly enabled daemons ingore the WANT_READONLY flag and never return delegations. They always return a full record migration. +Non-readonly enabled daemons ignore the WANT_READONLY flag and never return delegations. They always return a full record migration. Full record migration is allowed by the protocol, even if the originator only requests the 'hint' WANT_READONLY, so this access also interoperates between daemons with different capabilities.