VMware Cloud Director erhält die synchrone Streaming-Replizierung zwischen den Knoten aufrecht. Wenn ein Standby-Knoten nicht mehr erreichbar ist, müssen Sie die Ursache ermitteln und das Problem beheben.
Problem
Die Verwaltungsbenutzeroberfläche der VMware Cloud Director-Appliance zeigt die Clusterintegrität als DEGRADED an, und der Status eines der Standard-Knoten lautet ? nicht erreichbar.
Die /nodes-API gibt die folgenden Informationen zurück: localClusterHealth ist DEGRADED, der status des Knotens lautet ? nicht erreichbar und nodeHealth ist UNHEALTHY.
/nodes-API gibt möglicherweise die folgenden Informationen für den Knoten zurück.
{
"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"
]
}
Ursache
Um die Datenintegrität zu gewährleisten, verwendet die PostgreSQL-Datenbank Write-Ahead Logging (WAL). Der primäre Knoten streamt WAL zu Replizierungs- und Wiederherstellungszwecken konstant zu den aktiven Standby-Knoten. Die Standby-Knoten verarbeiten WAL, wenn sie es empfangen. Wenn ein Standby-Knoten nicht erreichbar ist, empfängt er kein WAL mehr und kann kein Kandidat für die Heraufstufung zum neuen primären Knoten mehr sein.
Lösung
- Vergewissern Sie sich, dass die virtuelle Maschine des nicht erreichbaren Standby-Knotens ausgeführt wird.
- Vergewissern Sie sich, dass die Netzwerkverbindung zum Standby-Knoten funktioniert.
- Vergewissern Sie sich, dass kein SSH-Problem vorliegt, das die Kommunikation des Standby-Knotens mit den anderen Knoten verhindern könnte.
- Vergewissern Sie sich, dass der vpostgres-Dienst auf dem Standby-Knoten ausgeführt wird.
