Vous n'êtes pas identifié(e).
Bonjour à tous...
j'ai deux serveurs en streaming :
1°) Arrété mon ancienMAitre
2°) effectué un switch entre mon AncienMaitre et mon NouveauMaitre => OK
3°) Effectué des mises à jours sur mon nouveauMaitre => OK
4°) 'Ralumé' AncienMaître afin qu'il devienne NouvelEsclave avec recovery.conf => OK
5°) Quand je starte mon nouvel esclave voici l'erreur qu'il me renvoie :
Jun 6 11:54:50 vpfdipsql1 postgres[31151]: [2-1] LOG: received fast shutdown request
Jun 6 11:54:50 vpfdipsql1 postgres[31161]: [2-1] LOG: shutting down
Jun 6 11:54:50 vpfdipsql1 postgres[31161]: [3-1] LOG: database system is shut down
Jun 6 11:54:52 vpfdipsql1 postgres[31337]: [1-1] LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [2-1] LOG: database system was shut down in recovery at 2012-06-06 11:54:50 CEST
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [3-1] LOG: entering standby mode
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [4-1] LOG: redo starts at A9/79001FC8
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [5-1] LOG: consistent recovery state reached at A9/7B000000
Jun 6 11:54:52 vpfdipsql1 postgres[31346]: [6-1] LOG: unexpected pageaddr A9/19000000 in log file 169, segment 123, offset 0
Jun 6 11:54:52 vpfdipsql1 postgres[31348]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 6 11:54:57 vpfdipsql1 postgres[31354]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Je suppose que le nouvel esclave attend un Wal de mon nouveau maitre (qui a eu des mises à jour)...
Voici les wal de mon NouveauMaitre :
-rw-------. 1 postgres postgres 16777216 Jun 1 10:17 00000001000000A900000078
-rw-------. 1 postgres postgres 16777216 Jun 1 11:17 00000001000000A900000079
-rw-------. 1 postgres postgres 16777216 Jun 1 11:29 00000001000000A90000007A
-rw-------. 1 postgres postgres 16777216 Jun 1 00:17 00000001000000A90000007B
-rw-------. 1 postgres postgres 16777216 Jun 1 01:17 00000001000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 02:17 00000001000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 03:17 00000001000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 04:17 00000001000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 05:17 00000001000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 1 06:17 00000001000000A900000081
-rw-------. 1 postgres postgres 16777216 Jun 1 07:17 00000001000000A900000082
-rw-------. 1 postgres postgres 16777216 Jun 1 08:17 00000001000000A900000083
-rw-------. 1 postgres postgres 16777216 Jun 1 09:17 00000001000000A900000084
-rw-------. 1 postgres postgres 16777216 Jun 1 12:16 00000002000000A90000007A
-rw-------. 1 postgres postgres 16777216 Jun 1 15:57 00000002000000A90000007B
-rw-------. 1 postgres postgres 16777216 Jun 1 16:10 00000002000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 16:13 00000002000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 16:15 00000002000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 16:37 00000002000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 17:15 00000002000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 6 11:55 00000002000000A900000081
-rw-------. 1 postgres postgres 56 Jun 1 12:16 00000002.history
Quel wal attend mon Nouvel esclave (A9/19000000 in log file 169 !!!!) ... et pourquoi ce plantage ?
Merci pour vos réponses...
Hors ligne
Bonjour,
comment avez-vous effectué le switch entre les 2 maîtres ?
Le message indique que la timeline à changé, et qu'il faut donc recréer l'esclave (pg_basebackup ou pg_start backup puis copie)
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour...
j'ai effectué le switch en :
- Arrêtant le serveurMaitre
- Création du fichier trigger_ha' pour que mon esclave devvienne le maître (ce qui a fait passer mon recovery.conf en recovery.done)
- J'ai ensuite effectué des m.a.j sur mon NouveauMaitre
- J'ai rallumé l'ancien ServeurMaitre pour qu'il deviene mon nouveau ServeurEsclave (evec le recovery.conf qui va bien !)
- Je pensais que les WAL de mon NouveauMaître seraient interceptées NouvauEsclave et que cela continuerait comme ça...
Questions :
1°) N'est-ce pas ce qu'il faut faire quand il y a une panne sur le serveur maitre, afin de passer sur l'esclave (comme le dit la doc d'ailleurs !)?
2°) Comment m'en sortir maintenant si je n'ai pas de dump ?
merci pour vos réponses...
Hors ligne
Autre chose : Quel WAL manque t'il dans pg_xlog ? Que veut dire A9/19000000 in log file 169 ?
Hors ligne
C'est la bonne façon de procéder, mais passer un esclave en maître change la timeline et cela nécessite donc de recréer le nouvel esclave.
Pour vous en sortir un dump ne servirait pas, il faut faire un pg_basebackup sur votre nouvel esclave.
Julien.
https://rjuju.github.io/
Hors ligne
Merci...
1°) mais alors, cela veut dire que s'il y a un switch entre serveurs (et qu'il y a eu des m.a.j sur le nouveau maître), on est obligé d'effectuer une restauration sur le nouvel esclave(à partir d'un backup du nouveau maître), avant de le remettre en route ...
Moi qui croyait que le simple fait de réallumer le nouvel esclave, reprenait les wal du nouveau maître et repartait comme en l'an 40 en tant qu'esclave... je me suis bien trompé !!!
Ai-je raison dans ma première affirmation 1°)
Hors ligne
Ce n'est pas le fait de faire des mises à jour sur le nouveau maître qui induit ce problème, mais la promotion d'un esclave en maître, cela fait partie des restrictions de la réplication postgres.
Normalement, cette promotion ne se fait qu'en cas d'incident sur le serveur maître ce qui nécessite alors logiquement la reconstruction d'un nouvel esclave.
Dans votre cas, je suppose que c'était pour valider des mises à jour et switcher rapidement d'un maître à l'autre en cas de réussite.
Julien.
https://rjuju.github.io/
Hors ligne
Je voulais tester un 'switchover'... car imaginons une panne d'une heure sur le ServeurMaître sans crash de disque... juste un problème par exemple de database arrétee (pour diverses raisons !) sur mon AncienMaitre...
Je switche l'AncienEsclave en NouveauMaitre => OK
J'effectue des m.a.j sur le NouveauMaitre => OK
Et je voulais au bout d'une heure, 'rallumer' le NouvelEsclave (AncienMaitre) afin que les modifications effectuées sur le NouveauMaitre puissent être envoyées via les WAL, sur le NouvelEsclave...
Vous semblez me dire que ce n'est pas possible et qu'il faut, à chaque fois et quelle que soit la panne, restaurer le NouvelEsclave avant de repartir... mais alors, cela implique que pendant la restauration du NouvelEsclave, il faut arrêter le NouveauMaitre, sous peine qu'il y ait des modifications dessus et qu'il faille recommencer la restauration... non ?
Vous voulez un cachet d'aspirine ?
Hors ligne
Non, le processus de création d'un esclave se fait très bien base lancée.
En cas de perte totale, vous avez l'exécutable pg_basebackup qui se connecte au serveur maître et recréé un esclave. Dans votre cas, je vous conseillerais un select pg_start_backup, puis un rsync pour ne copier que les fichier modifiés puis un pg_stop_backup et l'esclave se reconnectera sans soucis (si bien sur tous les wal générés entre temps sont disponibles).
Julien.
https://rjuju.github.io/
Hors ligne
cela implique que pendant la restauration du NouvelEsclave, il faut arrêter le NouveauMaitre, sous peine qu'il y ait des modifications dessus et qu'il faille recommencer la restauration... non ?
Non. Vous faites comme d'habitude pg_start_backup, scp (ou plus intelligemment rsync), pg_stop_backup.
Guillaume.
Hors ligne
Rebonjour à tous...
je reprends mon post pour vous dire que j'ai bien fait ce qu'il fallait et que ça ne fonctionne toujours pas :
J'ai effectué sur mon NouveauMaitre : pg_start_backup/rsync des xlog (vers l'esclave)/pg_stop_backup
premièrement le pg_stop backup ne s'arrête pas et me rend :
NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived
WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT: Check that your archive_command is executing properly. pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.
Mais, me suis-je dit, étant donné que les wal sont passés du coté de mon NouvelEsclave, je peux restarter mon nouvealEsclave afin qu'il fonctionne... et bé non, il semblerait qu'il lui manque des wal (mais lequels ?) !
Voici ce que me dit mon fichier log dans /var/log/ :
LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [2-1] LOG: database system was shut down in recovery at 2012-06-12 10:16:59 CEST
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [3-1] LOG: entering standby mode
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [4-1] LOG: redo starts at A9/79001FC8
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [5-1] LOG: consistent recovery state reached at A9/7B000000
Jun 12 10:17:40 vpfdipsql1 postgres[8116]: [6-1] LOG: unexpected pageaddr A9/6E000000 in log file 169, segment 123, offset 0
Jun 12 10:17:40 vpfdipsql1 postgres[8118]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 12 10:17:45 vpfdipsql1 postgres[8122]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 12 10:17:50 vpfdipsql1 postgres[8123]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 12 10:17:51 vpfdipsql1 postgres[8107]: [2-1] LOG: received fast shutdown request
Suis-je clair..
Merci pour vos réponses...
Hors ligne
Il faut faire le rsync sur tout le répertoire data et pas uniquement le répertoire pg_xlog, car il faut reconstruire entièrement l'esclave.
Ensuite il semble que vous ayez un problème sur l'archivage des wals. Vérifiez dans votre postgresql.conf du nouveau maitre le paramètre archive_command pour voir la commande effectuée et pourquoi elle ne fonctionne pas (pas d'autorisation sur le répertoire cible, plus de place ...)
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour vos explications... je comprends mieux maintenant .. moi qui croyait que seuls les WAL basculés d'un serveur à l'autre suffiraient à remettre le bazar en marche, je me suis bien trompé ... ok aussi pour le archive_command, son emplacement était géré par 'root' et donc je ne pouvais pas écrire dessus...
Maintenant j'ai une autre erreur sur mon NouveauMaitre... en effectuant un stop (Ok) et un start (non Ok)de l'instance, le start part en 'failure' et me répond ceci dans ma log...
Jun 13 13:50:48 vpfdipsql2 postgres[16626]: [2-1] LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 13 13:50:48 vpfdipsql2 postgres[16626]: [3-1] WARNING: could not create listen socket for "*"
Jun 13 13:50:48 vpfdipsql2 postgres[16626]: [4-1] FATAL: could not create any TCP/IP sockets
Pouvez-vous m'expliquer pourquoi ?
Merci encore ...
Hors ligne
A priori votre serveur est configuré pour écouter sur une adresse en ipV6 et votre kernel ne le supporte pas.
Vous pouvez vérifier dans le pg_hba.conf la présence d'une ligne contenant une adresse de la forme ::1/128 par exemple (localhost en ipv6) et les commenter. Vous pouvez aussi regarder dans le fichier /etc/hosts pour voir si localhost ne redirige pas vers une ipv6 (::1 en ipv6 et 127.0.0.1 en ipv4).
Julien.
https://rjuju.github.io/
Hors ligne
Merci encore pour vos réponses...
en fait, mon esclave n'était pas bien configuré...
J'en encore une petite erreur sur mon NouveaEsclave ... il starte correctement mais la log me rends un message du type :
Jun 13 16:28:20 vpfdipsql1 postgres[16616]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 13 16:28:25 vpfdipsql1 postgres[16617]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
et je n'ai pas réussi à comprendre sur les posts, si ce problème était grave...
Pouvez-vous encore m'aider en m'expliquant le truc ?
Hors ligne
Désolé, j'ai envoyé le message un peu vite...
Lors de l'ouverture de mon slave j'ai effectivement :
Jun 14 14:18:31 vpfdipsql1 postgres[23515]: [2-1] LOG: received fast shutdown request
Jun 14 14:18:31 vpfdipsql1 postgres[23525]: [2-1] LOG: shutting down
Jun 14 14:18:31 vpfdipsql1 postgres[23525]: [3-1] LOG: database system is shut down
Jun 14 14:31:47 vpfdipsql1 postgres[23628]: [1-1] LOG: could not create IPv6 socket: Address family not supported by protocol
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [2-1] LOG: database system was shut down in recovery at 2012-06-14 14:18:31 CEST
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [3-1] LOG: entering standby mode
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [4-1] LOG: redo starts at A9/79001FC8
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [5-1] LOG: consistent recovery state reached at A9/7B000000
Jun 14 14:31:47 vpfdipsql1 postgres[23637]: [6-1] LOG: unexpected pageaddr A9/6E000000 in log file 169, segment 123, offset 0
Jun 14 14:31:47 vpfdipsql1 postgres[23639]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
Jun 14 14:31:52 vpfdipsql1 postgres[23645]: [2-1] FATAL: timeline 2 of the primary does not match recovery target timeline 1
il semble dire qu'à partir du A9/7B000000 la restauration peut s'effectuer => OK
Mais qu'il y a un problème sur une page adresse A9/6E00000 => ok
Or voici le pg_xlog du serveur que je veux starter (qui d'ailleurs a été rsyncé avec le serveur maître=> pg_xlog identiques)
drwx------. 17 postgres postgres 4096 Jun 14 14:32 ..
drwx------. 3 postgres postgres 20480 Jun 14 14:30 .
-rw-------. 1 postgres postgres 16777216 Jun 14 14:30 00000002000000A90000008B
-rw-------. 1 postgres postgres 16777216 Jun 14 14:30 00000002000000A90000008C
drwx------. 2 postgres postgres 20480 Jun 14 14:30 archive_status
-rw-------. 1 postgres postgres 16777216 Jun 14 14:01 00000002000000A90000008A
-rw-------. 1 postgres postgres 293 Jun 14 14:01 00000002000000A90000008A.00000020.backup
-rw-------. 1 postgres postgres 16777216 Jun 14 13:56 00000002000000A900000089
-rw-------. 1 postgres postgres 16777216 Jun 13 12:38 00000002000000A900000088
-rw-------. 1 postgres postgres 16777216 Jun 12 10:12 00000002000000A900000087
-rw-------. 1 postgres postgres 16777216 Jun 12 10:12 00000002000000A900000086
-rw-------. 1 postgres postgres 16777216 Jun 12 10:05 00000002000000A900000085
-rw-------. 1 postgres postgres 16777216 Jun 12 10:02 00000002000000A900000084
-rw-------. 1 postgres postgres 16777216 Jun 12 10:00 00000002000000A900000083
-rw-------. 1 postgres postgres 16777216 Jun 12 09:56 00000002000000A900000082
-rw-------. 1 postgres postgres 16777216 Jun 12 09:54 00000002000000A900000081
-rw-------. 1 postgres postgres 16777216 Jun 1 17:15 00000002000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 1 16:37 00000002000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 16:15 00000002000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 16:13 00000002000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 16:10 00000002000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 15:57 00000002000000A90000007B
-rw-------. 1 postgres postgres 16777216 Jun 1 12:16 00000002000000A90000007A
-rw-------. 1 postgres postgres 56 Jun 1 12:16 00000002.history
-rw-------. 1 postgres postgres 16777216 Jun 1 11:29 00000001000000A90000007A
-rw-------. 1 postgres postgres 16777216 Jun 1 11:17 00000001000000A900000079
-rw-------. 1 postgres postgres 16777216 Jun 1 10:17 00000001000000A900000078
-rw-------. 1 postgres postgres 16777216 Jun 1 09:17 00000001000000A900000084
-rw-------. 1 postgres postgres 16777216 Jun 1 08:17 00000001000000A900000083
-rw-------. 1 postgres postgres 16777216 Jun 1 07:17 00000001000000A900000082
-rw-------. 1 postgres postgres 16777216 Jun 1 06:17 00000001000000A900000081
-rw-------. 1 postgres postgres 16777216 Jun 1 05:17 00000001000000A900000080
-rw-------. 1 postgres postgres 16777216 Jun 1 04:17 00000001000000A90000007F
-rw-------. 1 postgres postgres 16777216 Jun 1 03:17 00000001000000A90000007E
-rw-------. 1 postgres postgres 16777216 Jun 1 02:17 00000001000000A90000007D
-rw-------. 1 postgres postgres 16777216 Jun 1 01:17 00000001000000A90000007C
-rw-------. 1 postgres postgres 16777216 Jun 1 00:17 00000001000000A90000007B
Soit des log 000000001nnnn et des logs 0000002nnn .
1°) Question : Ou se trouve ma A9/6E000000 que je ne vois pas dans mon pg_xlog ...
2°) les timelines définissent-elles les 0000001nn (pour timeline 1) et 000002nn (pour les timeline2
3°) Comment m'en sortir ?
Merci pour vos réponses...
Hors ligne
Bonjour à tous...
Pour plus d'infos, j'ai reconstitué l'esclave avec un rsync des répertoires 'pg_xlog' et 'base' du nouveau maître vers le nouvel esclave... Mais le problème est que, quand je suis sur mon nouvel esclave, le pg_start_backup ne fonctionne pas car il me dit que mon nouvel esclave est en cours de démarrage (voir la log du message précédent avec le timeline !)... et donc je ne peux pas faire, comme sur le post : 'Mise en place de la réplication avec PostgreSQL 9.0 - 2/2' => pg_start_backup, cp (ici je fais un rsync) et pg_stop_backup... est-ce la raison de mon problème ?
Merci encore pour vos réponses...
Hors ligne
J'ai trouvé !
En fait, vous me l'aviez déjà dit : il faut que TOUS les repertoires du serveur maitre soient rsynqués vers le serveur esclave... ça fonctionne !
Le problème est que je ne travaille pas à temps complet sur ce projet...
Merci encore pour vos réponses..
Hors ligne
