Vous n'êtes pas identifié(e).
Bonjour,
j'ai 2 serveurs pgsql 9.6. L'un est maître et le second est mis en réplication. Les 2 serveurs fonctionnent très bien mais je me trouve confronter à un problème de taille, dans tous les sens du terme.
Mon serveur principal utilise 90% des 500 Go quand mon serveur de réplication n'utilise que 38% des 100 Go
Les 2 serveurs sont bien synchronisés et les mêmes données présentes.
J'ai tenté du VACUUM FULL sur toutes mes bases mais je ne gagne pas de place.
Quelle est la solution pour faire redescendre le volume du serveur maitre au niveau (à peu près) du serveur répliqué ?
Merci de votre aide
Hors ligne
Bonjour,
Quand vous dites 90% des 500GB : on parle de quoi ? la taille des fichiers de données ? la taille des bases visible dans psql ?
Que contient votre PGDATA ? les fichiers de données + les journaux de transactions + les fichiers temporaires ? En gros avez-vous répartis ces différents fichiers et repertoires dans plusieurs FS ou tout va t'il au même endroit ?
Si tout est en même endroit, c'est sans doute normal que la taille varie entre le leader et le replica :
- les WAL sont générés sur le serveur leader, pas le replica
- les fichiers temporaires sont générés sur le leader uniquement (sauf si vous utilisez aussi le replica en lecture seule pour requêter)
L'idée serait de comparer la taille des différents fichiers du leader et du replica.
Mais tout ce que je viens de dire peut être balancé à la poubelle si les 90% des 500GB sont la taille des bdd vu par psql...
Cordialement,
Sébastien.
Hors ligne
Bonjour,
le maître est sur un serveur linux avec 500 Go de disque dur (machine qui ne sert qu'au serveur postgres) et actuellement 90% du disque dur (donc des 500 Go alloués) sont occupés, contrairement à l'esclave donc je pense que les propositions sont pertinentes.
La réplication a été faite directement via les fichiers de configuration de pgsql, je suppose donc que tous les fichiers et journaux sont bien sur le maître.
Mon idée était bien d'eesayer de supprimer ces fichiers temporaires et les journaux mais je ne sais pas trop où chercher
Hors ligne
Bonjour,
les fichiers temporaires sont générés par des requêtes SQL (typiquement opérations de tri qui ne tiennent pas dans la RAM).
on ne peut pas les supprimer.
Pour les journaux il ne faut surtout pas y toucher. PostgreSQL gère tout seul.
Le volume et la quantité de WAL dépend de l'intensité de l'activité SQL dans l'instance.
Si c'est intense, le nombre de wal sera important, mais ils seront recyclés au fil de l'eau.
Si ça prend trop de place, il faut augmenter l'espace disque dédié.
Qu'avez vous mis dans "archive_command" ?
Les wal archivés sont-ils stockés ailleurs, sur un autre disque/FS ?
Cordialement,
Sébastien.
Hors ligne
j'ai trouvé les fichiers archive qui sont dans le répertoire par défaut (var/lib/postgresql/9.6/main/archive)
Il y a quasiment 25 000 fichiers de 16 Mo donc effectivement, ça prend de la place.
Je peux tout supprimer ou c'est préférable de garder un minimum ?
Hors ligne
si vous supprimez ces archives, vous ne pourrez plus faire de restoration PITR.
Donc soit vous prenez ce risque et vous supprimez les archives (mauvaise idée en production)
soit vous déplacez ces fichiers dans un repertoire distant.
Et il vous faudrait une politique de sauvegarde avec durée de rétention des backups et des archives (c'est la base d'un système de sauvegarde de production).
Cordialement,
Sébastien.
Hors ligne
J'ai le serveur de réplication en cas de défaillance physique du serveur maître et un dump quotidien de l'ensemble des bases présentes sur le serveur (avec les 7 derniers dumps qui sont conservés).
Y a-t-il du coup un intérêt à garder autant d'archives ?
Hors ligne
dans ce cas vous pouvez mettre archive_command='/bin/true'
Comme ça : pas d'archivage du tout.
Mais bon si j'étais vous je ne ferais pas comme ça.
Tout dépend de vos RPO RTO.
Cordialement,
Sébastien.
Hors ligne
de plus j'ajouterai que le fait d'avoir un replica vous protège d'un crash du serveur leader mais ne vous protège pas d'une perte de données (delete malheureux, ou truncate par erreur) : en effet ces erreurs seraient répercutées via la replication sur le replica.
Si vous vouliez revenir en arrière, dans votre cas il faudrait importer le dump et donc perdre x heures de données.
Je vous conseile également d'avoir un deuxième replica pour la résiliance (en cas de perte de votre leader, vous n'auriez qu'un seul noeud, ce qui peut entrainer quelques sueurs froides...)
Cordialement,
Sébastien.
Hors ligne
Merci beaucoup pour ces informations.
Aujourd'hui, notre base de données de production principale est sous un autre SGBD (Pervasive) et la base PGSQL est une extraction consultable pour les clients dans un espace client en ligne. La perte des données est dommageable pour la consultation mais peut se régénérer.
En revanche, il est prévu de migrer notre base de production également sous PGSQL et là, je souhaiterai mettre en mettre une gestion par pool avec 2 bases en local (sur des machines différentes, à des emplacements physiques différents) et 1 base cloud. Mais je sèche à trouver comment le mettre en place.
Et, pour se prémunir d'un delete ou truncate accidentel, l'idéal aurait été d'avoir une autre réplication différée de 10 / 20 / 30 minutes par exemple. Mais je ne sais pas si cette solution est possible.
Hors ligne
oui il est tout à fait possible d'avoir un replica avec du retard paramétré :
avec le paramètre recovery_min_apply_delay
(dans patroni.yml)
Cordialement,
Sébastien.
Hors ligne
