| > > > | |
 Serveurs de
secours semi-automatique (Warm Standby) pour la haute
disponibilité
|
Haute disponibilité, répartition de charge et
réplication
|
Cette section discute de la façon de migrer les données de la base vers une version plus récente de PostgreSQL™. Le sujet de cette section ne concerne pas la procédure d'installation per se du logiciel ; ces détails sont dans le Chapitre 15, Procédure d'installation de PostgreSQL™ du code source.
En règle générale, le format interne des données est sujet à modification d'une version majeure à l'autre (quand le nombre après le premier point change). Ce qui n'est pas le cas pour les versions mineures à l'intérieur d'une même version majeure (quand seul le nombre après le deuxième point change) ; elles ont toujours un format de stockage compatible. Par exemple, les versions 8.1.1, 8.2.3 et 8.3 ne sont pas compatibles, alors que les versions 8.2.3 et 8.2.4 le sont. Lorsque la mise à jour concerne des versions compatibles, les exécutables peuvent simplement être remplacés et le répertoire des données sur le disque réutilisé. Dans le cas contraire, il faut sauvegarder les données et les restaurer sur le nouveau serveur. pg_dump doit être utilisé pour cela ; les méthodes de sauvegarde au niveau système de fichiers ne fonctionnent évidemment pas. Un certain nombre de vérifications est automatiquement effectué pour interdire l'utilisation d'un répertoire de données d'une version incompatible. Il n'y a donc pas grand risque à lancer une mauvaise version de PostgreSQL™ sur un répertoire de données.
Il est recommandé d'utiliser les programmes pg_dump et pg_dumpall issus de la nouvelle version de PostgreSQL™. Ceci permet de tirer parti des améliorations de ces programmes. Les versions actuelles des programmes de sauvegarde peuvent lire des données sur des serveurs de versions anciennes, jusqu'à la 7.0.
La durée d'indisponibilité est minimisée par l'installation de nouveau serveur dans un répertoire différent et par le lancement en parallèle des deux serveurs (ancien et nouveau), sur des ports différents. On peut alors utiliser une commande telle que :
pg_dumpall -p 5432 | psql -d postgres -p 6543
pour transférer les données. On peut aussi utiliser un fichier intermédiaire. L'ancien serveur peut alors être éteint, et le nouveau démarré sur le port utilisé par l'ancien. Il est impératif que la base de données ne soit pas modifiée pendant l'exécution de pg_dumpall. Ces modifications seraient, sans cela, perdues. Le Chapitre 19, Authentification du client informe sur la façon d'interdire l'accès.
Il est aussi possible d'utiliser des outils de réplication comme Slony™ pour créer un serveur esclave avec la nouvelle version de PostgreSQL™. L'esclave peut se trouver sur le même ordinateur ou sur un autre. Une fois qu'il est synchronisé avec le serveur maître (utilisant l'ancienne version de PostgreSQL™), le maître et l'esclave peuvent être basculés pour que l'esclave devienne le maître. L'ancien serveur peut alors être arrêté. Ce basculement intervient en quelques secondes dans le cadre d'une mise à jour.
Si n'est pas souhaité, ou pas possible, de lancer les deux serveurs en parallèle, il faut réaliser l'étape de sauvegarde avant d'installer la nouvelle version, éteindre le serveur, déplacer l'ancienne version vers un autre endroit, installer la nouvelle, la démarrer et enfin restaurer les données. Par exemple :
pg_dumpall > sauvegarde.sql pg_ctl stop mv /usr/local/pgsql /usr/local/pgsql.old cd ~/postgresql-8.4.22 gmake install initdb -D /usr/local/pgsql/data postgres -D /usr/local/pgsql/data psql -f sauvegarde.sql postgres
Toutes les méthodes pour arrêter et démarrer les serveurs, ainsi que d'autres détails sont présentés dans le Chapitre 17, Configuration du serveur et mise en place. Les instructions d'installation donnent des conseils sur les endroits stratégiques pour réaliser ces opérations.
![[Note]](images/note.png)
Lorsque « l'ancienne installation est déplacée », il se peut qu'elle ne soit plus correctement utilisable. En effet, certains exécutables contiennent des chemins absolus vers les différents programmes et fichiers de données installés. Ce n'est habituellement pas un problème insurmontable, mais pour utiliser deux installations en parallèle pendant un moment, il faut leur affecter des répertoires d'installation différents au moment de la construction. (Ce problème est rectifié pour PostgreSQL™ 8.0 et suivantes tant que tous les sous-répertoires contenant des fichiers installées sont déplacés ensemble ; par exemple si /usr/local/postgres/bin/ va dans /usr/local/postgres.old/bin/, alors /usr/local/postgres/share/ doit aller dans /usr/local/postgres.old/share/. Dans les versions antérieures à la 8.0, déplacer une installation comme ceci n'aurait pas fonctionné.)
En pratique, vous voudrez probablement tester vos applications clientes sur la nouvelle version avant de basculer complètement. C'est une raison supplémentaire pour faire cohabiter des installations d'anciennes et nouvelles versions. Quand vous testez une mise à jour majeure de PostgreSQL™, prenez en compte les catégories suivantes de changements potentiels :
Les fonctionnalités de surveillance et de contrôle du serveur changent et s'améliorent souvent à l'occasion d'une version majeure.
De façon générale, elle inclut de nouvelles fonctionnalités et commandes SQL, et non des changements de comportements, sauf notification contraire dans les notes de version.
Habituellement, les bibliothèques telles que libpq ne font qu'ajouter des fonctionnalités, sauf notification contraire dans les notes de version.
Les changements concernant le catalogue système n'affectent habituellement que les outils de gestion de base de données.
Cela implique des changements dans les API des fonctions du serveur, qui est écrit dans le langage de programmation C. Des changements de ce type touche du code qui utilise des fonctions profondément internes au serveur.
