J'ai une base de données DEV et TEST pour un projet, c'est-à-dire des bases de données que j'utilise pour exécuter mon projet ou exécuter des tests localement. Ils sont tous les deux dans le même cluster ('exemple' - je viens de Redmond).
Notez que mon groupe local est différent du cluster qui héberge la base de données de production.
Comment dois-je configurer ces bases de données en ce qui concerne l'archivage des fichiers WAL?
J'aimerais pouvoir «construire» ou «reconstruire» l'une de ces bases de données en restaurant à partir d'une sauvegarde de base et d'exécuter des scripts de données de semences.
Mais comment dois-je configurer les bases de données ou le cluster pour archiver des fichiers WAL? Je comprends que j'en ai besoin si je veux récupérer la base de données. Je pense que c'est peu probable (comme je ne connaissais même pas «WAL» ou de leurs dossiers, ou que, vraisemblablement, ils sont partagés par toutes les bases de données du même cluster, qui semblent bizarreries et effrayantes provenant de Microsoft SQL Server.)
Dans le cas où je reconstruisions l'une des bases de données, je devrais supprimer les fichiers WAL depuis la sauvegarde de la base - Comment puis-je faire cela?
Mais je ne veux pas non plus avoir à vous soucier de la taille des fichiers WAL croissants indéfiniment. Je ne veux pas être obligé de reconstruire juste pour économiser de l'espace. Que puis-je faire pour éviter cela?
Mon cluster local seul contient une seule solution de développement et de test pour mon projet, c'est-à-dire que la perte de données de l'une de ces bases de données est (ou devrait être) Aucun gros problème. Même avoir à recréer le cluster lui-même et les deux bases de données, conviennent bien et non un problème si c'est même simplement plus facile que de restaurer les deux bases de données à une condition de «travail» pour le développement et les tests locaux.
En d'autres termes, je m'en fiche des données dans l'une ou l'autre base de données. Je m'assurerai - séparé de l'archivage WAL - que je puisse restaurer une base de données à un état suffisant pour mes besoins.
En outre, j'aimerais documenter (par exemple, dans le code) Comment configurer mon cluster local et mes deux bases de données afin que d'autres développeurs pour le même projet puissent utiliser la même configuration pour leurs clusters locaux . Ces clusters sont tous distincts du cluster qui héberge la base de données de production.
3 Réponses :
Plutôt que d'essayer de gérer vos fichiers WAL manuellement, il est généralement recommandé de laisser une application tierce en s'occuper de cela pour vous. Il existe plusieurs options, mais pg_backrest est le plus populaire des offres open-source là-bas.
pg_backrest est superbe. Je pense créer une sauvegarde de base des deux bases de données après les ensemencer avec des données de dev / de test fixes. J'utiliserais cette sauvegarde pour restaurer les bases de données à leurs états «initialisés» au besoin. Peut-être un moyen de minimiser l'espace disque utilisé par les fichiers d'archive WAL consiste à créer régulièrement une deuxième nouvelle sauvegarde de base, par exemple. une sauvegarde quotidienne de base (et écrasez-vous le précédent fichier de sauvegarde «second» précédent). De cette façon, je, et d'autres développeurs, pourraient restaurer cette sauvegarde de base et toutes les archives WALL, si désirées.
Chaque instance de base de données écrit son flux WAL, haché dans des segments de 16 Mo.
Chaque autre base de données relationnelle fait la même chose, même Microsoft SQL Server (les différences sont dans le nom et l'organisation de ces fichiers).
Le WAL contient les informations physiques requises pour rejouer les transactions. Imaginez-le comme des informations telles que: "Dans File X, Block 2734, modifiez 24 octets à la décalage 543 comme suit: ..."
Avec une sauvegarde de base et ces informations, vous pouvez restaurer un point donné à temps dans la durée de la base de données Chaque cluster PostgreSQL écrit son propre "courant wal". Les fichiers portent nommés avec de longs numéros hexadécimaux étranges qui ne se répètent jamais, il n'ya donc aucun danger qu'un segment wal ultérieur d'un cluster puisse entrer en conflit avec un segment wal antérieur du même groupe.
Vous devez vous assurer que WAL est archivé sur une autre machine, sinon l'exercice est assez inutile. Si vous avez plusieurs clusters sur la même machine, assurez-vous de les archiver à différents répertoires (ou dans des endroits en général), car les noms des segments WAL de différentes clusters À propos de la rétention: vous voulez garder autour de vos sauvegardes pendant un certain temps. Une fois que vous vous êtes débarrassé d'une sauvegarde de base, vous pouvez également vous débarrasser de tous les segments WAL de pg_archivecleanup exécutable qui peut vous aider à vous débarrasser de tous les segments wals archivés plus âgés qu'une sauvegarde de base donnée.
Microsoft SQL Server écrit des flux WAL séparés («Fichiers journaux de transaction») pour chaque base de données - j'ai été surpris que PostgreSQL ne le fait que pour une cluster complète («instance SQL Server» dans MSSQL).
Dans mon scénario, le cluster pertinent est purement pour le développement et les tests locaux, c'est-à-dire qu'il fonctionne sur mon ordinateur portable. Un cluster entièrement séparé héberge la base de données de production et fonctionne ailleurs (c'est-à-dire un autre ordinateur). Je aimerait utiliser des sauvegardes de base - voir Ce commentaire de la mienne , sur une autre réponse à cette question, qui décrit comment je pense à les utiliser. Mais je suis principalement intéressé par la minimisation de l'espace disque utilisé par les fichiers d'archives WAL.
Pour simplement avoir des sauvegardes sans PITR, utilisez soit pg_dump (simple, respectueux de l'espace) ou pg_basebackup avec -x flux . Ensuite, vous pouvez définir archive_mode = off et non archive wal du tout.
Que dois-je faire sur les fichiers d'archives WAL eux-mêmes? Juste les supprimer périodiquement? Ou existe-t-il une commande meilleure / plus sûre de faire la même chose?
Si vous désactivez l'archivage, il n'y aura pas d'archives et rien à supprimer.
Comment puis-je désactiver l'archivage?
Comme je l'ai dit, définissez archive_mode = off dans postgresql.conf et redémarrez.
Génial; Merci! Je pensais que c'était une option pour pg_dump ou pg_basebackup .
J'aimerais pouvoir «construire» ou «reconstruire» l'une de ces bases de données en restaurant à partir d'une sauvegarde de base et d'exécuter des scripts de données de semences.
Où est la basebackup? Si vous restaurez la sauvegarde de la base et exécutant les scripts de graines dessus, vous n'avez pas besoin d'archivage WAL sur Test / Dev. Mais alors ce que vous obtenez, ce sera un clone de prod, ce qui signifie qu'il n'aura pas différentes bases de données pour le test et pour développer dans le même cas, car (vraisemblablement) Prod n'a pas cela.
Si la sauvegarde de la base provient d'un autre endroit, vous devrez décrire ce que c'est. Qui dictera vos besoins wals.
Essayer d'exécuter une instance avec Test et Dev dessus, cela ressemble à une fausse économie pour moi. Il suffit de courir deux instances.
Réglage
archive_mode = off désactivera entièrement une archive WAL. Il y aura toujours des fichiers wal "en direct" dans le répertoire pg_wal ou pg_xlog, mais ceux-ci sont supprimés / recyclés automatiquement après chaque point de contrôle - vous n'avez pas besoin de les gérer, autrement que en contrôlant la fréquence de contrôle des points de contrôle (et en vous assurant de vous assurer de Ne pas avoir de machines à sous de réplication suspendues). Les archives WAL et les fichiers WAL en direct sont des choses différentes. Les fichiers WAL en direct sont obligatoires et sont nécessaires pour récupérer automatiquement quelque chose comme une panne de courant. L'archive WAL peut être nécessaire pour récupérer manuellement à partir d'un crash de disque dur ou de la destruction totale de votre serveur, et n'est probablement pas nécessaire du tout sur Dev / Test.
De bonnes questions! J'ai édité la question pour inclure des détails plus pertinents. Je suis pas restauré une sauvegarde de base de production sur le cluster correspondant. À l'heure actuelle, nous avons du code qui crée la base de données et son schéma, par ex. Tables, index, contraintes. Nous avons également du code qui grave la base de données avec des codes postaux «statiques» (par exemple) et des données de test, par ex. pour exécuter le projet sur un ordinateur de développeur. Notez également que la production Cluster est entièrement séparée de ceci / ces clusters. Ces clusters seulement des bases de données d'hôte dev / test.
Je pensais créer une sauvegarde de base des bases de données de dev / test initialisées, c'est-à-dire après avoir exécuté le code qui crée la base de données, ses tables, etc. et la graine avec des données de test. Cela permettrait de restaurer rapidement les bases de données à un état de travail connu. Je n'ai pas besoin Archivage Wal du tout - nous pourrions toujours recréer ces bases de données ou même recréer le cluster entièrement - mais cela ne semble pas possible de entièrement Désactiver l'archivage WAL. Je cherche un moyen de gérer les fichiers d'archive WAL, c'est-à-dire de minimiser l'espace disque qu'ils utilisent.
"Mais cela ne semble pas possible de désactiver entièrement l'archivage Wal." C'est, je pense que vous déroutez l'archivage avec le point de contrôle. Voir mon édition à ma réponse.
Merci! Je pense avoir la plupart des casse-tête - Dev / Test (uniquement) Les clusters doivent être configurés pour désactiver l'archivage (WAL). Comme le délai d'expiration de point de contrôle maximum est une heure, la taille des fichiers WAL «Live» ne semble pas être un problème, à moins que je n'étais, par exemple. Stress-tester le cluster ou ses bases de données.
N'essayez pas de développer votre propre solution. Utilisez l'une des différentes solutions de sauvegarde prête à l'emploi telles que BARMAN , pg_backrest ou pg_probackup
En ce qui concerne votre "partagé par toutes les bases de données est bizarre" - ce n'est pas bizarre du tout bizarre. Chaque SGBD fonctionne différemment et une "base de données" dans SQL Server est un concept complètement différent de celui d'une "base de données" dans Postgres (puis à nouveau les deux sont complètement différentes d'une "base de données" dans Oracle). La meilleure chose à faire est d'oublier tout ce que vous avez appris sur les concepts architecturaux de base. Vous devez également migrer votre état d'esprit;)
@A_HORSE_WITH_NO_NAME Tu ne plaisantes pas! Il est difficile de discuter, voire de rechercher des informations, en raison des différences terminologiques.