Seul Basculement de la base de données MGMTPOSTGRES_SLAVE de support à MGMTPOSTGRES_MASTER

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)

Composants utilisés

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.

Informations générales

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