Réplication continue de l'ancien vers le nouveau PostgreSQL avec Slony

La réplication de streaming native dans PostgreSQL ne fonctionne qu'entre serveurs avec la même version principale. Nous avons parlé de réplication logique dans un article précédent . Nous avons vu comment la réplication logique aide à déplacer les données d'une version de PostgreSQL vers une autre. Mais la réplication logique ne convient qu'aux versions prises en charge de PostgreSQL, par exemple, PostgreSQL 9.4 et PostgreSQL 11. Que faire avec les versions antérieures à 9.4? Utilisez Slony-I .

Utilisez la réplication avec Slony-I pour transférer des données d'anciennes bases de données vers la dernière version de PostgreSQL. Qu'est-ce que Slony et comment ça marche?

Ceci est le quatrième article de notre série Mise à niveau ou migration d'anciennes versions de PostgreSQL vers de nouvelles , où nous apprenons différentes méthodes de mise à jour des bases de données PostgreSQL.

Slony

Slony est une implémentation de réplication logique au niveau de l'application pour PostgreSQL. Ou plutôt, il s'agit d'un outil de réplication tiers qui nécessite une installation et une configuration distinctes. Slony existe depuis longtemps. La dernière version prend en charge PostgreSQL de 8.4 à 11.

Le principal objectif de la réplication est de transférer les modifications d'un serveur de base de données à un autre. Pour mieux comprendre l'architecture, regardons les termes: Slon, events et slonik.

Soit dit en passant, Slony, si vous n’avez pas deviné, ce sont des «éléphants». Et ils ont vraiment une excellente mémoire. Ce n'est pas un hasard si un éléphant strict mais mignon s'affiche sur le logo PostgreSQL.

Slon

Slon est un démon qui s'exécute sur chaque nœud PostgreSQL dans la réplication Slony-I. Ces démons sont utilisés pour gérer les événements de configuration et de réplication pour chaque serveur PostgreSQL. Chaque serveur PostgreSQL est appelé hôte. Tous les nœuds forment ensemble un cluster Slony.

Le nœud éditeur est la source des modifications, et le nœud abonné reçoit et applique les modifications de l'éditeur.

Pour configurer la réplication, vous devez spécifier toutes les tables répliquées ou un ensemble de réplication. L'abonnement fonctionne pour un ensemble spécifique. Les modifications apportées aux tables répliquées sont combinées dans SYNC, un groupe de transactions qui sont appliquées ensemble sur les abonnés.

Les événements

Les modifications sont signalées par l'éditeur en tant qu'événements. Lorsqu'un événement est traité par le démon Slon sur l'hôte distant, un accusé de réception est généré. Et les événements notifient les nœuds des modifications de configuration, comme l'ajout ou la suppression de nouveaux nœuds, de nouveaux abonnements ou des modifications DDL.

Chaque événement a son propre identifiant de source unique, son numéro de série, son identifiant de transaction pour l'instantané sur le nœud d'événement, plusieurs arguments et un horodatage avec un fuseau horaire.
Les déclencheurs écrits dans PL / pgSQL enregistrent toutes les modifications apportées aux tables répliquées. Malheureusement, il n'existe aucun moyen fiable de gérer les modifications apportées aux objets blob, DDL ou aux utilisateurs et aux rôles.

slonik

Il s'agit d'un utilitaire de ligne de commande avec un analyseur et un interpréteur qui accepte les scripts slonik - un langage déclaratif simple. Il est conçu pour surmonter les limites d'un langage procédural. À l'aide des commandes slonik, vous pouvez configurer ou modifier la réplication dans Slony, et elles peuvent être intégrées dans des scripts shell. Il accepte les commandes d'entrée standard ou de fichiers. L'exemple ci-dessous montre comment le script slonik est passé à slonik et incorporé dans des scripts shell.

Le script qui crée la configuration initiale pour un schéma maître-esclave simple dans notre base de données pgbench ressemble à ceci:

