Automatiser le basculement dans PostgreSQL 9.1

18

Comment configurer deux serveurs identiques pour le basculement automatique dans PostgreSQL 9.1.

OS

Centos 5
PostgreSQL 9.1 compilé à partir de la source
Le compte utilisateur postgres existe sur les deux machines et possède une clé sans mot de passe ssh pour se connecter aux deux machines.

Ma configuration actuelle:

Configuration du serveur maître:

postgresql.conf:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3
checkpoint_segments = 16    
wal_keep_segments = 8 
archive_mode = on    
archive_command = 'cp "%p" /opt/pgsql91/archive/"%f"'

pg_hba.conf:

 host  replication   all   10.0.66.1/32      trust
 host  replication   all   10.0.66.2/32      trust

Serveur de secours

postgresql.conf et pg_hba.conf sont identiques à ce qui est configuré sur le serveur maître.

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

Grâce à hzRoot, je comprends maintenant comment basculer le serveur de veille en maître.

À l'aide des commandes suivantes, je peux synchroniser le nouvel esclave avec le nouveau maître, puis obtenir la sauvegarde et l'exécution de la réplication.

Sur le nouveau maître (10.0.66.2)

su - postgres
touchez trigger.txt dans / opt / pgsql91 / data /
recovery.conf devient recovery.done
psql -c "; SELECT pg_start_backup ('backup', true)";
rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ --exclude postmaster.pid
psql -c "; SELECT pg_stop_backup ()";

Sur le nouvel esclave (10.0.66.1)

créer le fichier recovery.conf: cp recovery.done vers recovery.conf
vi recovery.conf changer l'adresse IP: primary_conninfo = 'host = 10.0.66.2'
démarrer postgresql

Mes questions sont donc maintenant:

Est-ce la bonne façon de changer de rôle?
Quelqu'un at-il automatisé ce processus, si oui, qu'avez-vous fait?
Si la réplication synchrone est activée, j'ai remarqué que le nouveau serveur maître ne valide aucune transaction car il attend que l'esclave réponde. Il n'y a cependant pas d'esclave car sur l'autre serveur, l'ancien maître est en panne. Est-ce correct ou dois-je désactiver temporairement la réplication synchrone pendant que le nouvel esclave est arrêté?

postgresql failover

— Craig Efrein
source

1. oui correct 2. il est peut-être préférable de ne pas automatiser ce processus. 3. vous avez donc besoin d'au moins 2 esclaves et 1 maître. car comme vous l'avez dit la synchronisation. la réplication a besoin d'au moins 2 nœuds pour pousser la synchronisation des validations. s'il n'y a qu'un seul nœud maître, vous ne pourrez pas vous engager ..

— sftsz

les étapes 4, 5 et 6 ne sont pas nécessaires sur le nouveau maître car, bien, vous répliquez pour commencer. Deuxièmement, que se passe-t-il si le maître est décédé et était hors ligne - vous ne pourriez pas vous y connecter. Les étapes 4, 5 et 6 sont généralement effectuées sur un nouveau nœud esclave rejoignant le pool de réplication.

— Eric

@Eric pendant que je jouais avec cela, les étapes 4,5,6 sont nécessaires pour ramener l'ancien maître à l'état de travail. Le fait de créer le nouveau primaire de secours crée immédiatement une nouvelle entrée WAL, il est donc maintenant de 1 entrée devant l'ancien maître. Le démarrage de l'ancien maître en mode veille m'a provoqué des erreurs, j'ai donc dû effectuer les étapes 4, 5, 6 sur l'ancien maître pour le synchroniser avec le nouveau maître (en utilisant pg_basebackup, qui peut diffuser l'intégralité du xlog à partir du nouveau maître - remplace les étapes 4,5,6 en postgres> = 9,1 je pense). Ai-je raison ou ai-je fait quelque chose de mal et cela ne devrait pas être nécessaire?

— Dalibor Filus

8

Découvrez repmrg :

repmgr est un ensemble d'outils open source qui aide les administrateurs de base de données et les administrateurs système à gérer un cluster de bases de données PostgreSQL.

