VMware Cloud Director maintient la réplication de diffusion synchrone entre les nœuds. Si un nœud en veille devient non attaché, vous devez déterminer la cause et résoudre le problème.

Problème

L'interface utilisateur de gestion du dispositif VMware Cloud Director affiche la santé du cluster comme étant DEGRADED, l'état de l'un des nœuds en veille non attachés est en cours d'exécution et il y a un point d'exclamation (!) avant le nom du nœud en amont pour le dispositif en veille.

Le journal PostgreSQL indique que l'instance principale a supprimé un segment WAL.
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

L'API /nodes renvoie des informations indiquant que localClusterHealth est DEGRADED, le nœud status est en cours d'exécution, nodeHealth est HEALTHY. Il y a un point d'exclamation (!) avant le nom du nœud en amont pour le dispositif en veille et l'API /nodes renvoie un avertissement indiquant que le dispositif en veille n'est pas attaché à son nœud en amont.

Par exemple, l'API /nodes peut renvoyer les informations suivantes pour le nœud.
{
    "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)"
    ]
}

Si un nœud en veille devient non attaché, vous devez le rattacher dès que possible. Si le nœud reste non attaché trop longtemps, il peut prendre du retard dans le traitement des enregistrements de WAL diffusés en continu provenant de l'instance principale à tel point qu'il ne puisse pas reprendre la réplication.

Cause

Pour garantir l'intégrité des données, la base de données PostgreSQL utilise la journalisation en écriture anticipée (WAL, Write-Ahead Logging). Le nœud principal transmet constamment la WAL aux nœuds en veille actifs à des fins de réplication et de récupération. Les nœuds en veille traitent la WAL lorsqu'ils la reçoivent. Si un nœud en veille devient non attaché, il cesse de recevoir la WAL et ne peut pas être candidat pour la promotion et devenir un nouveau nœud principal.

Solution

  1. Déployez un nouveau nœud en veille.
  2. Annulez l'enregistrement du nœud en veille non attaché.

Que faire ensuite

Reportez-vous à la section Récupérer après une panne de cellule en veille dans un cluster haute disponibilité.