Introduction
Ce document décrit comment récupérer une batterie MGMTPOSTGRES quand le MGMTPOSTGRES_MASTER est descendu et comment échouer MGMTPOSTGRES_SLAVE de nouveau au MAÎTRE MGMTPOSTGRES_.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Interface de Linux
- Environnement de virtual machine
- Postgresql
- Stimulateur/système configuration de Corosync (PCS)
Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :
- Version 4.8.1.1 de CloudCenter
- Composant MGMTPOSTGRES_SLAVE
- Composant MGMTPOSTGRES_MASTER
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle commande.
Si le composant de MAÎTRE MGMTPOSTGRES_ descend, le mécanisme ha échoue au MGMTPOSTGRES_SLAVE et ce devient le maître parce que le MAÎTRE MGMTPOSTGRES_ est vers le bas.
Problème
Afin d'échouer de nouveau au MAÎTRE MGMTPOSTGRES_, la batterie de base de données doit être récupérée et un processus manuel doit avoir lieu parce que quelques fichiers doivent être supprimés.
Journaux des erreurs :
[root@mgmtpostgres_master etc]# pcs status
Cluster name: cliqrdbcluster
Stack: corosync
Current DC: dbslave (version 1.1.15-11.e174ec8) – partition with quorum
Last updated: Mon Nov 13 19:15:30 2017 Last changed: Mon Nov 13 16:59:51 2017 by root via crm_attribute on db slave
2 nodes and 3 resources configured
Online: [ dbmaster dbslave ]
Full list of resrouces:
Resrouce Group: VIPGroup
PGMasterVIP (ocf::heartbeat:IPaddr2): Started dbslave
Master/Slave Set: mspostgresql [pgsql]
Masters: [ dbslave ]
Stopped: [ dbmaster ]
Failed Actions:
* pgsql_start_0 on dbmaster ‘unknown error’ (1): call=11, status=complete, exitreason=’My data may be inconsistent. You have to remove /var/lib/pgsql/tmp/PGSQL.lock file to force start.’,
last-rc-change=’Mon Nov 13 18:15:25 2017’, queued-0ms, exec=156ms
Daemon Status:
corosyn: active/disabled
pacemaker: active/enabled
pcsd: inactive/enabled
Solution
Des modifications manuelles doivent être faites dans MGMTPOSTGRES_MASTER et MGMTPOSTGRES_SLAVE pour que chacun d'eux forment une batterie et pour que MGMTPOSTGRES_MASTER joue le rôle comme maître de nouveau.
Étape 1. Dans le MGMTPOSTGRES_MASTER et le MGMTPOSTGRES_SLAVE, supprimez le fichier PGSQL.lock.
rm -rf /var/lib/pgsql/tmp/*.lock
Étape 2. Dans MGMTPOSTGRES_MASTER, poursuivez pour nettoyer des ressources.
pcs resource cleanup
Étape 3. Dans MGMTPOSTGRES_MASTER, confirmez que la batterie est en service et il n'y a aucune erreur.
pcs cluster status
pcs status
Note: Il est probable qu'une fois que la batterie est haute et des passages, le VIP aura toujours dans MGMTPOSTGRES_SLAVE comme maître.
Étape 4. Dans MGMTPOSTGRES_MASTER, forcez dans MGMTPOSTGRES_MASTER à assurer le rôle principal du dans MGMTPOSTGRES_SLAVE.
pcs resource move <resource group> <master database>
pcs resource move PGMasterVIP dbmaster
Étape 5. Dans le MGMTPOSTGRES_MASTER, vérifiez qu'il y a réplication (recherchez l'IP dans l'IP MGMTPOSTGRES_SLAVE).
ps –ef | grep postgr
Étape 6. Dans le MGMTPOSTGRES_MASTER, vérifiez qu'il n'y a aucune erreur et que MGMTPOSTGRES_MASTER est la base de données principale qui est utilisée.
pcs status
Commentaires