VMware Cloud Director mantiene una replicación de transmisión sincrónica entre los nodos. Si un nodo en espera se vuelve inaccesible, 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 y el estado de uno de los nodos en espera es unreachable.

La API /nodes devuelve información que indica que localClusterHealth es DEGRADED, el status del nodo es unreachable y nodeHealth es UNHEALTHY.

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=unreachable_standby_host_IP user=repmgr dbname=repmgr connect_timeout=2",
            "failover": {
                "details": "failover state unknown - unable to ssh to failed or unreachable node",
                "mode": "UNKNOWN",
                "repmgrd": {
                    "details": "On node unreachable_standby_node_ID (unreachable_standby_host_name): repmgrd = n/a",
                    "status": "UNKNOWN"
                }
            },
            "id": unreachable_standby_node_ID,
            "location": "default",
            "name": "unreachable_standby_host_name",
            "nodeHealth": "UNHEALTHY",
            "nodeRole": "STANDBY",
            "role": "standby",
            "status": "? unreachable",
            "upstream": "primary_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_IP): 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": "primary_host_name"
        }
    ],
    "warnings": [
        "unable to connect to node \"unreachable_standby_host_name\" (ID: unreachable_standby_node_ID)",
        "node \"unreachable_standby_host_name\" (ID: unreachable_standby_node_ID) is registered as an active standby but is unreachable"
    ]
}

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 no se puede acceder a 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

  • Compruebe que la máquina virtual del nodo en espera al que no se puede acceder esté en ejecución.
  • Compruebe que la conexión de red con el nodo en espera esté funcionando.
  • Compruebe que no haya ningún problema de SSH que impida que el nodo en espera se comunique con los otros nodos.
  • Compruebe que el servicio vpostgres en el nodo en espera esté en ejecución.

Qué hacer a continuación

Para comprobar que no haya problemas de red o de SSH, consulte Comprobar el estado de conectividad de un clúster de alta disponibilidad de la base de datos.