En tirant parti de la fonction de redondance d'UC introduite dans PostgreSQL 9, repmgr simplifie considérablement le processus de configuration et de gestion de la base de données avec des exigences de haute disponibilité et d'évolutivité.

repmgr simplifie l'administration et la gestion quotidienne, améliore la productivité et réduit les coûts globaux d'un cluster PostgreSQL en:

surveiller le processus de réplication; permettant aux administrateurs de base de données d'émettre un nombre élevé

les opérations de disponibilité telles que les commutations et les basculements.

Cela fait deux choses:

repmgr: programme de commande qui effectue des tâches sur votre cluster puis se ferme
repmgrd: démon de gestion et de surveillance qui surveille le cluster et peut automatiser les actions à distance.

Pour le basculement automatique, repmgrd fait l'affaire et n'est pas un SPOF dans votre réseau, comme pgPool. Cependant, il est toujours important de surveiller tous les démons et de les récupérer après l'échec.

La version 2.0 est sur le point d'être publiée, y compris les RPM.

— Frank Heikens
source

Bonjour Frank, merci pour ta réponse. Je n'ai pas entendu parler de repmrg et je vais certainement essayer.

— Craig Efrein

Bonjour Frank encore, Merci pour le repmgr, c'était exactement ce que je cherchais. J'ai finalement pu l'essayer aujourd'hui.

— Craig Efrein

4

dans votre fichier recovery.conf, vous devez ajouter une ligne qui indique à postgres de basculer du maître à l'esclave. vous devez ajouter

trigger_file = '/any/file/to/trigger'

lorsque vous créez ce fichier sur un chemin donné. les nœuds vont changer. (le fichier n'inclut rien, c'est juste un déclencheur)

vous pouvez trouver des informations supplémentaires sur la réplication en streaming

d'autre part, il sera peut-être possible de le créer automatiquement avec quelques astuces mais utiliser des outils de surveillance et faire du basculement manuel sera mieux ..

— sftsz
source

Merci pour votre réponse. Cela peut prendre quelques jours avant que je puisse le tester, mais je reviendrai certainement vers vous.

— Craig Efrein

Je vais vous donner +1 pour la réponse trigger_file qui m'a aidé à rationaliser considérablement le processus. Ce n'est pas la réponse complète qui est de savoir comment automatiser complètement le processus. Une autre chose que j'ai remarquée est que pendant que le maître était en panne, les transactions ne se terminaient pas car il attendait que le maître acquitte. Ce

— problème a

C'est assez génial. J'ai beaucoup de critiques concernant le manque de flexibilité dans l'implémentation de la réplication de PostgreSQL, mais c'est un excellent moyen simple de gérer le basculement.

— Aaron Brown

1

Il reprend cependant le rôle de maître même lorsque le maître lui-même est toujours en cours d'exécution (vous avez donc deux maîtres). Ceci n'est pas automatisé par postgres lui-même.

— Dalibor Filus

0

Quelqu'un at-il envisagé d'utiliser pgpool-II pour cela?

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr_setting/index.html

J'installe la réplication pour PostgreSQL. Il semble que la partie délicate se passe lorsque le vieux maître revient.

D'après ce que j'ai lu, pgpool semble pouvoir automatiser la plupart de cela. Cependant, je ne suis pas sûr de tirer parti des fonctionnalités de réplication déjà présentes dans PostgreSQL 9.1.

— Paulo SantAnna
source

1

pgPool est un point de défaillance unique, vous perdez tout quand il tombe en panne.

— Frank Heikens

1

Merci pour votre réponse. J'ai essayé PGPool II avec des résultats mitigés sur CentOS et Debian et j'ai finalement abandonné.

— Craig Efrein

1

Pourquoi ne pas utiliser pgpool II avec HAproxy? Avec un battement de coeur et une écoute IP flottante?

— mikiemorales

Juste pour référence historique, pgpool-ii ne fonctionne pas actuellement sur Windows.

— tommed