Voici le scénario:
Il existe deux machines exécutant CentOS 6.2 - machine0 et machine1
PostgreSQL 9.1 est installé sur les deux.
L'un d'eux doit être actif, en tant que système maître et par le biais d'une réplication de flux asynchrone sur l'autre machine, le serveur de secours doit copier les modifications dans la base de données à partir du système maître.
En supposant que machine0 est le maître et machine1 est le standby au début.
Si le maître (disons machine0) échoue (l'échec signifie ici que le serveur postgresql plante), le standby doit prendre le relais du maître et devenir le nouveau maître.
machine1, le nouveau maître gère toutes les opérations de la base de données et lorsque le serveur postgresql dans machine0 revient en ligne, il doit devenir un standby, commencer la synchronisation à partir du moment où il a perdu le contact avec machine1 et copier toutes les modifications dans la base de données et rester en mode veille.
Lorsque machine1 échoue, tout le cycle se répète.
Lorsque la veille échoue et revient en ligne, elle doit commencer à lire à partir du maître et synchroniser les données.
Je suis confus quant aux outils que je dois utiliser pour la configuration, car je comprends que PostgreSQL n'est pas fourni avec le basculement par défaut.
Si quelqu'un peut me lier à des fils / pages qui décrivent comment faire ce que j'essaie, je serai vraiment reconnaissant.
la source
Réponses:
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:
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
DBServer2 aura
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)
Voici le script /usr/local/sbin/vip-down.sh (conceptuel)
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
Contrawise, vip-down effectue cette séquence
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.
la source