Vous n'êtes pas identifié(e).
Bonjour,
Suite (sans doute mais ce n'est pas certain) à l'application de postgresql 9.6.11 sur 2 serveurs en streaming replication maitre - esclave.
Le Maître a saturé sa partition data.
Aujourd'hui postgres est HS dessus et impossible de le redémarrer. Il a fallu que je libère de l'espace disque sur la partition data.
Puis-je resynchrniser l'exclave qui lui tourne toujours mais est en mode lecture seule?
Rsync des bases plus wal suffira - t -il ou sinon quelle est la méthode.
D'avance merci de votre aide
Hors ligne
Pourquoi ne pas passer tout simplement l'esclave en maître ?
Si vous voulez que l'ancien maître reste maître, il va falloir faire un rsync des fichiers de l'esclave, redémarrer le maître (qui se prendra pour un esclave du coup), et le basculer en maître.
Guillaume.
Hors ligne
Bonjour,
Merci pour cette réponse car le maitre est 16 x plus puissant (ram et proc) que le vieux serveur de sauvegarde qui a été recyclé en secondaire.
Et surtout que le maitre est situé sur le site majeur avec 60 qgis qui lui écrivent dessus alors que l'autre serveur est dans un site ou la charge est faible (et en rapport avec la machine).
Mais là je reconnais qu'il fait très bien le boulot, il m'évite de tout restaurer !
Je teste ca et fait un retour!
Hors ligne
visiblement mon architecture ne rend pas l'esclave maitre. c'est juste un hot standby
Hors ligne
Un hot standby peut devenir maîitre, c'est même son but à terme. Il faut basculer son rôle pour cela.
Guillaume.
Hors ligne
Bonjour,
J'ai pu relancer maitre à partir de celui en standby par duplication de fichiers.
Toutefois une partie du problème demeure, en effet une base présente un volume anormale ( 1888 Go ) pour un volume de données estimée de 400 Go avant problème.
j'ai fait une requete pour estimer le volume global des données + index comme suit qui confirme la présence de seulement 410 Go
with decoup as
(
SELECT
pg_total_relation_size('"'||table_schema || '"."' || table_name ||'"' ) as Taille_totale
FROM information_schema.tables WHERE table_type::text = 'BASE TABLE'::text
)
select sum(taille_totale)/1024/1024/1024 from decoupqui confirme que le ratio/données poids des fichiers de la base est anormal.
J'ai tenté de faire un vaccum full sur 100 tables mais le volume ne change pas . Par ailleurs tous les objets de la base (schéma, table ) ont une taille "normal".
Y-a-t-il un moyen pour identifier ces fichiers en trop et de les enlever?
un du -h /var/lib/postgresql/9.6/main/base/ numéro de base me donne bien :
1,9To ...
Dernière modification par tholot (18/12/2018 08:51:21)
Hors ligne
Faire un VACUUM FULL n'aurait rien changé à la différence de taille constatée. Il serait intéressant de savoir la taille prise par tous les objets de la base. Cette requête me semble plus intéressante pour le savoir :
SELECT pg_size_pretty(sum(pg_table_size(oid))) FROM pg_class;Normalement, PostgreSQL ne perd pas la notion des fichiers existants. Le seul cas à ma connaissance est lors d'un crash de PostgreSQL ou s'il est "kill-é" maladroitement. Trouver les fichiers "oubliés" est risqué. Si vous vous trompez sur un fichier, vous êtes bon pour repartir d'une sauvegarde. À mon sens, le mieux serait de sauvegarder la base actuelle avec pg_dump, de la restaurer sur une autre base (sur la même instance), et une fois que vous vous êtes assurés que cette nouvelle base est bonne, supprimez l'ancienne. Ça supprimera automatiquement les fichiers "en trop".
Guillaume.
Hors ligne
Bonjour,
Merci pour cette proposition, c'était effectivement mon étape suivante chercher de la donnée en dehors des tables et schéma.
Au niveau du crash il s'agit d'un ubuntu 16 sur lequel postrgres a été mis à jour de la version 9.6.10 vers la 9.6.11.
Le crash a consisté par la production de fichiers par postgres de manière continue jusque saturation de la partition data (1To initialement contre 4To occupé in fine)
La mise à jour a eu lieu le mardi soir et le crash le vendredi suivant.
Est-il imaginable que cette montée en version est obligé postgres a réécrire ses données et conserver les WAL pour le faire en paralléle afin de pouvoir les fournir à l'esclave l'obligeant à disposer d'un volume quadruple à taille des bases actuelles?
l'esclave est un hot standby avec slot replication mais se trouve sur un site distant liée par une liaison ethernet.
je check la requete fourni d'abord et programme un backup de base en sus car j'imagine que cela va être la solution finalement.
Hors ligne
Non, totalement inimaginable (en dehors d'un bug sur lequel personne ne serait tombé).
Guillaume.
Hors ligne
je viens de faire la requête postgres indique 417 Gb lui aussi.
pg_admin et phppg_admin voit le 1888 Go
le du -h de la base donne 1,9 To également
Hors ligne
pgAdmin récupère la taille de la base avec un pg_database_size, et cette fonction ne fait que parcourir les objets physiques (ie, les fichiers). Elle ne récupère pas la liste des objets logiques (tables, index, etc) pour en faire la somme. Du coup, vous placez un fichier qui n'a rien à avoir avec la base dans le répertoire de la base, il sera pris en compte par le pg_database_size mais pas par la requête que je vous ai donné plus haut.
Donc tout ceci laisse à penser que vous avez en effet des fichiers qui ne concernent pas vos objets logiques dans le répertoire de cette base.
Je maintiens que la solution la plus sûre (mais à coup sûr la plus lente) est un pg_dump/pg_restore. L'autre solution revient à récupérer tous les relfilenode dans pg_class et de supprimer tous les fichiers qui ne font pas partie de ces relfilnode. Rapide, mais dangereux si vous supprimez un fichier de trop.
Guillaume.
Hors ligne
Bonjour,
Merci pour l'explication , c'est exactement ce que je me disais en parcourant la table pg_class qui montre seulement 10 000 entrées pour 16300 fichiers ....
ok pour la solution la plus sur.
Concrétement je liste dans un fichier liste tous les fichiers du répertoire je le charge en base et fait une jointure avec relfinode avec un not in je ne risque pas d'en prendre un de trop en théorie.
par contre pour aller jusqu'au bout de la logique mon esclave en streaming replication auras toujours 1,2 To de trop puisque cette modification physique n'entrainera en rien des wal et donc une répercussion sur le serveur distant.
C'est ce qui me ferait militer pour une restauration complète.
Hors ligne
Pour infos, "10000 entrées pour 16300 fichiers" n'est pas une information suffisante pour savoir si des fichiers ont été oubliés. Une table, c'est généralement plusieurs fichiers, déjà parce que les données sont réparties sur plusieurs fichiers d'1 Go maximum, mais aussi parce qu'il y a au moins deux fichiers de métadonnées.
Guillaume.
Hors ligne