VMware Cloud Director gestisce la replica streaming sincrona tra i nodi. Se un nodo di standby diventa non collegato, è necessario determinare la causa e risolvere il problema.
Problema
Nell'interfaccia utente di gestione dell'appliance VMware Cloud Director, lo stato dell'integrità del cluster è DEGRADED, lo stato di uno dei nodi di standby non collegati è in esecuzione ed è presente un punto esclamativo (!) prima del nome del nodo upstream per la modalità di standby.
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 restituisce l'informazione che localClusterHealth ha stato DEGRADED, il nodo status è in esecuzione e nodeHealth è HEALTHY. È presente un punto esclamativo (!) prima del nome del nodo upstream per la modalità standby e l'API /nodes restituisce un avviso che indica che il nodo di standby non è collegato al relativo nodo upstream.
/nodes potrebbe restituire le informazioni seguenti per il 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)"
]
}
Se un nodo di standby diventa non collegato, è necessario ricollegarlo non appena possibile. Se il nodo rimane non collegato per troppo tempo, è possibile che accumuli un ritardo nell'elaborazione dei record WAL di streaming continuo provenienti dal nodo primario tale da perdere la possibilità di riprendere la replica.
Causa
Per garantire l'integrità dei dati, il database PostgreSQL utilizza WAL (Write-Ahead Logging). Il nodo primario invia WAL in streaming costantemente ai nodi di standby attivi per scopi di replica e ripristino. I nodi di standby elaborano WAL quando ricevono i relativi dati. Se un nodo di standby diventa non collegato, smette di ricevere WAL e non può essere un candidato per la promozione a nuovo nodo primario.
Soluzione
- Distribuire un nuovo nodo di standby.
- Annullare la registrazione del nodo di standby non collegato.
