Vous n'êtes pas identifié(e).
Bonjour,
Dans le cadre d’un projet universitaire, mon groupe souhaiterait mettre en place la réplication sur une grappe de machines avec PostgreSQL 9.3 installé sur chacune de ces machines (même configuration technique, même OS, même version de PostgreSQL).
L’objectif sera de mettre en place un cluster PostgreSQL (1 Master avec 3 Slaves), le cluster PostgreSQL devra se comporter de manière « autonome ».
Par « autonome » il faut comprendre :
• Si un Master meurt, un des Slaves prend automatiquement sa place.
• Un nouveau Slave intégré dans le cluster intègre les données existantes (récupère automatiquement les WAL).
Notes :
• On part du principe que chaque nœud PostgreSQL est susceptible de « tomber » (être Hors-Service) à un moment donné (câble Ethernet coupé, coup de pied dans le serveur etc), donc aucune machine n’est fiable à 100%.
• Nous n’utiliserons que les fonctionnalités de base proposée par PostgreSQL 9.3 (donc pas ajout d’extension du style Bucardo etc).
• Le contenu des fichiers de configuration (postgresql.conf, pg_hba.conf, recovery.conf) seront normalement identiques entre les 4 machines du cluster (sauf si vous m'indiquez une raison contraire).
Nous avons choisi le mode :
• Hot Standby : pour autoriser la lecture sur les Slaves (ou « Standby Server »).
• Synchronous Streaming Replication : pour que la réplication soit « immédiatement » prise en compte par les Slaves avec « accusé de réception » sur le Master.
Questions :
1. Demande de confirmation : Lorsqu’on utilise le Synchonous Streaming Replication, est-ce que le Master envoie 1 WAL pour 1 transaction réalisée en TCP ?
Voici un schéma qui résume les problématiques posées dans les questions 2. et 3. lorsqu'une machine Master A meurt et que les Slaves B, C et D dont le primary_conninfo contient l'addresse IP de A sont toujours en vie.
2. Lorsque l'on démarre les machines du cluster PostgreSQL, sur quel critère une machine devient Master et les autres Slaves ? Est-ce que la négociation entre les machines est « automatique » ? Faut-t-il utiliser une commande manuelle au démarrage du serveur (si oui laquelle) ?
3. Dans la documentation il est dit : « PostgreSQL does not provide the system software required to identify a failure on the primary and notify the standby database server. Many such tools exist and are well integrated with the operating system facilities required for successful failover, such as IP address migration. »
A quel moment un slave devient master ? Quel paramètre faut-t-il mettre en place pour ce processus soit automatique ?
4. Dans la documentation il est dit : « If the primary server fails and the standby server becomes the new primary, and then the old primary restarts, you must have a mechanism for informing the old primary that it is no longer the primary. This is sometimes known as STONITH (Shoot The Other Node In The Head), which is necessary to avoid situations where both systems think they are the primary, which will lead to confusion and ultimately data loss. »
Est-ce que ce mécanisme appelé STONITH est automatiquement géré par PostgreSQL ou bien doit-t-on mettre quelque chose de spécifique en place ?
5. Comment mettre en place le failover lorsqu’on a plusieurs slaves ? (on sait à peu près comment faire avec 1 slave, mais pas avec plusieurs slaves).
6. Dans la documentation il est dit : « In standby mode, the server continuously applies WAL received from the master server. The standby server can read WAL from a WAL archive (see restore_command) or directly from the master over a TCP connection (streaming replication). »
Je sais que pour le mode Streaming Replication la réplication sur le Slave est plus ou moins « immédiate ». Dans le cas où on n’utilise pas le Streaming Replication, quel paramètre du Slave indique la périodicité pour intégrer les WALs du Master dans le Slave ?
7. Vocabulaire : Quelle est la différence entre un WAL, un « journal de transaction » et un « fichier de log » ?
N'hésitez pas à me dire s'il y a des questions que vous ne comprenez pas.
Je vous remercie par avance, cordialement,
Dernière modification par guk92 (25/04/2015 16:16:46)
Hors ligne
1. Demande de confirmation : Lorsqu’on utilise le Synchonous Streaming Replication, est-ce que le Master envoie 1 WAL pour 1 transaction réalisée en TCP ?
Tout dépend de ce que vous appelez WAL. Si vous parlez d'un segment de journal de transactions, alors non.
2. Lorsque l'on démarre les machines du cluster PostgreSQL, sur quel critère une machine devient Master et les autres Slaves ?
Les esclaves sont créés à partir du maître. Les esclaves savent donc qu'ils sont esclaves.
Est-ce que la négociation entre les machines est « automatique » ?
Pas de négotiation.
Faut-t-il utiliser une commande manuelle au démarrage du serveur (si oui laquelle) ?
Non, un serveur PostgreSQL sait automatiquement dans quel mode il est.
3. Dans la documentation il est dit : « PostgreSQL does not provide the system software required to identify a failure on the primary and notify the standby database server. Many such tools exist and are well integrated with the operating system facilities required for successful failover, such as IP address migration. »
A quel moment un slave devient master ?
Quand on lui demande (par exemple avec un trigger file).
Quel paramètre faut-t-il mettre en place pour ce processus soit automatique ?
Je crois que vous n'avez pas bien saisi le "PostgreSQL does not [...] notify the standby database server. ". Il n'y a aucun paramètre parce que PostgreSQL ne le fait pas. Vous devez installer un logiciel tiers pour ça, style repmgr ou le couple pacemaker/corosync.
4. Dans la documentation il est dit : « If the primary server fails and the standby server becomes the new primary, and then the old primary restarts, you must have a mechanism for informing the old primary that it is no longer the primary. This is sometimes known as STONITH (Shoot The Other Node In The Head), which is necessary to avoid situations where both systems think they are the primary, which will lead to confusion and ultimately data loss. »
Est-ce que ce mécanisme appelé STONITH est automatiquement géré par PostgreSQL ou bien doit-t-on mettre quelque chose de spécifique en place ?
Ce n'est pas géré automatiquement, d'où le "You must have a mechanism...".
5. Comment mettre en place le failover lorsqu’on a plusieurs slaves ? (on sait à peu près comment faire avec 1 slave, mais pas avec plusieurs slaves).
La même chose qu'avec un esclave. Vous abattez l'ancien maître, vous configurez puis redémarrez l'esclave sélectionné en maître, puis vous reconfigurez ou reconstruisez les autres esclaves.
6. Dans la documentation il est dit : « In standby mode, the server continuously applies WAL received from the master server. The standby server can read WAL from a WAL archive (see restore_command) or directly from the master over a TCP connection (streaming replication). » Je sais que pour le mode Streaming Replication la réplication sur le Slave est plus ou moins « immédiate ». Dans le cas où on n’utilise pas le Streaming Replication, quel paramètre du Slave indique la périodicité pour intégrer les WALs du Master dans le Slave ?
Il n'y en a pas. Quand un WAL est prêt à être archivé, il l'est. Quand il arrive sur l'esclave et que ce dernier s'en rend compte, il l'intègre.
7. Vocabulaire : Quelle est la différence entre un WAL, un « journal de transaction » et un « fichier de log » ?
À priori, aucun. Si on cherche à être tatillon, WAL est l'acronyme de Write Ahead Log. Donc la techno WAL est la techno de journalisation des écritures. Mais généralement, on appelle un journal de transactions un WAL par simplicité. Un fichier de log des changements de la base est un journal de transactions (et donc un WAL). À ne pas confondre avec un journal de log/de traces 
Bref, dites un journal de transactions ou un WAL, tout le monde comprendra. Parler de fichier de log, et là, une certaine confusion peut naître.
Guillaume.
Hors ligne
Bonjour Guillaume,
Merci pour vos réponses.
Tout dépend de ce que vous appelez WAL. Si vous parlez d'un segment de journal de transactions, alors non.
8. Un segment de journal de transaction fait 16 Mo, donc je me doute bien que le Master ne va envoyer un tel fichier à travers le réseau, cependant je me demande dans les cas du Synchronous Streaming Replication, quelle opération "technique" est réalisée lorsqu'on fait ceci sur le Master :
START TRANSACTION;
INSERT ...;
COMMIT;----
Les esclaves sont créés à partir du maître. Les esclaves savent donc qu'ils sont esclaves.
9. Comment une machine sait qu'elle est Master ? Quel paramètre détermine cela ?
----
10.
A vous lire j'ai l'impression que (vrai/faux) :
a. la machine Master "A" de mon exemple (qui sera HS à un instant T) est destinée à être Master du cluster début à la fin si un humain ou programme ne résout pas le problème parce que les Slaves PostgreSQL (cf : les machines B, C et D de mon exemple) ne savent pas détecter le problème de "A" et agir en conséquence,
b. et que si "A" tombe HS les slaves (cf : les machines B, C et D de mon exemple) resteront slaves à vie,
c. et enfin qu'il faut forcément agir "manuellement" pour que le cluster PostgreSQL soit de nouveau opérationnel,
d. et que pour conclure même si la documentation parle de failover le cluster PostgreSQL lui ne gère aucun failover par lui-même,
... je me trompe ?
Si je me trompe, pourriez-vous me dire à quel niveau je dois agir pour automatiser au maximum le cluster ? Pour prouver que notre cluster PostgreSQL fonctionne, mon groupe devra éteindre le Master (cf : A), et nous aurions espéré que B, C ou D devienne automatiquement Master à son tour ! PostgreSQL ne gère pas cela automatiquement ? (d'où le terme de "négociation" dans le 1er message).
Merci encore, cordialement,
Dernière modification par guk92 (26/04/2015 20:09:51)
Hors ligne
8. Oh si, le maître l'envoie à chaque esclave si l'archivage est bien configuré. Rien ne se passe directement au commit de la transaction au niveau du Streaming (synchrone ou pas). Le processus wal sender (sur le maître donc) envoie les enregistrements des journaux de transactions toutes les X millisecondes vers son esclave, c'est ainsi que l'information passe d'un noeud à un autre.
9. Pas de paramètre. Elle sait qu'elle n'est pas esclave, elle est donc maître.
10.
a. Oui.
b. Oui, tant qu'une action (manuelle) n'est pas réalisée.
c. Oui.
d. Tout dépend de ce que vous entendez par failover. Pour moi, un failover, c'est promouvoir l'esclave en maître. Et dans ce cas, PostgreSQL le permet. Si pour vous, c'est que les esclaves détectent automatiquement que le maître est tombé et qu'ils choisissent entre eux automatiquement qui est le plus à jour et propre à être maître, et que ce dernier passe maître et que tous les autres viennent s'y connecter, alors non
Non, PostgreSQL ne gère pas "ça" automatiquement. C'est à vous d'installer un outil (voir ceux déjà cités) et à les configurer pour que cela se fasse.
Guillaume.
Hors ligne