VMware Cloud Director maintient la réplication de diffusion synchrone entre les nœuds. Si un nœud en veille devient inaccessible, vous devez déterminer la cause et résoudre le problème.
Problème
L'interface utilisateur de gestion du dispositif VMware Cloud Director affiche la santé du cluster comme étant DEGRADED et l'état de l'un des nœuds en veille est ? inaccessible.
L'API /nodes renvoie des informations indiquant que localClusterHealth est DEGRADED, le nœud status est ? inaccessible et nodeHealth est UNHEALTHY.
/nodes peut renvoyer les informations suivantes pour le nœud.
{
"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"
]
}
Cause
Pour garantir l'intégrité des données, la base de données PostgreSQL utilise la journalisation en écriture anticipée (WAL, Write-Ahead Logging). Le nœud principal transmet constamment la WAL aux nœuds en veille actifs à des fins de réplication et de récupération. Les nœuds en veille traitent la WAL lorsqu'ils la reçoivent. Si un nœud en veille est inaccessible, il cesse de recevoir la WAL et ne peut pas être candidat à une promotion pour devenir un nouveau nœud principal.
Solution
- Vérifiez que la machine virtuelle du nœud en veille inaccessible est en cours d'exécution.
- Vérifiez que la connexion réseau au nœud en veille fonctionne.
- Vérifiez qu'il n'existe aucun problème SSH pouvant empêcher le nœud en veille de communiquer avec les autres nœuds.
- Vérifiez que le service vpostgres sur le nœud en veille est en cours d'exécution.
