Si vous êtes intéressé par la réplication et le basculement de bases de données synchrones, j'ai une suggestion. Vous pouvez envisager d'utiliser deux outils:
DRBD (Disk Replicated Block Device) fournit une réplication au niveau du disque (synchrone) entre les disques sur deux serveurs différents. Les modifications du disque sont répliquées sur le réseau. Il est préférable d'utiliser un câble croisé sur eth2 pour les cartes réseau utilisant le netblock 192.168.xx.
ucarp permet la gestion DBVIP et le basculement entre deux serveurs différents.
Vous pouvez les utiliser conjointement comme suit:
- DBServer1 a l'IP 10.1.2.30
- DBServer2 a l'IP 10.1.2.40
- DB VIP est 10.1.2.70
Configurez ucarp sur deux serveurs différents de telle manière que chaque instance ucarp communique avec l'autre le long d'un ID de routeur virtuel
DBServer1 aura
/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B
DBServer2 aura
/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B
Quelle est la raison pour laquelle -b (diffusions) est 3 sur un serveur et 4 sur l'autre? Si les deux serveurs sont redémarrés, le serveur avec le -b le plus bas amènera en premier ucarp. Quant à -r, c'est le rapport mort. Ainsi, DBServer1 apparaîtra en 15 secondes (3X5) et DBServer2 apparaîtra en 20 secondes (4X5).
Disons que DBServer1 plante. ucarp sur DBServer2 recherchera pendant 20 secondes une poignée de main pour ucarp sur DBServer1. Si rien n'est détecté, le script vip-up.sh sur DBServer2 prendra le contrôle du DBVIP.
OK, tout cela est juste pour le basculement et la gestion DBVIP. Et la base de données PostgreSQL? Étonnamment, PostgreSQL ne fonctionne que sur un serveur à la fois. Celui qui a le DBVIP doit avoir DRBD dans l'état primaire. Cela rejoint le script vip-up. Comment l'écrivez-vous?
Voici le script /usr/local/sbin/vip-down.sh (conceptuel)
#! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up
Voici le script /usr/local/sbin/vip-down.sh (conceptuel)
#! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`
Tout ce que vous devez faire est de configurer pg_hba.conf pour vous assurer que tous les utilisateurs viennent via 10.1.2.70
Essentiellement, vip-up effectue cette séquence
- Faire en sorte que DRBD devienne primaire
- Monter le dossier de données postgres sur / dev / drbd0
- Postgres de démarrage
- démarrer le processus vipmon
Contrawise, vip-down effectue cette séquence
- Postgres d'arrêt
- unount / dev / drbd0
- Faire en sorte que DRBD devienne secondaire
Qu'en est-il de vipmon.sh? Vous pouvez créer un script pour vérifier, dans une boucle indéfinie, l'état de postgres (il est en cours d'exécution), vérifier le périphérique DRBD (pouvez-vous toujours écrire dans le dossier de données des publications)
Avec cette configuration, vous avez des postgres sur le DRBD primaire et une copie au niveau du disque du dossier de données postgres sur l'autre DBServer (le DRBD secondaire). postgres ne fonctionne pas sur le DRBD secondaire.
Lorsqu'un basculement se produit, vous avez juste besoin de temps pour que ucarp détecte qu'il est sûr de monter les données postgres, de démarrer postgres et d'activer le script vipmon.
Ce qui est génial avec cette configuration, c'est qu'en cas de basculement, le DBServer qui devient DRBD Primary devrait avoir une copie à 100% du niveau du disque du serveur dont vous avez échoué. Ainsi, le démarrage de postgres devrait vous mettre à niveau dans un état cohérent. Les journaux de transactions (dans pg_xlog) doivent être intacts (moins l'intermittence due au basculement)
J'espère que ces suggestions aident. Bien que je sois un administrateur de bases de données MySQL, j'utilise régulièrement MySQL et DRBD dans la société d'hébergement Web de mon employeur. J'ai installé MySQL / DRBD de la manière susmentionnée. Je l'ai fait une fois pour un client utilisant PostgreSQL / DRBD. Cela fonctionne très bien. C'est Open Source. Vous avez juste besoin de faire preuve de diligence raisonnable dans l'apprentissage de DRBD et ucarp. Cela comprendrait la reconnexion de DRBD après un basculement, la gestion d'un scénario de cerveau divisé où les deux serveurs DB deviennent principaux, et des choses comme celles-ci.