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
       <title>DatabaseMaxDead</title>
       <para>Default: 5</para>
       <para>
-	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.
       </para>
     </refsect2>
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 @@
       <refsect3>
 	<title>Generation</title>
 	<para>
-	  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.
 	</para>
 	<para>
@@ -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.
 	</para>
 	<para>
-	  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.
 	</para>
@@ -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.
 	</para>
 	<para>
 	  Only one node at a time can be the designated leader. Which
@@ -1127,7 +1127,7 @@ DB Statistics: locking.tdb
       <para>
 	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.
       </para>
       <para>
-	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:
       </para>
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.