O VMware Cloud Director mantém a replicação síncrona de streaming entre os nós. Se um nó em espera ficar desconectado, você deverá determinar a causa e resolver o problema.

Problema

A UI de gerenciamento de dispositivo do VMware Cloud Director mostra a integridade do cluster como DEGRADED, o status de um dos nós em espera desconectados é em execução e há um ponto de exclamação (!) antes do nome do nó upstream do nó em espera.

O log do PostgreSQL mostra que o nó primário excluiu um segmento de 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

A API /nodes retorna informações de que localClusterHealth está DEGRADED, o status do nó é em execução e nodeHealth é HEALTHY. Há um ponto de exclamação (!) antes do nome do nó upstream do nó em espera, e a API /nodes retorna um aviso de que o nó em espera não está conectado ao seu nó upstream.

Por exemplo, a API /nodes pode retornar as seguintes informações para o nó.
{
    "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)"
    ]
}

Se um nó em espera se tornar desconectado, você deverá reconectá-lo o mais rápido possível. Se o nó permanecer desconectado por muito tempo, ele poderá ficar para trás no processamento dos registros de WAL em streaming contínuo do nó primário, a ponto de talvez que não seja possível para ele retomar a replicação.

Causa

Para garantir a integridade dos dados, o banco de dados PostgreSQL usa o WAL (Write-Ahead Logging). O nó primário transmite o WAL constantemente aos nós ativos em espera para fins de replicação e recuperação. Os nós em espera processam o WAL quando o recebem. Se um nó em espera ficar desconectado, ele deixará de receber o WAL e não poderá ser um candidato para se tornar um novo nó primário.

Solução

  1. Implante um novo nó em espera.
  2. Cancele o registro do nó em espera desconectado.

O que Fazer Depois

Consulte Recuperar de uma falha de célula em espera em um cluster de alta disponibilidade.