Vous n'êtes pas identifié(e).
Bonjour à tous,
Je dispose d'une infra bisite rélié par un lien intranet intersite avec une réplication physique bati sur postgresql 12 et postgis sur deux machines virtuelles.
afin de faire des tests de migration (en gros 1To de bases de données hébergées) j'ai rajouté 2 machines virtuelles avec OS et postgresql 14 et postgis 3 que j'ai tuné et préréglée pour la replication physique.
aujourd'hui je me pose la question suivante en terme de performance et de fiabilité de l'opération de migration vis à vis de la réplication par flux
le déroulé s'effectue comme suit :
sur l'infra ancienne j'attends la sauvegarde du vendredi soir sur l'infra en version 12 puis je lance la restauration à partir de ce répertoire de sauvegarde sur l'infra 14.
Question jusqu'alors je laissais ce conclure cette phase de restauration SANS réplication vers le serveur esclave (je l'éteins ou je ne place pas le fichier signal.....)
puis je profitais du week-end pour faire une copie physique des bases via un rsync et une fois aboutie relancer le serveur esclave.
je me pose la question suivante est-ce que je prends un risque à laisser la réplication active pendant la phase de restauration des bases qui va solliciter la même machine physique et virtuelle pour restaurer et envoyer les données au serveur secondaire.
Si vous aves des avis ou des retours à ce sujet. sinon je ferais un retour (pour info 16 processeurs et 8Mo de ram sur le serveur concerné et 1To de données à gérer environ 10h de restauration les dernières années)
D'avance merci !
Hors ligne
J'imagine que vos machine ont 8GB de RAM et non 8MO 
Pour le reste, cela dépend grandement de comment tout est configuré. S'agit-il d'une restauration en parallèle ? Y a-t-il des slots de réplications ? En cas de problème, vous aurez à choisir entre ralentir la restauration, sacrifier le serveur secondaire (cad devoir le resynchroniser de 0 plus tard) ou sacrifier le serveur primaire (cad le voir finir en arrêt brutal pour cause de manque d'espace disque dans le répertoire pg_wal). À vous de voir ce qui vous convient le mieux.
Pourquoi ne pas utiliser pg_upgrade pour la montée de versions, à partir d'un réplicat physique / pg_basebackup. Cela devrait être bien plus efficace qu'un pg_dump/pg_restore.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Oui bien sûr 8 go de ram ^^
effectivement il y a un slot de replication oui c'est une retauration en parraléle avec le nb de job correspondant au nombre de processeur -1.
Sauf erreur le pg_upgrade ne peut être utlisé que sur la même machine or je vis à faire évoluer toutes les caractéristiques du serveur (OS, version de Postgres etc et surtout je fais des tests de remontée de bases régulièrement avant les phases de migration afin de n'avoir que peu de mauvaise surprise le week-end choisi!)
Hors ligne
Concernant pg_upgrade, cela nécessite les 2 versions des binaires présentes, ainsi que les données présentes localement. Le reste est libre, sous réserve de ne pas faire de changement d'architecture (32 <-> 64 bits, Windows <-> Linux, Big Endian <-> Little Endian etc), mais pg_upgrade vous prévient avant en cas de problème. Rien ne vous empêche de ruser pour limiter le temps pour avoir la dernière versions des données sur le nouveau serveur (restaurer une sauvegarde puis appliquer les WAL depuis le serveur principal, faire un rsync une fois le serveur principal éteint...).
La grosse limitation concerne les versions de la libc / ICU. En cas de version différentes, il est possible (voire probable en fonction des versions présentes et des collations utilisées) que les index portant sur des données collationnables soient corrompues. La solution consiste à faire un reindex de tous les index index impactés, mais même faire un pg_upgrade puis réindexer tous les index (puis faire le vacuum/analyze préconisé par pg_upgrade) devrait être beaucoup moins long que tout restaurer à coup de pg_dump / pg_restore.
Julien.
https://rjuju.github.io/
Hors ligne
