diff --git a/xml/geo_booth_i.xml b/xml/geo_booth_i.xml index 1fcfbf51..8adb8dbe 100644 --- a/xml/geo_booth_i.xml +++ b/xml/geo_booth_i.xml @@ -327,7 +327,7 @@ ticket = "&ticket2;" INFINITY on all + the dependency-chain has a fail count of INFINITY on all available nodes, the service cannot be run on that site. In that case, it is of no use to claim the ticket. diff --git a/xml/ha_management.xml b/xml/ha_management.xml index 50912b8d..7779ee8d 100644 --- a/xml/ha_management.xml +++ b/xml/ha_management.xml @@ -8,10 +8,10 @@ - The crm_failcount command queries the number of failures per resource on a given node. This tool can also be used to - reset the failcount, allowing the resource to again run on nodes where + reset the fail count, allowing the resource to again run on nodes where it had failed too often. See the crm_failcount man page for a detailed introduction to this tool's usage and command syntax. @@ -178,10 +178,10 @@ from the book, except for a general overview--> - --> - \ No newline at end of file + diff --git a/xml/ha_managing_resources.xml b/xml/ha_managing_resources.xml index 2d538dd3..c17c371a 100644 --- a/xml/ha_managing_resources.xml +++ b/xml/ha_managing_resources.xml @@ -374,7 +374,7 @@ primitive admin_addr IPaddr2 \ Cleaning up cluster resources A resource is automatically restarted if it fails, but each failure - increases the resource's failcount. + increases the resource's fail count. If a migration-threshold has been set for the resource, @@ -382,9 +382,9 @@ primitive admin_addr IPaddr2 \ the migration threshold. - By default, failcounts are not automatically reset. You can configure a failcount + By default, fail counts are not automatically reset. You can configure a fail count to be reset automatically by setting a failure-timeout option for the - resource, or you can manually reset the failcount using either &hawk2; or &crmsh;. + resource, or you can manually reset the fail count using either &hawk2; or &crmsh;. Cleaning up cluster resources with &hawk2; diff --git a/xml/ha_resource_constraints.xml b/xml/ha_resource_constraints.xml index 12ce8eba..9fd245a4 100644 --- a/xml/ha_resource_constraints.xml +++ b/xml/ha_resource_constraints.xml @@ -817,7 +817,7 @@ A resource is automatically restarted if it fails. If that cannot be achieved on the current node, or it fails N times on the current node, it tries to fail over to another node. Each time - the resource fails, its failcount is raised. You can define several + the resource fails, its fail count is raised. You can define several failures for resources (a migration-threshold), after which they will migrate to a new node. If you have more than two nodes in your cluster, the node a particular resource fails over to is chosen @@ -838,12 +838,12 @@ for resource rsc1 to preferably run on &node1;. If it fails there, migration-threshold is checked and compared to the - failcount. If failcount >= migration-threshold then the resource is + fail count. If fail count >= migration-threshold then the resource is migrated to the node with the next best preference. After the threshold has been reached, the node will no longer be - allowed to run the failed resource until the resource's failcount is + allowed to run the failed resource until the resource's fail count is reset. This can be done manually by the cluster administrator or by setting a failure-timeout option for the resource. @@ -862,7 +862,7 @@ - Start failures set the failcount to INFINITY and + Start failures set the fail count to INFINITY and thus always cause an immediate migration. @@ -907,7 +907,7 @@ - If you want to automatically expire the failcount for a resource, add the + If you want to automatically expire the fail count for a resource, add the failure-timeout meta attribute to the resource as described in , @@ -934,8 +934,8 @@ - Instead of letting the failcount for a resource expire automatically, you - can also clean up failcounts for a resource manually at any time. Refer to + Instead of letting the fail count for a resource expire automatically, you + can also clean up fail counts for a resource manually at any time. Refer to for details. @@ -944,7 +944,7 @@ Specifying resource failover nodes with &crmsh; To determine a resource failover, use the meta attribute - migration-threshold. If failcount exceeds + migration-threshold. If fail count exceeds migration-threshold on all nodes, the resource remains stopped. For example: @@ -952,11 +952,11 @@ Normally, rsc1 prefers to run on &node1;. If it fails there, migration-threshold is checked and compared - to the failcount. If failcount >= migration-threshold + to the fail count. If failcount >= migration-threshold then the resource is migrated to the node with the next best preference. - Start failures set the failcount to inf depend on the + Start failures set the fail count to inf depend on the option. Stop failures cause fencing. If there is no STONITH defined, the resource will not migrate.