#!/bin/sh slonik <<_EOF_ cluster name = percona_pg; node 1 admin conninfo = 'dbname=pg93 host=pg93_host user=percona_pg93_user'; node 2 admin conninfo = 'dbname=pg11 host=pg11_host user=percona_pg11_user'; #-- # Creates a _$(clustername), this example, _percona_pg schema #-- init cluster ( id=1, comment = 'Legacy PG Node'); #-- # Add a list of tables being replicated to a set. #-- create set (id=1, origin=1, comment='pgbench'); set add table (set id=1, origin=1, id=1, fully qualified name = 'public.pgbench_accounts', comment='accounts'); set add table (set id=1, origin=1, id=2, fully qualified name = 'public.pgbench_branches', comment='branches'); set add table (set id=1, origin=1, id=3, fully qualified name = 'public.pgbench_tellers', comment='tellers'); set add table (set id=1, origin=1, id=4, fully qualified name = 'public.pgbench_history', comment='history'); #-- # Create the second node (the slave) tell the 2 nodes how to connect to # each other and how they should listen for events. #-- store node (id=2, comment = 'Target node', event node=1); store path (server = 1, client = 2, conninfo='dbname=pg93 host=pg93_host user=percona_pg93_user'); store path (server = 2, client = 1, conninfo='dbname=pg11 host=pg11_host user=percona_pg11_user'); _EOF_ 

Pourquoi Slony est-il pratique pour les migrations?

Malgré les avantages de la réplication logique interne, pour les versions antérieures à PostgreSQL 9.4, vous devez utiliser cette solution tierce. L'approche basée sur les déclencheurs dépend de l'API de base de données - les deux versions doivent être compatibles pour utiliser la syntaxe PL / pgSQL et SQL.

Comment adapter la base de données pour une utilisation avec Slony?

• Les tables doivent avoir des clés primaires. Ajoutez un champ série à toutes les tables sans clé primaire.
• Les modifications apportées au blob OID ne sont pas répliquées. Si vous avez des colonnes avec des valeurs courtes, convertissez-les en BYTEA. Si les objets sont très volumineux - par exemple, des images -, il est préférable de stocker les données dans un stockage externe (par exemple, S3 dans le cloud Amazon). Si la modification de l'application est trop compliquée, appliquez les modifications d'objet blob à la dernière étape de la migration.
• ALTER TABLE et autres opérations DDL. Slony ne détecte pas les changements de structure de table. Utilisez la commande slonik EXECUTE SCRIPT pour appliquer un fichier SQL avec des chaînes SQL ou DDL à l'ensemble du cluster de réplication.

Migration en ligne des versions précédentes de PostgreSQL

1. Créez un utilisateur de réplication avec des privilèges de superutilisateur. Vous pouvez configurer les droits en détail, mais c'est beaucoup plus compliqué.
2. Créez une base de données à destination avec un accès TCP / IP.
3. Copiez les définitions de table du maître vers les esclaves.
4. Installez Slony-I. Sur les serveurs avec une ancienne version du système d'exploitation, il sera plus facile d'installer Slony-I à partir du code source.
5. Définissez le cluster, l'ensemble de tables et les informations de connexion de noeud comme une liste de commandes slonik.
6. Exécutez le démon slon sur chaque serveur PostgreSQL. Vérifiez la sortie standard ou les fichiers journaux pour les erreurs de connexion.
7. Exécutez les commandes d'abonnement slonik pour démarrer la synchronisation.
8. Testez les requêtes en lecture seule dans la nouvelle version de Postgres.
9. Lorsque toutes les données sont répliquées et synchronisées, arrêtez les applications et dirigez-les vers le nouveau serveur Postgres.
10. Utilisez le nœud de désinstallation dans la nouvelle version de PostgreSQL pour supprimer toutes les traces de réplication Slony.

Transition vers les versions précédentes

Utilisez la même procédure pour mettre à niveau vers les versions précédentes. Avec Slony, vous pouvez répliquer à partir de n'importe quelle version et vers n'importe quelle version de PosgreSQL prise en charge par la version Slony. La version minimale prise en charge est 8.4.

Résumé

Nous avons vu en termes généraux comment vous pouvez passer à la nouvelle version avec un temps d'arrêt minimal en utilisant Slony. En savoir plus sur notre webinaire .