VMware Cloud Director erhält die synchrone Streaming-Replizierung zwischen den Knoten aufrecht. Wenn ein Standby-Knoten nicht mehr angehängt ist, müssen Sie die Ursache ermitteln und das Problem beheben.

Problem

Die Verwaltungsbenutzeroberfläche der VMware Cloud Director-Appliance zeigt die Clusterintegrität als DEGRADED an, der Status eines der nicht angehängten Standard-Knoten lautet wird ausgeführt und ein Ausrufezeichen (!) wird vor dem Namen des Upstream-Knotens für das Standby angezeigt.

Das PostgreSQL-Protokoll zeigt, dass der primäre Knoten ein WAL-Segment gelöscht hat.
2020-10-08 04:10:50.064 UTC [13390] LOG:  started streaming WAL from primary at 21/80000000 on timeline 17
2020-10-08 04:10:50.064 UTC [13390] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000110000002100000080 has already been removed
2020-10-08 04:10:55.047 UTC [13432] LOG:  started streaming WAL from primary at 21/80000000 on timeline 17
2020-10-08 04:10:55.047 UTC [13432] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000110000002100000080 has already been removed

Die /nodes-API gibt die folgenden Information zurück:localClusterHealth ist DEGRADED, der status des Knotens lautet wird ausgeführt und nodeHealth ist HEALTHY. Ein Ausrufezeichen (!) wird vor dem Namen des Upstream-Knotens für das Standby angezeigt und die /nodes-API gibt eine Warnmeldung zurück, dass der Standby-Knoten nicht an seinen Upstream-Knoten angehängt ist.

Beispiel: Die /nodes-API gibt möglicherweise die folgenden Informationen für den Knoten zurück.
{
    "localClusterFailover": "MANUAL",
    "localClusterHealth": "DEGRADED",
    "localClusterState": [
        {
            "connectionString": "host=primary_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "failover = manual",
                "mode": "MANUAL",
                "repmgrd": {
                    "details": "On node primary_node_ID (primary_host_name): repmgrd = not applicable",
                    "status": "NOT APPLICABLE"
                }
            },
            "id": primary_node_ID,
            "location": "default",
            "name": "primary_host_name",
            "nodeHealth": "HEALTHY",
            "nodeRole": "PRIMARY",
            "role": "primary",
            "status": "* running",
            "upstream": ""
        },
        {
            "connectionString": "host=unattached_standby_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "failover = manual",
                "mode": "MANUAL",
                "repmgrd": {
                    "details": "On node unattached_standby_node_ID (unattached_standby_host_name): repmgrd = not applicable",
                    "status": "NOT APPLICABLE"
                }
            },
            "id": unattached_standby_node_ID,
            "location": "default",
            "name": "unattached_standby_host_name",
            "nodeHealth": "HEALTHY",
            "nodeRole": "STANDBY",
            "role": "standby",
            "status": "running",
            "upstream": "! upstream_host_name"
        },
        {
            "connectionString": "host=running_standby_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "failover = manual",
                "mode": "MANUAL",
                "repmgrd": {
                    "details": "On node running_standby_node_ID (running_standby_host_name): repmgrd = not applicable",
                    "status": "NOT APPLICABLE"
                }
            },
            "id": running_standby_node_ID,
            "location": "default",
            "name": "running_standby_host_name",
            "nodeHealth": "HEALTHY",
            "nodeRole": "STANDBY",
            "role": "standby",
            "status": "running",
            "upstream": "upstream_host_name"
        }
    ],
    "warnings": [
        "node \"unattached_standby_host_name\" (ID: unattached_standby_node_ID) is not attached to its upstream node \"upstream_host_name\" (ID: upstream_node_id)"
    ]
}

Wenn ein Standby-Knoten nicht mehr angehängt ist, müssen Sie ihn so bald wie möglich wieder anhängen. Wenn der Knoten zu lange nicht mehr angehängt ist, fällt er möglicherweise bei der Verarbeitung des kontinuierlichen Streaming von WAL-Datensätzen vom primären Knoten so stark zurück, dass die Replizierung für ihn möglicherweise nicht mehr fortgesetzt werden kann.

Ursache

Um die Datenintegrität zu gewährleisten, verwendet die PostgreSQL-Datenbank Write-Ahead Logging (WAL). Der primäre Knoten streamt WAL zu Replizierungs- und Wiederherstellungszwecken konstant zu den aktiven Standby-Knoten. Die Standby-Knoten verarbeiten WAL, wenn sie es empfangen. Wenn ein Standby-Knoten nicht mehr angehängt ist, empfängt er kein WAL mehr und kann kein Kandidat für die Heraufstufung zum neuen primären Knoten mehr sein.

Lösung

  1. Stellen Sie einen neuen Standby-Knoten bereit.
  2. Heben Sie die Registrierung des nicht angehängten Standby-Knotens auf.

Nächste Maßnahme

Weitere Informationen finden Sie im Wiederherstellen nach einem Ausfall einer Standby-Zelle in einem Hochverfügbarkeits-Cluster.