Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#26 Re : Général » failover » 18/12/2018 09:04:12
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.
#27 Re : Général » failover » 17/12/2018 17:52:10
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 ...
#28 Re : Général » failover » 10/12/2018 18:54:49
visiblement mon architecture ne rend pas l'esclave maitre. c'est juste un hot standby
#29 Re : Général » failover » 10/12/2018 18:53:46
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!
#30 Général » failover » 10/12/2018 18:25:55
- tholot
- Réponses : 12
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