Merge pull request #10204 from Icinga/an-HA

doc/: fix "a HA" -> "an HA"
This commit is contained in:
Alexander Aleksandrovič Klimov 2024-10-24 11:30:24 +02:00 committed by GitHub
commit 4ca68e444e
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
4 changed files with 4 additions and 4 deletions

View File

@ -3131,7 +3131,7 @@ object Endpoint "icinga2-master2.localdomain" {
> **Note**
>
> This is required if you decide to change an already running single endpoint production
> environment into a HA-enabled cluster zone with two endpoints.
> environment into an HA-enabled cluster zone with two endpoints.
> The [initial setup](06-distributed-monitoring.md#distributed-monitoring-scenarios-ha-master-clients)
> with 2 HA masters doesn't require this step.

View File

@ -878,7 +878,7 @@ actively attempts to schedule and execute checks. Otherwise the node does not fe
}
```
You may ask why this analysis is important? Fair enough - if the numbers are not inverted in a HA zone
You may ask why this analysis is important? Fair enough - if the numbers are not inverted in an HA zone
with two members, this may give a hint that the cluster nodes are in a split-brain scenario, or you've
found a bug in the cluster.

View File

@ -651,7 +651,7 @@ authority = endpoints[Utility::SDBM(object->GetName()) % endpoints.size()] == my
that by querying the `paused` attribute for all objects via REST API
or debug console on both endpoints.
Endpoints inside a HA zone calculate the object authority independent from each other.
Endpoints inside an HA zone calculate the object authority independent from each other.
This object authority is important for selected features explained below.
Since features are configuration objects too, you must ensure that all nodes

View File

@ -363,7 +363,7 @@ Checkable::ProcessingResult Checkable::ProcessCheckResult(const CheckResult::Ptr
// Don't recompute the next check when the current check isn't generated by this endpoint. When the check is
// remotely generated we should've already received the "SetNextCheck" event before the "event::CheckResult"
// cluster event. Otherwise, the next check received before this check will be invalidated and cause the Checkable
// "next_check/next_update" in a HA setup to always be different from the other endpoint as the "m_SchedulingOffset"
// "next_check/next_update" in an HA setup to always be different from the other endpoint as the "m_SchedulingOffset"
// is randomly initialised on each node.
if (!origin) {
if (cr->GetActive()) {