PostgreSQL + dbSQWare : sauvegarde et restauration Point-In-Time (2/2)

de | 2017-07-14
0 Commentaire

Résumé de l’épisode précédent

Dans l’article précédent, nous avons vu le principe d’une sauvegarde Point-In-Time ainsi que la manière dont dbSQWare le gère. Nous nous sommes arrêtés sur le dernier fichier (« RestoreCommands.hlp ») car il contient la procédure et les commandes nécessaires à la restauration de la base dont il a eu la charge.

Après une pause pleine de suspens, nous allons le détailler ligne à ligne car il regroupe toutes les informations utiles pour chacune des étapes. Il couvre le cas où vous cherchez à restaurer la base à son emplacement d’origine.

Avertissement :

Ce fichier est une aide précieuse et pleine de bonne volonté mais cela ne vous dispense pas de refléchir à ce que vous faites. Ne prenez pas cet air offensé : nous savons que vous êtes un professionnel mais nous devons le dire.

Ne soyez pas si susceptible.

 

Avertissement bis :

La sauvegarde PITR contient toutes les *données* mais il faut naturellement que les binaires soient installés et de version identique à celles d’origine.

 

Les avertissements légaux (« disclaimers », comme cela se disait sur les forums de Warez) étant dits, revenons à ce fichier et voyons ce qu’il contient.

Le fichier « RestoreCommand.hlp » : votre meilleur allié

Rappel pour ceux qui auraient dormi depuis la semaine dernière : ce fichier se trouve dans le répertoire dbSQWare dédié à une P.I.T.R (dossier dont le nom est de la forme « PITR_YYYYMMDD_hhmmss »), lui-même situé dans le dossier de sauvegardes disigné par la variable « gvsqw_RootPitr ». Chez nous, c’est de la forme « /pgbackup/nom_du_cluster/ ».

Dans le même ordre d’idée, le chemin d’origine de notre installation est « /pgdata/nom_du_cluster ». De toute façon, les commandes seront adaptées à votre installation.

cd $gvsqw_RootPitr;cat RestoreCommands.hlp

Qu’est-ce qui s’offre ainsi à nos yeux remplis d’étoiles ?

  • Un en-tête contenant les informations générales (architecture de départ, date, nom de la base, machine) :
#Backup INSTANCE_POSTGRES, 20170702_210015, SunOS machine_origine 5.11 11.3 sun4v sparc sun4v

Ici, un backup récent sur une machine Solaris.

Suivent les différentes actions à prendre pour reconstruire la base d’origine en partant de l’hypothèse que vous repartez de zéro. Dans la plupart des cas, un copié/collé est suffisant.

  • Première action : arrêter l’instance si elle tourne toujours.
pg_ctl stop -m fast

Note : le « -m fast » est superflu si vous êtes en PostgreSQL 9.4 ou plus récente car c’est devenu le mode par défaut.

  • Création des dossiers

Dans le cas où vous repartez d’un File System entièrement vide.

mkdir -p /pgdata/INSTANCE_POSTGRES/logs
mkdir -p /pgdata/INSTANCE_POSTGRES/data
mkdir -p /pgdata/INSTANCE_POSTGRES/archive_xlog

Note : il y a une répétition inutile des ordres de création des répertoires. Vous pouvez modifier le fichier RestoreCommand.hlp ou les ignorer.

  • Ensuite, on déplace les fichiers de configuration depuis le répertoire de sauvegarde vers le PGDATA :
cp /pgbackup/INSTANCE_POSTGRES/PITR/PITR_20170702_210015/postgresql.conf /pgdata/INSTANCE_POSTGRES/data/postgresql.conf
cp /pgbackup/INSTANCE_POSTGRES/PITR/PITR_20170702_210015/pg_hba.conf /pgdata/INSTANCE_POSTGRES/data/pg_hba.conf
cp /pgbackup/INSTANCE_POSTGRES/PITR/PITR_20170702_210015/pg_ident.conf /pgdata/INSTANCE_POSTGRES/data/pg_ident.conf
  • On enchaîne sur l’opération la plus longue : remettre les données à leur place.
