Vous n'êtes pas identifié(e).
Bonjour Julien,
Merci pour toutes ces informations...
bon j'ai repris les fondamentaux en lançant juste la ligne de commande et :
Postgres m'a répondu^^
pg_dump: erreur : échec de la requête : ERROR: out of shared memory
ASTUCE : You might need to increase max_locks_per_transaction.
Bref deux soucis identifié :
une valeur de share_buffers trop basse et un nombre de verrous par transaction trop bas...par rapport à la taille de la base à sauvegarder
Bonjour à tous
J'ai un script shell de sauvegarde que j'utilise depuis 10 ans sur un cluster de 6 bases de données sur ubuntu
Je l'ai fait évoluer depuis postgres 9.1 jusque la migration du week-end dernier de postgres 12 à 14.
Toutes mes sauvegardes marchent sauf sur une base et je bloque à comprendre pourquoi...
les droits, comptes et option du pg_dump sont identiques et ce font avec 7 jobs parallélisés en directory (-Fd)
le script se lance crée le répertoire pour cette base puis plus rien à l'affichage on voit bien le processus select et 1 job de sauvegarde et puis ca s'arrête sans rien écrire.
Je précise que pour toutes les autres bases il n'y aucun soucis le processus de select s'initialise puis 7 connections pg_dump puis les 7 copy...
Bref je manque d'imagination... des idées inspirations?
Bonjour,
Oui bien sûr 8 go de ram ^^
effectivement il y a un slot de replication oui c'est une retauration en parraléle avec le nb de job correspondant au nombre de processeur -1.
Sauf erreur le pg_upgrade ne peut être utlisé que sur la même machine or je vis à faire évoluer toutes les caractéristiques du serveur (OS, version de Postgres etc et surtout je fais des tests de remontée de bases régulièrement avant les phases de migration afin de n'avoir que peu de mauvaise surprise le week-end choisi!)
Bonjour à tous,
Je dispose d'une infra bisite rélié par un lien intranet intersite avec une réplication physique bati sur postgresql 12 et postgis sur deux machines virtuelles.
afin de faire des tests de migration (en gros 1To de bases de données hébergées) j'ai rajouté 2 machines virtuelles avec OS et postgresql 14 et postgis 3 que j'ai tuné et préréglée pour la replication physique.
aujourd'hui je me pose la question suivante en terme de performance et de fiabilité de l'opération de migration vis à vis de la réplication par flux
le déroulé s'effectue comme suit :
sur l'infra ancienne j'attends la sauvegarde du vendredi soir sur l'infra en version 12 puis je lance la restauration à partir de ce répertoire de sauvegarde sur l'infra 14.
Question jusqu'alors je laissais ce conclure cette phase de restauration SANS réplication vers le serveur esclave (je l'éteins ou je ne place pas le fichier signal.....)
puis je profitais du week-end pour faire une copie physique des bases via un rsync et une fois aboutie relancer le serveur esclave.
je me pose la question suivante est-ce que je prends un risque à laisser la réplication active pendant la phase de restauration des bases qui va solliciter la même machine physique et virtuelle pour restaurer et envoyer les données au serveur secondaire.
Si vous aves des avis ou des retours à ce sujet. sinon je ferais un retour (pour info 16 processeurs et 8Mo de ram sur le serveur concerné et 1To de données à gérer environ 10h de restauration les dernières années)
D'avance merci !
Bonjour Daniel,
Merci pour cette explicitation vraiment très claire.
Je crois que je me suis laissé abusé par le message d'erreur de mes connexions avec mon super user.
En effet dans mon cas je restaure une sauvegarde déjà hashée en md5 alors que j'ai recrée le superuser localement sur la nouvelle machine en le hashan avec shram.
Donc la connexion locale passe sans soucis (psql -U monsuperuser), alors que l'exécution du fichier contenant les comptes m'a obligé à redescendre la connexion en md5 car je fais des connexions au bases vivantes et en pg 12 pour avoir des stats sur le nombre de tables à sauvegarder et les comparer avec la restauration sachant que j'utilise une méthode de connexion distinct (tcp/ip) pour me connecter ...
Merci pour votre aide
Bonjour Guillaume,
Merci pour ces éléments de réponses.
Je conclus donc que dans mon cas de figure :
soit je remets la valeur md5 dans password_encryption dans le postgresql.conf du postgresql 14.
Soit je ne transfert pas ma base de compte et je ressaisis ou fait ressaisir tous les mots de passe par les utilisateurs.
J'espère que ma synthése est juste?
Bonne journée
Bonjour à tous,
Je teste actuellement une montée en version de postgresql sur un serveur non en production.
Je me confronte au problème d'encryption des mots de passe.
Dans ma procédure de migration , je commence par réinjecter tous les comptes (en provenance d'un postgresql 12 donc encrypté en md5)
puis je restaure ensuite chacune des bases une a une.
Mon problème est simple y-a-t-il une méthode qui permet lors de la migration (je fabrique un fichier .dump pour stocker les comptes) que je relis afin de le réinjecter dans la version 14 qui permet de hasher les mots de passe avec la nouvelle méthode?
Dans mon cas je n'upgrade pas un serveur en place mais je renvoie la derniere sauvegarde fiable sur une nouvelle version (ce qui permet de partir sur une configuration logicielle et matérielle plus récente).
D'avance merci pour vos éclairages!
Bonne soirée!
Merci Guillaume pour ces conseils.
Effectivement sauter l'étape d'archivage n'a plus de sens puisque le réplicat est maintenant postérieur au flux de wal à traiter.
J'ai effectivement lancé archive_command='yes' en effectuant un reload du service postgresql
Bonjour à tous,
La semaine dernière suite a une mauvaise manipulation de droits, le stockage du flux de wal d'archivage continu dans un emplacement partagé entre le serveur maitre et le secondaire en standby a été interrompu.
Le problème n'a été qu'en partie diagnostiqué en milieu de semaine dernière et le décallage avec le serveur secondaire étant important décision a été prise de resynchronisé le serveur directement par rsync des fichiers de base de données.
La difficulté actuelle est que le serveur maitre continue le processus d'archivage en continu des wals en parallèle avec 7 jours de retard par rapport au wal rééllement nécessaire à l'actualisation du secondaire.
il s'avère que pour une raison non encore établie le processus checkpoint et le processus archiver alternent tous les deux des phases d'execution (R) et de sleep (D) visible au travers de la console htop.
Avez une idée de ce qui pourrait contraindre la performance globale de ces process?
Pas de message d'erreur de postgres sur les limites du checkpoint et le serveur a récemment été rebootée et semble ne pas faire grand chose en terme de charge.
Merci Guillaume pour toutes ces précisions!
Bonjour Merci Guillaume,
C'est beaucoup plus clair pour moi effectivement.
Juste un détail la réplication par streaming semble opére visiblement à la granularité au segment de wal, ce qui fait dans mon cas pratique au temps de transfert prés les deux serveurs sont quasiment synchrones.
A contrario mon troisiéme serveur lui utilise la restoration de l'archivage des wal du master, et là il semblerait que l'esclave attende qu'un wal intégral de16Mo soit archivé par le primaire avant de le récupérer puis de le jouer avec un pas de temps élastique en fonction des actions sur le primaire.
Ou cela traduit-il plutôt une erreur de fonctionnement de mon installation
Merci d'avance
Merci Guillaume
Bon ben voila tout est dit le rsync ne suffit pas il faut en plus formaliser cela avec pg_start_backup et pg_stop_backup. J'avais imaginé que ce n'était valable que pour les opérations avec création d'un fichier sauvegarde et pas avec une synchronisation de fichier racine...en relisant la doc...
Pour bien comprendre pg_start_backup et pg_stop_backup ce sont des opérations qui visent à lancer la création d'un checkpoint et de mettre en cohérence les opérations d'archivage des wals et de synchronisations des timelines, non?
Merci en tout cas :
Pour info les opérations que je fais :
je prépare un serveur maitre avec juste un archivage de wal par archive_command
je rends esclave un second serveur qui lui a déjà servi en autonome et pour ca je fais :
mise en place d'une restore_command
rsync des fichiers du répertoire main à partir du maitre arrêté
mise en place du fichier standby.signal
et redémarrage des deux serveurs.
Naïvement je pensais que le fait d'arrêter les deux serveurs faisait que le maître était dans un état stable et donc que le rsync produirait forcément un état stable en face.
De toutes façons à partir du moment ou j'arrêtais le maitre je ne pouvais plus utiliser le pg_start_backup et pg_stop_backup, donc en fait vous suggérer de le faire à faire à chaud côté maitre uniquement?
D'avance merci pour tous ces éclaircissements.
Bonjour Guillaume,
loin de moi l'idée de critiquer ce phénoménal travail de traduction et de maintien à jour qui est doit être très énergivore.
Par ailleurs merci beaucoup pour la traduction qui permet de mieux appréhender certaines substilités de postgres.
Merci Daniel, en lisant la documentation du gihub, je vois comment contribuer et signaler plus efficacement les erreurs.
J'ai quand même une question sur la réplication :
Tous les exemples que je vois sont basés, dans les documentations notamment, sur la mise en place d'une solution répliquée à partir de serveur neuf (au sens installé initialement dans ce but). Or dans ma vie, j'ai une machine virtuelle de développement sur laquelle je teste une version supérieure de moteur de postgresql avec postgis de manière autonome (sans replication donc ), j'y restore mon environnement et je l'expose à qqs clients promus déboggueurs en chef. Puis lorsque tout ou presque est ok, je retiens cette nouvelle version de moteur pour programmer une migration de tous mes serveurs réplication compris :
Dans mon cas de figure 2 sont l'un a côté de l'autre (et donc je propose de recycler de ce fait la machine qui m'a servi à faire le test de montée de version).
Comme je ne veux pas refaire toute la maquette et que malheureusement il est rare que je réussisse sans itération à obtenir une solution stable.
Je réutilise le postgres autonome pour en faire le nouvel esclave. Et donc je prends une machine vierge sur laquelle je deploie tous les outils, migres mes bases puis je synchronise avec rsync tout le répertoire main de postgresql.
Je mets le fichier recovery.signal et la restore_command en place puis je redémarre l'esclave puis le maitre qui lui utilise l'archive_command.
Fréquemment le serveur esclave se souvient de sa vie antérieure en m'indiquant via une erreur de timeline ou de recherche de fichier history. Comment puis je le rendre vierge de cette mémoire? Sauf erreur de ma part le seul répertoire qui n'est pas synchronisé est le log hormis bien sûr les répertoires protégés par postgres bien sûr.
D'avance votre éclairage à ce sujet
Yann
Bonjour,
Sur la francisation de la documentation postgresql nouveau soucis sauf erreur :
9.26.4. Fonctions de contrôle de la restauration la fonction de suivi des wal est décrite ainsi (comme en 9.x)
pg_last_xlog_receive_location()
Alors que dans la doc anglaise :
https://docs.postgresql.fr/12/functions-admin.html
9.26.4. Recovery Control Functions
c'est
pg_last_wal_receive_lsn()
qui est noté
et surtout dans le moteur 12 l'ancienne dénomination n'exite plus mais ce n'est pas la seule coquille:
Qui alerté dans ce cas, et par ailleurs comment peut-on participer à la francisation des docs s'il manque des bras?
D'avance merci !
Bonjour,
j'ai l'impression que cela provient du fait que je n'avais pas de replication effective entre mes deux serveurs du fait de la confusion entre standby.signal et recovery.signal et donc que les deux serveurs ont eu des phases ou ils étaient ou répliqués ou autonome. et comme j'ai restauré sur l'un et l'autre des bases de bon volume conséquents (1To) la croissance des wal a été volumineuse.
Je suis reparti de quasi 0 et les timelines semblent en accord maintenant.
je crois que j'ai trouvé un 000002.history qui mettait le bazard....alors que la timeline était en 000001
Merci c'est pas grave Guillaume, juste que postgres ne disait rien pour me mettre sur la voix...
Maintenant j'ai ce message là :
LOG: démarré le flux des journaux depuis le principal à 156/6C000000 sur la timeline 1
2020-10-23 12:48:01.517 CEST [30552] FATAL: la timeline requise 2 n'est pas un fils de l'historique de ce serveur
2020-10-23 12:48:01.517 CEST [30552] DÉTAIL: Le dernier checkpoint est à 156/6C000028 sur la timeline 1, mais dans l'historique de la timeline demandée, le serveur est sorti de cette timeline à 156/670000A0.
2020-10-23 12:48:01.519 CEST [30550] LOG: processus de lancement (PID 30552) a quitté avec le code de sortie 1
2020-10-23 12:48:01.519 CEST [30550] LOG: annulation du démarrage à cause d'un échec dans le processus de lancement
2020-10-23 12:48:01.524 CEST [30550] LOG: le système de base de données est arrêté
Je crois que j'ai trop bidouillé et l'esclave est perdu, je vais tenter un rsync de tous les fichier de la base et refaire un fichier standby.signal
re,
effectviment je n'ai pas créér ce fichier "La raison la plus probable de cette erreur est que vous avez oublié de créer le fichier standby.signal."
Car sur la doc française il est mentionné recovery.signal.... (ce qui ne lui fait ni chaud ni froid)
erreur de traduction ? ou traduction automatique?
26.2.4. Paramétrer un Serveur de Standby
Pour paramétrer le serveur de standby, restaurez la sauvegarde de base effectué sur le serveur primaire (voir (see Section 25.3.4). Créez un fichier recovery.signal dans le répertoire de données du cluster de standby. Positionnez restore_command à une simple commande qui recopie les fichiers de l'archive de WAL. Si vous comptez disposer de plusieurs serveurs de stanby pour mettre en œuvre de la haute disponibilité, assurez-vous que recovery_target_timeline est configuré à latest (la valeur par défaut), pour indiquer que le serveur de standby devra prendre en compte la ligne temporelle définie lors de la bascule à un autre serveur de standby.
Ou une feinte pour vérifier que l'on a bien lu.. ;-)
le slave se connecte bien au master mais la timeline 2 ne lui plait pas... faut que je creuse cela encore....
Alors en fait c'est plus sioux que cela :
2020-10-23 09:12:46.645 CEST [28985] LOG: le système de bases de données a été arrêté à 2020-10-23 09:06:41 CEST
2020-10-23 09:12:46.645 CEST [28985] FATAL: doir spécifier une restore_command quand standby_mode n'est pas activé
2020-10-23 09:12:46.648 CEST [28983] LOG: processus de lancement (PID 28985) a quitté avec le code de sortie 1
2020-10-23 09:12:46.648 CEST [28983] LOG: annulation du démarrage à cause d'un échec dans le processus de lancement
2020-10-23 09:12:46.662 CEST [28983] LOG: le système de base de données est arrêté
Il considère que standby mode n'est pas activé et exige donc une restore_command, pourquoi considère-t-il que primary_conn ou primary_slot n'active pas le mode standby?
De ce que j'ai lu on peut choisir la replication par streaming ou l'accès à un répertoire d'archive continu du master. Je me trompe?
D'ailleurs ce qui est vraiment surprenant c'est que cette option n'existe pas dans le postgresql.conf.
Même par en attente comme primary_conn'' ou restore_command'' dans la section standby server....
J'imagine que c'est parcequ'elle va disparaitre en version 13 ? la présence de primary_conn devrait permettre de déduire que l'on souhaite avoir un secondaire actif?
Hello, merci guillaume j'avais oublié le fichier recovery.signal mais il faut que je remonte la pelote....car il y a d'autres choses :
petit soucis dans la doc de la 12 : (il manque la mention de standy_mode=on (qui existe bien dans la doc de la 11 et plus dans la 12)..
Pour paramétrer le serveur de standby, restaurez la sauvegarde de base effectué sur le serveur primaire (voir (see Section 25.3.4). Créez un fichier recovery.signal dans le répertoire de données du cluster de standby.
Positionnez restore_command à une simple commande qui recopie les fichiers de l'archive de WAL. Si vous comptez disposer de plusieurs serveurs de stanby pour mettre en œuvre de la haute disponibilité, assurez-vous que recovery_target_timeline est configuré à latest (la valeur par défaut), pour indiquer que le serveur de standby devra prendre en compte la ligne temporelle définie lors de la bascule à un autre serveur de standby.
Je vais le signaler car j'ai l'impression que cette omission ne vient pas de la traduction mais de la doc anglaise de la 12.
Bonjour à tous,
j'ai deux serveurs sur le même réseau local que je souhaite mettre en replication physique :
sur le master
j'ai ouvert le pg_hba.conf
ave une ligne :
host replication * ip/32 md5
et j'ai monté wal_keep_segments à 1000
j'ai lancé la création du slot de replication avec :
la fonction adhoc
le resultat donne cela :
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-----------+-----------+--------
nom_slot | physical | f
sur le slave
primary_conninfo = 'host=IP_master port=port user=compte_non_su password='
primary_slot_name = 'nom_slot'
wal_keep_segments = 1000
j'ai fait une copie via rsync du master vers le slave.
Depuis j'ai rajouté deux nouvelles bases sur le master mais la réplication ne s'effectue pas :
les logs du master et du slave ne font état d'aucune connection même échouée...
aucun processus serveur wal_sender en route...
les serveurs sont par défaut hot= replica
Je passe a côté de qqchose, mais j'ai beau lire la doc je ne vois pas...
Si vous avez des idées...
Bonjour,
Merci beaucoup pour cette réponse je pensais bien que j'avais omis quelquechose
Bonjour,
Merci de votre réponse, effectivement j'avais lu les évolutions de ALTER MATERIALIZED VIEW, mais j'avais conclus comme vous que cela n'avait des effets que sur des éléments basiques et pas sur la définition ou le contenu d'une vue matérialisée.
Pour l'exemple en fait j'ai une vue matérialisée dénommée topo_region_s_r84 qui présente le polygone de la région auvergne-rhone-alpes et des attibuts qui sont constitués par la définition
suivante select nom_reg, st_union(geom_bdt) from n_commune_cog_2014_s_fr where insee_reg='84' group by 1.
je voudrais changer cette définition pour l'asseoir sur une table n_commune_s_fr qui elle évoulue au fil des ans et malheureusement j'ai des centaines de vues ou de tables qui s'appuient sur cette vue matérialisée.
J
Bonjour à tous,
J'ai un soucis récurrent sur mes installations de postgres-postgis. Je souhaite installer plusieurs clients à postgres qui me sont nécessaires pour faire tourner mes batchs d'entrée sortie dans la base.
en l'occurence j'installe en ubuntu, toutes ces dépendances par défaut :
sudo apt-get install postgresql-12-postgis-2.5
sudo apt-get install gdal-bin
sudo apt-get install pgadmin4
sudo apt-get install postgresql-12-pgrouting
sudo apt-get install postgresql-client-12
Or il me manque systématiquement les bibliothéques shp2pgsql et son verso pgsql2shp.
J'arrive à trouver une astuce pour contourner cela en ajoutant :
sudo apt-get install postgis
qui lui les installe systématiquement.
Ce faisant j'ai souvent une version supérieure de psql, voir de postgis qui s'installe en plus.
Comme cela m'arrive à chaque fois depuis la version 9.0 je me dis que je loupe une étape au niveau des installations initiales? Auriez vous une idée svp
