getmonmode

- This is useful since it allows for keeping continous logs to a file + This is useful since it allows for keeping continuous logs to a file at a reasonable non-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory. This can allow you to avoid having to reproduce an issue due to the @@ -678,7 +678,7 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/var/ctdb/persist This command will dump the content of database backup to the screen (similar to ctdb catdb). This is a debugging command.

getmonmode

- This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands. + This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continuously monitor that all other nodes that are expected are in fact connected and that they respond to commands.

ACTIVE - This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster.

diff --git a/doc/ctdb.1.xml b/doc/ctdb.1.xml index 7924354..78da195 100644 --- a/doc/ctdb.1.xml +++ b/doc/ctdb.1.xml @@ -1050,7 +1050,7 @@ This is mainly useful for backing up persistent databases such as secrets.tdb an CTDBD also keeps a in-memory ringbuffer containing the most recent log entries for all log levels (except DEBUG). - This is useful since it allows for keeping continous logs to a file + This is useful since it allows for keeping continuous logs to a file at a reasonable non-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory. This can allow you to avoid having to reproduce an issue due to the @@ -1181,7 +1181,7 @@ HEALTH: NO-HEALTHY-NODES - ERROR - Backup of corrupted TDB in '/var/ctdb/persist getmonmode - This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continously monitor that all other nodes that are expected are in fact connected and that they respond to commands. + This command returns the monutoring mode of a node. The monitoring mode is either ACTIVE or DISABLED. Normally a node will continuously monitor that all other nodes that are expected are in fact connected and that they respond to commands. ACTIVE - This is the normal mode. The node is actively monitoring all other nodes, both that the transport is connected and also that the node responds to commands. If a node becomes unavailable, it will be marked as DISCONNECTED and a recovery is initiated to restore the cluster. diff --git a/doc/ctdbd.1 b/doc/ctdbd.1 index 5800520..9d0b129 100644 --- a/doc/ctdbd.1 +++ b/doc/ctdbd.1 @@ -191,7 +191,7 @@ Send all log messages to syslog instead of to the ctdb logfile\&. .RS 4 In addition to the normal loggign to a log file, CTDBD also keeps a in\-memory ringbuffer containing the most recent log entries for all log levels (except DEBUG)\&. .sp -This is useful since it allows for keeping continous logs to a file at a reasonable non\-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory\&. This can allow you to avoid having to reproduce an issue due to the on\-disk logs being of insufficient detail\&. +This is useful since it allows for keeping continuous logs to a file at a reasonable non\-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory\&. This can allow you to avoid having to reproduce an issue due to the on\-disk logs being of insufficient detail\&. .sp This in\-memory ringbuffer contains a fixed number of the most recent entries\&. This is settable at startup either through the \-\-log\-ringbuf\-size argument, or preferably by using CTDB_LOG_RINGBUF_SIZE in the sysconfig file\&. .sp @@ -426,7 +426,7 @@ Note: you can use LVS and public addresses at the same time\&. .PP To activate LVS on a CTDB node you must specify CTDB_PUBLIC_INTERFACE and CTDB_LVS_PUBLIC_ADDRESS in /etc/sysconfig/ctdb\&. .PP -You must also specify the "\-\-lvs" command line argument to ctdbd to activete LVS as a capability of the node\&. This should be done automatically for you by the /etc/init\&.d/ctdb script\&. +You must also specify the "\-\-lvs" command line argument to ctdbd to activate LVS as a capability of the node\&. This should be done automatically for you by the /etc/init\&.d/ctdb script\&. .PP Example: .sp diff --git a/doc/ctdbd.1.html b/doc/ctdbd.1.html index 063fbce..acffd47 100644 --- a/doc/ctdbd.1.html +++ b/doc/ctdbd.1.html @@ -131,7 +131,7 @@ CTDBD also keeps a in-memory ringbuffer containing the most recent log entries for all log levels (except DEBUG).

- This is useful since it allows for keeping continous logs to a file + This is useful since it allows for keeping continuous logs to a file at a reasonable non-verbose level, but shortly after an incident has occured, a much more detailed log can be pulled from memory. This can allow you to avoid having to reproduce an issue due to the @@ -373,7 +373,7 @@ ctdb will try to reassign public IP addresses onto the new node as a way to dist To activate LVS on a CTDB node you must specify CTDB_PUBLIC_INTERFACE and CTDB_LVS_PUBLIC_ADDRESS in /etc/sysconfig/ctdb.

-You must also specify the "--lvs" command line argument to ctdbd to activete LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script. +You must also specify the "--lvs" command line argument to ctdbd to activate LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.

Example:

diff --git a/doc/ctdbd.1.xml b/doc/ctdbd.1.xml
index 91e2f9f..f8f9d7f 100644
--- a/doc/ctdbd.1.xml
+++ b/doc/ctdbd.1.xml
@@ -349,7 +349,7 @@
 	    log entries for all log levels (except DEBUG).
           
           
-	    This is useful since it allows for keeping continous logs to a file
+	    This is useful since it allows for keeping continuous logs to a file
 	    at a reasonable non-verbose level, but shortly after an incident has
 	    occured, a much more detailed log can be pulled from memory. This
 	    can allow you to avoid having to reproduce an issue due to the
@@ -737,7 +737,7 @@ ctdb will try to reassign public IP addresses onto the new node as a way to dist
 	
 
 	
-You must also specify the "--lvs" command line argument to ctdbd to activete LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.
+You must also specify the "--lvs" command line argument to ctdbd to activate LVS as a capability of the node. This should be done automatically for you by the /etc/init.d/ctdb script.
 	
 
 	
diff --git a/server/ctdb_vacuum.c b/server/ctdb_vacuum.c
index bdb7c40..50ff45a 100644
--- a/server/ctdb_vacuum.c
+++ b/server/ctdb_vacuum.c
@@ -874,7 +874,7 @@ static int update_tuning_db(struct ctdb_db_context *ctdb_db, struct vacuum_data
 
 		/*
 		 * re-calc new vacuum interval:
-		 * in case no limit was reached we continously increase the interval
+		 * in case no limit was reached we continuously increase the interval
 		 * until vacuum_max_interval is reached
 		 * in case a limit was reached we divide the current interval by 2
 		 * unless vacuum_min_interval is reached
-- 
1.7.4.1