DBA en train d'attendre que l'application des logs se termine (Archives personnelles de l'auteur)

DBA en train d’attendre que l’application des logs se termine (Archives personnelles de l’auteur)

mkdir -p /pgdata/INSTANCE_POSTGRES/data
cd /pgdata/INSTANCE_POSTGRES/data
gzip -dc /pgbackup/INSTANCE_POSTGRES/PITR/PITR_20170702_230003_tar/data_dir.tar.gz| tar xvf -

Avez-vous remarqué le « _tar » dans le nom du répertoire PITR ?

En fait, dbSQWare permet d’archiver le dossier « data_dir » sour forme d’archive compressée (si le volume est faible ou si vous économisez l’espace disque) ou non (si vous avez de la réserve d’espace ou que vous économisez le temps CPU). Dans ce dernier cas, l’extension sera « _rsync ».

La méthode de restauration varie en conséquence et le fichier RestoreCommand.hlp indiquera la commande adaptée. C’est rudement bien fait, quand même.

  • Avant d’attaquer la récupération (le « recovery » du « point-in-time recovery »), il faut faire un peu de ménage.

Suppression du fichier *.pid, des xlogs présents au moment de la sauvegarde puisqu’ils sont contenus dans les archives et des journaux d’évènements du serveur.

cd /pgdata/INSTANCE_POSTGRES/data
rm -f postmaster.pid pg_log/* pg_xlog/[0-9A-F]*
  • Si votre instance utilise des tablespaces…

…dbSQWare vous indiquera lesquels existaient et comment les recréer.

Tout est prêt, tout est propre alors…

  • Appliquons les journaux de transactions archivées.

Le document propose deux variantes, selon que vous soyez dans le cas où les archive xlogs sont prêts à l’emploi dans le répertoire d’origine ou bien s’il faut d’abord les récupérer depuis celui de sauvegarde.
Pensez à configurer le « recovery.conf » avec la date souhaitée !


# Choose recovery.conf file to use :
##cp -p /pgbackup/INSTANCE_POSTGRES/PITR/PITR_20170702_210015/recovery.conf /pgdata/INSTANCE_POSTGRES/data/.
##cp -p /pgbackup/INSTANCE_POSTGRES/PITR/PITR_20170702_210015/recoverySimple.conf /pgdata/INSTANCE_POSTGRES/data/recovery.conf

Une fois cette étape terminée, vous devez avoir récupéré une instance active et cohérente.
Par prudence, avant d’annoncer la résurrection de la base, prenez le temps de vérifier le journal du serveur, de vous connecter pour passer quelques requêtes et de redémarrer l’instance (un geste proche de la superstition, hérité des premières versions de la 9, où nous avons rencontré des « trucs curieux », faute de meilleurs termes. Neuf chances sur dix que cela ne soit plus utile).

 

Conclusion

Idéalement, vous ne devriez pas découvrir les commandes de restauration au moment de les passer. Malheureusement, les entreprises qui disposent d’un environnement pour la validation des procédures de restauration se font de plus en plus rare. Alors prennez un peu d’avance et renseignez vous avant l’incident.

Pour l’avoir fait plusieurs fois dans des conditions plus ou moins tendues, nous pouvons vous l’affirmer : la restauration d’une PITR PotsgreSQL est simple et fiable. Encore faut-il avoir sous les mains tous les fichiers nécessaires pour s’éviter une mauvaise surprise.

C’est précisément la valeur ajoutée de dbSQWare : chaque script fait ce que *vous* auriez fait (ou auriez dû faire) et s’efforce de prévoir ce qui vous serait utile en cas d’urgence. Cela vient de l’origine du produit, écrit par un DBA qui sait pertinemment ce que représente une corruption de file system au beau milieu de la nuit.

Deux mots avant de conclure le sujet : premièrement, dbSQWare génère une crontab de référence qui inclue sauvegarde logique avec pg_dump et sauvegarde PITR. Utilisez la ou inspirez vous en pour votre plan de maintenance. Deuxièmement, et c’est valable pour tous ses autres scripts, dbSQWare vous indique toujours ce qu’il fait et quelles sont les commandes lancées. Cela vous permet d’apprendre et de comprendre ce qui est fait uniquement en lisant les logs du script.

Profitez-en.

Des problèmes ? des questions ? Exprimez-vous ! Les commentaires sont ouverts. Coquilles et fautes de grammaires sont notre lot quotidien : signalez-les nous à m.capello@dbsqware.com

Crédit photo : une drôle d’histoire au sujet de travaux publics,  trouvée sur 94citoyens.com