Vous n'êtes pas identifié(e).
Pages : 1
Bonjour tout le monde.
J'ai lu dans la doc officielle de postgres (en français) ceci:
Le failover (ou bascule sur incident) sur disque partagé élimine la surcharge de synchronisation par l'existence d'une seule copie de la base de données. Il utilise un seul ensemble de disques partagé par plusieurs serveurs. Si le serveur principal échoue, le serveur en attente est capable de monter et démarrer la base comme s'il récupérait d'un arrêt brutal. Cela permet un failover rapide sans perte de données.
Je que j'ai compris c'est qu'il faudra seulement un cluster demarré car le "$PGDATA" est commun : (vrai ou faux)?
Mon besoin ou plutôt ce qu'on me de demande est d'avoir 2 exigences à la fois voir plus. Un sercice continu et une reprise avec le dernier commit si problème sur le maître.
Le failover sur disque partagé d'après ma compréhension ne réponds pas à un service continue. Le log-shipping non plus.
Le streaming réplication ne me garantie pas le dernier commit et le hot-standbay ne me permet pas une rapidété de lecture/ecriture sur la base vue ce qu'on lui demande de faire de plus il faut multiplier les machines ce que ne plait pas forcément aux directeurs et aux chefs de projet car il veulent plus fiable et moin cher...!
Est ce que quelqu'un pourra me conseiller une architecture optimale avec 2 machines à disposition. Pour moi je peux faire du streaming réplication vu que c'est le plus rapide à mon sens mais avec un service continue si on rajoute une bascule avec pacemaker mais je cherche à avoir une fiabilité et non perte de donnée.
Merci d'avance.
Hors ligne
Bonjour,
Je que j'ai compris c'est qu'il faudra seulement un cluster demarré car le "$PGDATA" est commun : (vrai ou faux)?
Vrai, et il faut faire très attention de ne démarrer qu'un seul serveur à la fois, sinon c'est la corruption garantie. Cela garantie la reprise de service en cas de crash de postgres, mais le stockage est alors un SPOF.
La réplication synchrone (disponible à partir de la version 9.1) garantie qu'aucun commit ne sera perdu en cas de crash. En cas de crash, si le dernier wal est toujours accessible, toutes les transactions commitées pourront être récupérées. Pour la multiplication des serveurs, il est des fois plus rentable d'avoir un plus grand nombre de serveurs moins puissants sur lesquels répartir la charge plutôt qu'avoir un serveur surpuissant.
Pour une "architecture optimale", cela dépend du type d'application et de la finalité voulue. En cas de fail over, les connexions devront basculer sur le nouveau maître, et les transactions en cours seront bien évidemment annulées. Un bon point de départ serait une architecture maître esclave synchrone sur des baises disques distinctes. Vous pouvez également regarder du coté de pgbouncer, ipvs ou haproxy pour minimiser les interruptions de service, et faire de la balance de charge.
Julien.
https://rjuju.github.io/
Hors ligne
Merci Julien,
Donc ci je comprend bien c'est un architecture Hotstandby (pour la replication synchrone) au niveu du paramètre "wal_level"=hot_standby et pas archive?
Une question très importante: Je sais que le minimum syndical est 2 machine pour maître et esclave ( ce que je dispose) mais à ton avis combien de machines faut -t- il et quel est le rôle des autres machine s'il en faut plus?
Une deuxiem pour le repertoire partagé du premier cas, comment mettre en place ce repertoire? Je pense qu'il faut le dupliquer, faut il utiliser DRBD pour le faire.
Bien à toi
Hors ligne
Le paramètre wal_level à 'hot_standby' permet d'avoir assez d'informations dans les wal pour qu'un esclave puisse être accessible en lecture seule. Pour que la réplication soit synchrone, il changer le paramètre 'synchronous_standby_names', et que le paramètre 'synchronous_commit' soit à on (ou remote_write en 9.2 pour une réplication synchrone en mémoire).
L'idéal est de disposer d'une machine en réplication synchrone réservée au PCA/PRA qui ne soit pas accédée en lecture afin de ne pas trop pénaliser les performances du maître. Tu peux ensuite ajouter d'autres esclaves si besoin pour répartir l'activité en lecture seule, en changeant les paramètres 'max_standby_streaming_delay' et 'max_standby_archive_delay' au besoin sur ceux-ci.
Pour le répertoire partagé, l'idée est d'avoir une tolérance sur le service postgres, en considérant que le stockage est sûr (raid 10, spare disk, liaisons et alimentations redondées etc). DRBD peut effectivement répliquer les données sur un autre stockage, mais il sera moins performant que la réplication interne de postgres, et surtout limité à 2 noeuds.
Julien.
https://rjuju.github.io/
Hors ligne
Je commence à voir plus claire. D'abord je veux juste préciser que peut être je pose des questions parfois banales et évidentes. Le problème c'est que c'est une responsabilité et je n'ai pas envie de subir des concéquences dont je n'ai pas besoin de faire un dessin. Bref
Si je me permet de résumer:
- La version e postgres sera la 9.2 (c'est déjà pris en compte et acquis pas de pbm).
- Un master/slave en hote standby pour la synchro. (avec les paramètres qui vont bien).
- La solution répertoire partagé n'ai pas conseillée dans mon cas car je ne dispose pas du raid 10. (je n'ai que du raid5 avec 3 disques). Ce n'ai pas conseillé je sais mais ce n'ai pas moi qui décide. En revanche j'ai lapossibilité du choisir du raid1.
Questions:
- Pour confirmation en cas de failover, c'est le 'pg_ctl promote' qu'il faut pour mettre l'esclave en maître?
- La reconstruction de l'ancien maître en esclave se fait via 'pg_basbackup'?
- Entre du raid5 avec 3 disque et du raid1, que choisir? et pour quel repertoire sur fs '$PGDATA', '$PGLOG' et '$PGXLOG'?
A préciser que je vais partir sur une solution de replication hot standby 1master/1slave (c'est tout ce que j'ai comme ressources). Je vais essayer de demander une 3e pour slave2 mais ce n'ai pas gagné. Qu'en penses tu?
Je vais voir d'avantage ce que fait pgbouncer il a l'air pas trop compliqué.
Bien à toi
Hors ligne
Pour promouvoir un esclave en maître, il y a la commande pg_ctl promote, ou la création d'un fichier trigger, paramétré avec l'option trigger_file du recovery.conf
La reconstruction peut se faire avec pg_basebackup, ou avec un pg_start_backup(), copie des fichiers, pg_stop_backup(). Dans le cas d'une grosse instance, la reconstruction peut être plus rapide en utilisant rsync plutôt qu'une copie entière.
Le raid5 est vraiment à proscrire pour les bases de données. Cela dépend bien évidemment de la volumétrie de la base (par exemple si toute la base tient en ram, cela n'est pas trop problématique). Avoir un filesystem dédié pour le répertoire pg_xlog permettra de gagner en performances. Le répertoire pg_clog n'a pas besoin d'être séparé, le gain sera presque inexistant.
Avoir un 2ème esclave peut permettre de répartir la charge pour soulager le maître. Idéalement il faut que cela soit prévu dans l'application, sinon cela impose d'avoir un outil tiers tel que pgpool, mais cela nuira aux performances imposera quelques restrictions.
Julien.
https://rjuju.github.io/
Hors ligne
Merci Julien,
En revanche concernant le rsync à quel niveau il faut l'utiliser. Est ce que au niveau du fichier "recovery.conf" sur la ligne 'restore_command' ou elle est parametrable quelque part? merci de m'apporter qq précisions et ou m'aiguiller vers un tuto sur le web.
Pour le Raid dans mon cas on peut dire que le raid1 sera adopter par rapport au raid5; on est d'acord.
Bien à toi
Hors ligne
Le restore_command paramètre la façon dont sont récupérés les wal. En cas de copie réseau, il est préférable d'utiliser rsync plutôt que scp car rsync est atomique. Si tu ne fais pas de sauvegarde PITR, les wal peuvent être directement archivés sur l'esclave, et le restore_command sera alors un simple cp.
Je parlais plutôt du rsync pour la reconstruction de l'esclave. En effet, si peu de données on changées depuis la promotion de l'esclave en maître, un rsync du nouveau maître vers l'ancien maître sera probablement plus rapide qu'une recopie entière de la base (que ferais pg_basebackup). La reconstruction doit se faire manuellement (ou par script bien entendu) car il n'y a aucun paramètre permettant de configurer cela.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
