VMware Cloud Director mantiene una replicación de transmisión sincrónica entre los nodos. Si un nodo en espera se desconecta, debe determinar la causa y solucionar el problema.

Problema

La interfaz de usuario de administración del dispositivo de VMware Cloud Director muestra el estado del clúster como DEGRADED, el estado de uno de los nodos en espera desconectado es running y hay un signo de exclamación (!) delante del nombre del nodo ascendente para el nodo en espera.

El registro de PostgreSQL muestra que el elemento principal ha eliminado un segmento del 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

La API /nodes devuelve información que indica que localClusterHealth es DEGRADED, el status del nodo es running, el nodeHealth es HEALTHY. Hay un signo de exclamación (!) delante del nombre del nodo ascendente de la API en espera y la API /nodes devuelve una advertencia que indica que el nodo en espera no está asociado a su nodo ascendente.

Por ejemplo, es posible que la API /nodes devuelva la siguiente información para el nodo.
{
    "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 nodo en espera se desconecta, debe volver a asociarlo tan pronto como sea posible. Si el nodo permanece sin asociar durante demasiado tiempo, es posible que se produzca un retraso en el procesamiento de los registros WAL de transmisión continua desde la instancia del elemento principal hasta tal punto que no pueda reanudar la replicación.

Causa

Para garantizar la integridad de los datos, la base de datos de PostgreSQL utiliza el registro de escritura anticipada (WAL). El nodo principal transmite el WAL constantemente a los nodos en espera activos con fines de replicación y recuperación. Los nodos en espera procesan el WAL cuando lo reciben. Si se desconecta un nodo en espera, este deja de recibir el WAL y no puede ser un candidato para la promoción a fin de convertirse en un nuevo elemento principal.

Solución

  1. Implemente un nuevo nodo en espera.
  2. Elimine del registro el nodo en espera sin asociar.

Qué hacer a continuación

Consulte la Recuperarse de un error de celda en espera en un clúster de alta disponibilidad.