Forums PostgreSQL.fr

tholot

Membre

failover

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

gleu

Administrateur

Re : failover

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.

tholot

Membre

Re : failover

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!

tholot

Membre

Re : failover

visiblement mon architecture ne rend pas l'esclave maitre. c'est juste un hot standby

gleu

Administrateur

Re : failover

Un hot standby peut devenir maîitre, c'est même son but à terme. Il faut basculer son rôle pour cela.

---

Guillaume.

tholot

Membre

Re : failover

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 decoup

qui 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)

gleu

Administrateur

Re : failover

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.

tholot

Membre

Re : failover

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.

gleu

Administrateur

Re : failover

Non, totalement inimaginable (en dehors d'un bug sur lequel personne ne serait tombé).

---

Guillaume.

tholot

Membre

Re : failover

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

gleu

Administrateur

Re : failover

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.

tholot

Membre

Re : failover

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.

gleu

Administrateur

Re : failover

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.