L'archivage en continu peut être utilisé pour créer une configuration de cluster en haute disponibilité (HA) avec un ou plusieurs serveurs de standby prêts à prendre la main sur les opérations si le serveur primaire fait défaut. Cette fonctionnalité est généralement appelée warm standby ou log shipping.
Les serveurs primaire et de standby travaillent de concert pour fournir cette fonctionnalité, bien que les serveurs ne soient que faiblement couplés. Le serveur primaire opère en mode d'archivage en continu, tandis que le serveur de standby opère en mode de récupération en continu, en lisant les fichiers WAL provenant du primaire. Aucune modification des tables de la base ne sont requises pour activer cette fonctionnalité, elle entraîne donc moins de travail d'administration par rapport à d'autres solutions de réplication. Cette configuration a aussi un impact relativement faible sur les performances du serveur primaire.
Déplacer directement des enregistrements de WAL d'un serveur de bases de données à un autre est habituellement appelé log shipping. PostgreSQL™ implémente le log shipping par fichier, ce qui signifie que les enregistrements de WAL sont transférés un fichier (segment de WAL) à la fois. Les fichiers de WAL (16Mo) peuvent être transférés facilement et de façon peu coûteuse sur n'importe quelle distance, que ce soit sur un système adjacent, un autre système sur le même site, ou un autre système à l'autre bout du globe. La bande passante requise pour cette technique varie en fonction du débit de transactions du serveur primaire. Le log shipping par enregistrement est aussi possible avec la streaming replication (voir Section 25.2.5, « Streaming Replication »).
Il convient de noter que le log shipping est asynchrone, c'est à dire que les enregistrements de WAL sont transférés après que la transaction ait été validée. Par conséquent, il y a un laps de temps pendant lequel une perte de données pourrait se produire si le serveur primaire subissait un incident majeur; les transactions pas encore transférées seront perdues. La taille de la fenêtre de temps de perte de données peut être réduite par l'utilisation du paramètre archive_timeout, qui peut être abaissé à des valeurs de quelques secondes. Toutefois, un paramètre si bas augmentera de façon considérable la bande passante nécessaire pour le transfert de fichiers. Si vous voulez une fenêtre de moins d'une minute environ, envisagez l'utilisation de la streaming replication (voir Section 25.2.5, « Streaming Replication »).
La performance de la récupération est suffisamment bonne pour que le standby ne soit en général qu'à quelques instants de la pleine disponibilité à partir du moment où il aura été activé. C'est pour cette raison que cette configuration de haute disponibilité est appelée warm standby. Restaurer un serveur d'une base de sauvegarde archivée, puis appliquer tous les journaux prendra largement plus de temps, ce qui fait que cette technique est une solution de 'disaster recovery' (reprise après sinistre), pas de haute disponibilité. Un serveur de standby peut aussi être utilisé pour des requêtes en lecture seule, dans quel cas il est appelé un serveur de Hot Standby. Voir Section 25.5, « Hot Standby » pour plus d'information.
Il est habituellement préférable de créer les serveurs primaire et de standby de façon à ce qu'ils soient aussi similaires que possible, au moins du point de vue du serveur de bases de données. En particulier, les chemins associés avec les tablespaces seront passés d'un noeud à l'autre sans conversion, ce qui implique que les serveurs primaire et de standby doivent avoir les mêmes chemins de montage pour les tablespaces si cette fonctionnalité est utilisée. Gardez en tête que si CREATE TABLESPACE(7) est exécuté sur le primaire, tout nouveau point de montage nécessaire pour cela doit être créé sur le primaire et tous les standby avant que la commande ne soit exécutée. Le matériel n'a pas besoin d'être exactement le même, mais l'expérience monte que maintenir deux systèmes identiques est plus facile que maintenir deux différents sur la durée de l'application et du système. Quoi qu'il en soit, l'architecture hardware doit être la même -- répliquer par exemple d'un serveur 32 bits vers un 64 bits ne fonctionnera pas.
De manière générale, le log shipping entre serveurs exécutant des versions majeures différentes de PostgreSQL™ est impossible. La politique du PostgreSQL Global Development Group est de ne pas réaliser de changement sur les formats disques lors des mises à jour mineures, il est par conséquent probable que l'exécution de versions mineures différentes sur le primaire et le standby fonctionne correctement. Toutefois, il n'y a aucune garantie formelle de cela et il est fortement conseillé de garder le serveur primaire et celui de standby au même niveau de version autant que faire se peut. Lors d'une mise à jour vers une nouvelle version mineure, la politique la plus sûre est de mettre à jour les serveurs de standby d'abord -- une nouvelle version mineure est davantage susceptible de lire les enregistrements WAL d'une ancienne version mineure que l'inverse.
En mode de standby, le serveur applique continuellement les WAL reçus du serveur maître. Le serveur de standby peut lire les WAL d'une archive WAL (voir restore_command) ou directement du maître via une connexion TCP (streaming replication). Le serveur de standby essaiera aussi de restaurer tout WAL trouvé dans le répertoire pg_xlog du cluster de standby. Cela se produit habituellement après un redémarrage de serveur, quand le standby rejoue à nouveau les WAL qui ont été reçu du maître avant le redémarrage, mais vous pouvez aussi copier manuellement des fichiers dans pg_xlog à tout moment pour qu'ils soient rejoués.
Au démarrage, le serveur de standby commence par restaurer tous les WAL disponibles à l'endroit où se trouvent les archives, en appelant la restore_command. Une fois qu'il a épuisé tous les WAL disponibles à cet endroit et que restore_command échoue, il essaye de restaurer tous les WAL disponibles dans le répertoire pg_xlog. Si cela échoue, et que la réplication en flux a été activée, le standby essaye de se connecter au serveur primaire et de démarrer la réception des WAL depuis le dernier enregistrement valide trouvé dans les archives ou pg_xlog. Si cela échoue ou que la streaming replication n'est pas configurée, ou que la connexion est plus tard déconnectée, le standby retourne à l'étape 1 et essaye de restaurer le fichier à partir de l'archive à nouveau. Cette boucle de retentatives de l'archive, pg_xlog et par la streaming replication continue jusqu'à ce que le serveur soit stoppé ou que le failover (bascule) soit déclenché par un fichier trigger (déclencheur).
Le mode de standby est quitté et le serveur bascule en mode de fonctionnement normal quand un fichier de trigger est trouvé (trigger_file). Avant de basculer, tout WAL immédiatement disponible dans l'archive ou le pg_xlog sera restaurée, mais aucune tentative ne sera faite pour se connecter au maître.
Mettez en place un archivage en continu sur le primaire vers un répertoire d'archivage accessible depuis le standby, comme décrit dans Section 24.3, « Archivage continu et récupération d'un instantané (PITR) ». La destination d'archivage devrait être accessible du standby même quand le maître est inaccessible, c'est à dire qu'il devrait se trouver sur le serveur de standby lui-même ou un autre serveur de confiance, pas sur le serveur maître.
Si vous voulez utiliser la streaming replication, mettez en place l'authentification sur le serveur primaire pour autoriser les connexions de réplication à partir du (des) serveur de standby; c'est à dire, mettez en place une ou des entrées appropriées dans pg_hba.conf avec le champ database positionné à replication. Vérifiez aussi que max_wal_senders est positionné à une valeur suffisamment grande dans le fichier de configuration du serveur primaire.
Effectuez une sauvegarde de base comme décrit dans Section 24.3.2, « Réaliser une sauvegarde de base » pour initialiser le serveur de standby.
Pour paramétrer le serveur de standby, restaurez la sauvegarde de base effectué sur le serveur primaire (voir (see Section 24.3.3, « Récupération à partir d'un archivage continu »). Créez un fichier de commande de récupération recovery.conf dans le répertoire de données du cluster de standby, et positionnez standby_mode à on. Positionnez restore_command à une simple commande qui recopie les fichiers de l'archive de WAL.
![[Note]](images/note.png)
N'utilisez pas pg_standby ou des outils similaires avec le mode de standby intégré décrit ici. restore_command devrait retourner immédiatement si le fichier n'existe pas; le serveur essayera la commande à nouveau si nécessaire. Voir Section 25.4, « Méthode alternative pour le log shipping » pour utiliser des outils tels que pg_standby.
Si vous souhaitez utiliser la streaming replication, renseignez primary_conninfo avec une chaîne de connexion libpq, contenant le nom d'hôte (ou l'adresse IP) et tout détail supplémentaire nécessaire pour se connecter au serveur primaire. Si le primaire a besoin d'un mot de passe pour l'authentification, le mot de passe doit aussi être spécifié dans primary_conninfo.
Si vous mettez en place le serveur de standby pour des besoins de haute disponibilité, mettez en place l'archivage de WAL, les connexions et l'authentification à l'identique du serveur primaire, parce que le serveur de standby fonctionnera comme un serveur primaire après la bascule. Vous aurez aussi besoin de positionner trigger_file pour rendre la bascule possible. Si vous mettez en place le serveur de standby pour des besoins de reporting, sans aucune intention de basculer dessus, trigger_file n'est pas nécessaire.
Si vous utilisez une archive WAL, sa taille peut être réduite en utilisant l'option archive_cleanup_command pour supprimer les fichiers qui ne sont plus nécessaires au serveur de standby. L'outil pg_archivecleanup est conçu spécifiquement pour être utilisé avec archive_cleanup_command dans des configurations typiques de standby, voir Section F.22, « pg_archivecleanup ». Notez toutefois que si vous utilisez l'archive à des fins de sauvegarde, vous avez besoin de garder les fichiers nécessaires pour restaurer à partir de votre dernière sauvegarde de base, même si ces fichiers ne sont plus nécessaires pour le standby.
If you're using a WAL archive, its size can be minimized using the parameter to remove files that are no longer required by the standby server. Note however, that if you're using the archive for backup purposes, you need to retain files needed to recover from at least the latest base backup, even if they're no longer needed by the standby.
Un simple exemple de recovery.conf est:
standby_mode = 'on' primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' restore_command = 'cp /path/to/archive/%f %p' trigger_file = '/path/to/trigger_file' archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
Vous pouvez avoir n'importe quel nombre de serveurs de standby, mais si vous utilisez la streaming replication, assurez vous d'avoir positionné max_wal_senders suffisamment haut sur le primaire pour leur permettre de se connecter simultanément.
La streaming replication permet à un serveur de standby de rester plus à jour qu'il n'est possible avec l'envoi de journaux par fichiers. Le standby se connecte au primaire, qui envoie au standby les enregistrements de WAL dès qu'ils sont générés, sans attendre qu'un fichier de WAL soit rempli.
La streaming replication est asynchrone, il y a donc toujours un petit délai entre la validation d'une transaction sur le primaire et le moment où les changements sont visibles sur le standby. Le délai est toutefois beaucoup plus petit qu'avec l'envoi de fichiers, habituellement en dessous d'une seconde en partant de l'hypothèse que le standby est suffisamment puissant pour supporter la charge. Avec la streaming replication, archive_timeout n'est pas nécessaire pour réduire la fenêtre de perte de données.
Si vous utilisez la streaming replication sans archivage en continu des fichiers, vous devez positionner wal_keep_segments sur le maître à une valeur suffisamment grande pour garantir que les anciens segments de WAL ne sont pas recyclés trop tôt, alors que le standby pourrait toujours avoir besoin d'eux pour rattraper son retard. Si le standby prend trop de retard, il aura besoin d'être réinitialisé à partir d'une nouvelle sauvegarde de base. Si vous positionnez une archive de WAL qui est accessible du standby, wal_keep_segments n'est pas nécessaire, puisque le standby peut toujours utiliser l'archive pour rattraper son retard.
Pour utiliser la streaming replication, mettez en place un serveur de standby en mode fichier comme décrit dans Section 25.2, « Serveurs de Standby par transfert de journaux ». L'étape qui transforme un standby en mode fichier en standby en streaming replication est de faire pointer primary_conninfo dans le fichier recovery.conf vers le serveur primaire. Positionnez listen_addresses et les options d'authentification (voir pg_hba.conf) sur le primaire pour que le serveur de standby puisse se connecter à la pseudo-base replication sur le serveur primaire (voir Section 25.2.5.1, « Authentification »).
Sur les systèmes qui supportent l'option de keepalive sur les sockets, positionner tcp_keepalives_idle, tcp_keepalives_interval et tcp_keepalives_count aide le primaire à reconnaître rapidement une connexion interrompue.
Positionnez le nombre maximum de connexions concurrentes à partir des serveurs de standby (voir max_wal_senders pour les détails).
Quand le standby est démarré et que primary_conninfo est positionné correctement, le standby se connectera au primaire après avoir rejoué tous les fichiers WAL disponibles dans l'archive. Si la connexion est établie avec succès, vous verrez un processus walreceiver dans le standby, et un processus walsender correspondant sur le primaire.
Il est très important que les privilèges d'accès pour la réplications soient paramétrés pour que seuls les utilisateurs de confiance puissent lire le flux WAL, parce qu'il est facile d'en extraire des informations privilégiées. Les serveurs de standby doivent s'authentifier sur le primaire avec un compte superutilisateur. Par conséquent, un rôle avec les privilèges SUPERUSER et LOGIN doit être créé sur le primaire.
L'authentification cliente pour la réplication est contrôlée par un enregistrement de pg_hba.conf spécifiant replication dans le champ database. Par exemple, si le standby s'exécute sur un hôte d'IP 192.168.1.100 et que le nom du superutilisateur pour la réplication est foo, l'administrateur peut ajouter la ligne suivante au fichier pg_hba.conf sur le primaire:
# Autoriser l'utilisateur "foo" de l'hôte 192.168.1.100 à se connecter au primaire # en tant que standby de replication si le mot de passe de l'utilisateur est correctement fourni # # TYPE DATABASE USER CIDR-ADDRESS METHOD host replication foo 192.168.1.100/32 md5
Le nom d'hôte et le numéro de port du primaire, le nom d'utilisateur de la connexion, et le mot de passe sont spécifiés dans le fichier recovery.conf. Le mot de passe peut aussi être enregistré dans le fichier ~/.pgpass sur le serveur en attente (en précisant replication dans le champ database). Par exemple, si le primaire s'exécute sur l'hôte d'IP 192.168.1.50, port 5432, que le nom du superutilisateur pour la réplication est foo, et que le mot de passe est foopass, l'administrateur peut ajouter la ligne suivante au fichier recovery.conf sur le standby:
# Le standby se connecte au primaire qui s'exécute sur l'hôte 192.168.1.50 # et port 5432 en tant qu'utilisateur "foo" dont le mot de passe est "foopass" primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
Un important indicateur de santé de la streaming replication est le nombre d'enregistrements générés sur le primaire, mais pas encore appliqués sur le standby. Vous pouvez calculer ce retard en comparant le point d'avancement des écritures du WAL sur le primaire avec le dernier point d'avancement reçu par le standby. Ils peuvent être récupérés en utilisant pg_current_xlog_location sur le primaire et pg_last_xlog_receive_location sur le standby, respectivement (voir Tableau 9.57, « Fonctions de contrôle de la sauvegarde » et Tableau 9.58, « Fonctions d'information sur la restauration » pour plus de détails). Le point d'avancement de la réception dans le standby est aussi affiché dans le statut du processus de réception des WAL (wal receiver), affiché par la commande ps (voyez Section 27.1, « Outils Unix standard » pour plus de détails).
Haute
disponibilité, répartition de charge et réplication