Vous n'êtes pas identifié(e).
Bonjour,
J'ai une réplication avec 1 maitre et 2 standby et l'autre jour en voulant ajouter une BDD j'ai eu une erreur de place sur le disque.
Suite à ça, j'ai diminué mon wal_keep_segment de 1000 à 100 (c'était un test justement sur ce paramètre) et j'ai supprimé des fichiers dans pg_xlog pour permettre à postgres de redémarrer et de supprimer cette BDD en trop.(Je ne pouvais pas agrandir l'espace disque.)
Ma 1ère BDD est bien complète (elle n'avait pas bouger entre temps), et postgres à redémarrer.
Par contre ,j'ai dû arrêté mes Standbys en créant le fichier définit dans trigger_file .
ça a fonctionné, le fichier recovery.conf s'est instantanément renommé recovery.done.
Par contre, je vois que le maitre est toujours en erreur sur un fichier :
2011-11-06 14:46:53.450 CET - - - - DÉTAIL: La commande d'archivage qui a échoué était : rsync -a pg_xlog/000000010000002A00000089 xxx.xxx.xx.xx:/data/archives_xlog/000000010000002A00000089 && rsync -az pg_xlog/000000010000002A00000089 xxx.xxx.xx.xx:/data/archives_xlog/000000010000002A00000089
2011-11-06 14:46:53.450 CET - - - - ATTENTION: le journal des transactions « 000000010000002A00000089 » n'a pas pu être archivé : trop d'échecs
rsync: link_stat "/data/pg_xlog/000000010000002A00000089" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1039) [sender=3.0.6]
Est ce qu'il n'a pas compris que les Standbys n'existaient plus, ou est ce qu'il veut son fichier "000000010000002A00000089 " ?
Comment faire pour qu'il arrête de faire cette erreur ?
Quand je fais "ps" je vois qu'il est en erreur sur ce fichier :
[root@IFMSRVEURICABDD data]# ps -edf | grep postgres
postgres 19407 1 9 16:17 ? 00:00:00 /usr/pgsql-9.1/bin/postmaster -p 5432 -D /data
postgres 19412 19407 0 16:17 ? 00:00:00 postgres: logger process
postgres 19414 19407 0 16:17 ? 00:00:00 postgres: writer process
postgres 19415 19407 0 16:17 ? 00:00:00 postgres: wal writer process
postgres 19416 19407 0 16:17 ? 00:00:00 postgres: archiver process failed on 000000010000002A00000089
postgres 19417 19407 0 16:17 ? 00:00:00 postgres: stats collector process
root 19428 18012 0 16:17 pts/0 00:00:00 grep postgres
Dernière modification par lolotte35 (08/11/2011 10:32:00)
Hors ligne
Le fichier 000000010000002A00000089 existe encore sur le système de fichiers ?
Marc.
Hors ligne
non.... ce n'est pas bon tout ça?
Hors ligne
PostgreSQL suppose qu'il a toujours le fichier 000000010000002A00000089 a archivé. Pour éviter les messages, il faut désactiver l'archivage.
Guillaume.
Hors ligne
ok et s'il n'y avait pas eu d'erreur de place sur le disque, il aurait bien compris qu'il n'avait plus de standby ?
Hors ligne
ah ça marche! trop bien, merci!
c'est surtout pour les cas où ça arriverai en production!
Hors ligne
La suppression des journaux de transaction n'est pas liée à la présence ou non d'une base de standby. Le fichier n'aurait pas du disparaître, c'est plutôt bizarre.
Marc.
Hors ligne
Merci Marc,
Heureusement il y a une explication : j'ai précisé au début que suite à la remonter d'une sauvegarde dans une 2ème base de donnée (pour un test de réplication avec wal_keep_segment à 1000 ), l'espace disque s'est saturé sur le serveur maitre.
Je ne pouvais pas agrandir l'espace disque car c'est un disque physique.
Je n'ai pas eu d'autre choix que de supprimer des fichiers dans le répertoire pg_xlog sinon impossible de redémarrer postgres qui manquait de place!
J'ai donc ensuite vu que 1000 c'était trop pour ce paramètre....
Hors ligne
Ok, tant qu'il y a une explication logique, ça me va 
Sinon, il y a un 'truc' auquel on pense rarement quand on est sous Linux: les systèmes de fichiers EXT(2,3,4) ont de l'espace réservé (5%) par défaut. Quand on est dans le genre de situation où on est plein, il y a moyen de baisser cette réserve (à 2% par exemple), ce qui permet de récupérer l'espace dont on a besoin pour redémarrer.
Marc.
Hors ligne
Merc je note!
J'espère qu'ne production cela n'arrivera jamais
Donc si je résume :
Le maitre écrit ses fichies WAL dans son répertoire pg_xlog
Les copies en même temps par le biais de la commande "archive_command" donc moi des rsync
Et n'en garde dans son répertoire que le nombre que l'on a mis dans "wal_keep_segment"
Ensuite quand il veut en archiver un, il créé un fichier vide portant le même nom dans "pg_xlog/archive_status/" en mettant comme extension ".ready".
Et quand le serveur en standby vient lui dire "c'est ok pour le fichier nommé "xxxxx" alors il le renomme en xxxxx.done (au lieu de ready).
Et le Standby fait la même démarche de "archive_status" et renommage ?
Il sait qu'il doit attendre 2 confirmations dans il a deux Standby?
Que ce passe-t-il si le standby est en retard et ne vient dire que très longtemps plus tard que c'est ok pour lui ?
Hors ligne
Non, le passage de .ready en .done se fait simplement quand le maître a réussi à faire son archivage (exécuté correctement la archive_command)
Les bases de standby ne remontent rien au maître, en règle générale (il y a une petite exception paramétrable en 9.1, mais dans les grandes lignes c'est vrai, le maître ignore complètement la présence d'esclave et leur état)
Marc.
Hors ligne
ça m'arrange!
ah ok, donc si le maitre réussi l'achive command il fait le passage de .ready en .done .
Et le Standby lui ,il va bien dire des mots doux au maitre non? car l'autre jour le maitre écrivait dans ses logs qu'un des standby lui parlait d'un fichier WAL qui avait été supprimé....
Hors ligne
Le standby va demander au maître des bouts de fichiers wal, quand on est en streaming replication. mais le maître est totalement passif dans l'histoire. Oui, normalement c'est l'esclave qui est passif, mais bon
Marc.
Hors ligne
Le maitre est passif, mais fait quand même l'archive command donc la copie du fichier WAL vers le Standby?
En fait le standby vient lui demander des WAL quand il n'en a plus dans son répertoire d'attente (pour moi archive_xlog)?
Je pense que le Standby ne faisait que traiter les fichiers WAL de archive_xlog vers son pg_xlog...
Hors ligne
L'archive_command recopie l'archive vers où vous voulez. Je veux simplement dire que dans l'interaction maître-esclave, tout est à l'initiative de l'esclave. L'archivage n'est pas directement lié à la notion de standby, et est donc à l'initiative du maître.
Oui, le standby ne fait que recopier les données du répertoire d'archivage vers son propre répertoire pg_xlog.
Marc.
Hors ligne
d'accord donc si le Standby met 3h à intégrer ses fichiers WAL, tant qu'il reçoit toujours les nouveaux fichiers WAL envoyer par le archive_command du maitre, cela ne pose aucun soucis d'intégrité de base du Standby.
La base sera ok quand il aura rattrapé son retard.
Quand est ce que l'esclave va parler avec le Maitre alors?
Que s'il s'ennuie car il n'a pas de fichiers WAL à traiter ? (il deviendrait alors sadomasochiste 
)
Hors ligne
Quand il n'aura plus de fichier archives à traiter. Alors il se connecte en mode 'streaming' pour demander la réception des bouts de journaux générés à intervalle régulier (le wal_sender_delay).
Et il reste dans ce mode tant que le maître ne dit pas à l'esclave qu'il est trop en retard et que le wal demandé n'est plus disponible. Dans quel cas on repasse en mode 'restaurations des fichiers de l'archive'.
Le wal_keep_segments sert justement à éviter de repasser trop rapidement dans le mode de restauration des archives: le maître garde davantage de journaux qu'il n'est nécessaire à son propre usage, au cas où l'esclave en aurait besoin. Et 1000, c'est vraiment beaucoup
Marc.
Hors ligne
Oui il faut que je trouve la bonne valeur du wal_keep_segment, 1000 c'était vraiment trop!
Du coup, si le standby prend 3h à traiter ses fichiers WAL et qu'il vient demander au maitre les nouveautés et que le wal demandé n'est plus disponible, alors mon Standby est "mort". il faut le reconstruire?
Si c'est le cas, j'ai intérêt à trouver un wal_keep_segment parfait, vu le retard que prend mon standby dès qu'il y a une opération de maintenance!
Cela vous semble normal que le reindex sur le maitre a pris autant de temps à se répercuter sur serveur en Standby (qui n'est pas sur le même site) soit 3h, que la remontée d'une sauvegarde (qui prend aussi 3h pour finir sur le standby)?
C'est l'opération de maintenance la plus gourmande?
Hors ligne
Le standby n'est pas mort. Il faut qu'il puisse accéder à l'endroit où vous stockez vos archives. Si effectivement vous ne stockez pas vos archives, à ce moment là, il est mort (on ne peut pas sauter un journal).
C'est difficile de vous dire ce qui prendra le plus de temps à appliquer. Ça peut dépendre de votre débit réseau, des disques et du processeur du serveur de standby comparativement au maître.
Marc.
Hors ligne
ok merci pour tous ces renseignements!
Hier soir, j'ai voulu lancé le rsync du standby qui n'est pas sur le même site (après le start) et j'ai pu voir que sans l'option "-z" de compression mon réseau n'est pas content, contre 3h de transfert en compression , là en 12h il n'avait pas fait grand chose, j'ai même dû le stopper pour ne pas pénaliser le réseau!
Cette nuit, je le remets avec l'option de compression
Et je testerai les temps pour tous les types de maintenance !
Hors ligne
Ok. Par contre le protocole de réplication de PostgreSQL n'est pas compressé. Si le lien réseau est si problématique, vous pouvez toujours essayer de le compresser à travers une redirection de port SSH par exemple (et l'option -C de ssh)
Marc.
Hors ligne
Vous parlez dans le "archive _command" ou dans le "rsync" pour la première syncro?
J'ai un standby qui n'a pas de problème de réseau car sur le même site et l'autre qui en effet peut en pâtir.
j'ai donc mis dans mon archive commande pour le standby de l'autre site :
rsync -az %p 192.168.10.xxx:/data/archives_xlog/%f
avec le z il compresse
et quand je fais le rsync pour la 1ère syncro :
rsync -avz -e ssh /data/ IP_serveur_esclave:/data/ --exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf --exclude save/ --exclude logs/ --exclude files/ --exclude pg_log/
Quand il n'y a que quelques fichiers de 16Mb ça va, mais comme notre base fait 20Giga, quand il doit tout rappatrier sur Paris, ça lui prend du temps. Je pourrai peut être lui faire prendre le tgv!
Dernière modification par lolotte35 (09/11/2011 18:42:29)
Hors ligne
rsync -z compresse effectivement les données, ça devrait revenir au même que mes histoires de ssh (c'est le même algo de compression…).
Pour ce qui est de 'lui faire prendre le tgv', ce n'est pas forcément idiot: un camion remplit de bandes de sauvegarde a un meilleur débit que bien des réseaux (je crois que c'est dans le Tanenbaum sur les réseaux qu'il le mentionne). Quelquefois, envoyer une bande par la poste ou par coursier est plus rapide.
Marc.
Hors ligne
ah oui on a une navette entre nos 2 sites! je pourrai essayer...
Merci et bon week end
Hors ligne
Je vais profiter de ce thread pour poser plusieurs questions lorsqu'on est dans le cas suivant: un master et 2 standby en hotstandby replication.
Dans la conf du master il y a une archive_command qui est capable de copier sur chacun des standbys les WALs.
Que se passe t'il si la commande arrive à copier le WAL sur seulement un des standbys ?
On peut imaginer que l'archive_command sorte avec un exit status != 0. Du coup le master tentera d'archiver à nouveau ce même WAL tant que l'archive_command ne sortira pas avec un exit status ==0 ?
J'imagine que le standby qui avait bien récupéré le WAL attendra le prochain et ne traitera donc plus jamais le WAL renvoyé ? (ouf je sais pas si j'ai été clair)
Hors ligne
