Un guide d'expert sur la réplication Slony pour PostgreSQL

Qu'est-ce que Slony ?

Slony-I (appelé simplement "Slony" à partir de maintenant) est un système de réplication tiers pour PostgreSQL qui date d'avant la version 8.0, ce qui en fait l'une des plus anciennes options de réplication disponibles. Il fonctionne comme une méthode de réplication basée sur des déclencheurs qui est une solution « maître vers plusieurs esclaves ».

Slony fonctionne en installant des déclencheurs sur chaque table à répliquer, à la fois sur le maître et sur les esclaves, et chaque fois que la table reçoit un INSERT, UPDATE ou DELETE, il enregistre quel enregistrement est modifié et quelle est la modification. Les processus externes, appelés « démons slon », se connectent aux bases de données comme n'importe quel autre client et récupèrent les modifications du maître, puis les rejouent sur tous les nœuds esclaves abonnés au maître. Dans une configuration de réplication performante, cet élément asynchrone on peut s'attendre à ce que la réplication ait un retard de 1 à 20 secondes sur le maître.

Au moment d'écrire ces lignes, la dernière version de Slony est la version 2.2.6 et prend en charge PostgreSQL 8.3 et supérieur. Le support se poursuit à ce jour avec des mises à jour mineures, mais si une future version de PostgreSQL modifie les fonctionnalités fondamentales des transactions, des fonctions, des déclencheurs ou d'autres fonctionnalités de base, le projet Slony peut décider d'interrompre les mises à jour importantes pour prendre en charge ces nouvelles approches drastiques.

La mascotte de PostgreSQL est un éléphant connu sous le nom de « Slonik », qui signifie « petit éléphant » en russe. Étant donné que ce projet de réplication concerne la réplication de nombreuses bases de données PostgreSQL entre elles, le mot russe pour éléphants (pluriel) est utilisé :Slony.

Concepts

• Cluster :une instance de réplication Slony.
• Nœud :une base de données PostgreSQL spécifique en tant que nœud de réplication Slony, qui fonctionne comme maître ou esclave pour un ensemble de réplication.
• Ensemble de réplication :un groupe de tables et/ou de séquences à répliquer.
• Abonnés :un abonné est un nœud qui est abonné à un ensemble de réplication et reçoit des événements de réplication pour toutes les tables et séquences de cet ensemble à partir du nœud maître.
• Démons Slony :les principaux travailleurs qui exécutent la réplication, un démon Slony est lancé pour chaque nœud de l'ensemble de réplication et établit diverses connexions au nœud qu'il gère, ainsi qu'au nœud maître.

Comment est-il utilisé

Slony est installé soit par la source, soit via les référentiels PGDG (PostgreSQL Global Development Group) qui sont disponibles pour les distributions Linux basées sur Red Hat et Debian. Ces binaires doivent être installés sur tous les hôtes qui contiendront un nœud maître ou esclave dans le système de réplication.

Après l'installation, un cluster de réplication Slony est configuré en émettant quelques commandes à l'aide du binaire « slonik ». ‘slonik’ est une commande avec une syntaxe simple mais unique pour initialiser et maintenir un cluster slony. C'est l'interface principale pour envoyer des commandes au cluster Slony en cours d'exécution qui est en charge de la réplication.

L'interfaçage avec Slony peut se faire soit en écrivant des commandes slonik personnalisées, soit en compilant slony avec le drapeau --with-perltools, qui fournit les scripts "altperl" qui aident à générer ces scripts slonik nécessaires.

Créer un cluster de réplication Slony

Un « cluster de réplication » est un ensemble de bases de données qui font partie de la réplication. Lors de la création d'un cluster de réplication, un script d'initialisation doit être écrit qui définit les éléments suivants :

• Le nom du cluster Slony souhaité
• Les informations de connexion pour chaque nœud faisant partie de la réplication, chacune avec un numéro de nœud immuable.
• Liste de toutes les tables et séquences à répliquer dans le cadre d'un "ensemble de réplication".

Un exemple de script peut être trouvé dans la documentation officielle de Slony.

Une fois exécuté, slonik se connectera à tous les nœuds définis et créera le schéma Slony sur chacun. Lorsque les démons Slony sont lancés, ils effacent alors toutes les données des tables répliquées sur l'esclave (s'il y en a) et copient toutes les données du maître vers les esclaves. À partir de ce moment, les démons répliqueront en permanence les modifications enregistrées sur le maître vers tous les esclaves abonnés.

Configurations intelligentes

Alors que Slony est initialement un système de réplication maître vers plusieurs esclaves, et a été principalement utilisé de cette manière, il existe plusieurs autres fonctionnalités et utilisations intelligentes qui rendent Slony plus utile qu'une simple solution de réplication. La nature hautement personnalisable de Slony le rend pertinent pour une variété de situations pour les administrateurs qui peuvent sortir des sentiers battus.

Réplication en cascade

Les nœuds Slony peuvent être configurés pour une réplication en cascade sur une chaîne de différents nœuds. Si le nœud maître est connu pour supporter une charge extrêmement lourde, chaque esclave supplémentaire augmentera légèrement cette charge. Avec la réplication en cascade, un seul nœud esclave connecté au maître peut être configuré comme un « nœud de transfert », qui sera alors chargé d'envoyer des événements de réplication à plusieurs esclaves, en maintenant la charge sur le nœud maître au minimum.

Traitement des données sur un nœud esclave

Contrairement à la réplication intégrée de PostgreSQL, les nœuds esclaves ne sont pas réellement « en lecture seule », seules les tables qui sont répliquées sont verrouillées en « lecture seule ». Cela signifie que sur un nœud esclave, le traitement des données peut avoir lieu en créant de nouvelles tables ne faisant pas partie de la réplication pour héberger les données traitées. Les tables faisant partie de la réplication peuvent également avoir des index personnalisés créés en fonction des modèles d'accès qui peuvent différer de l'esclave et du maître.

Les tables en lecture seule sur les esclaves peuvent toujours avoir des fonctions personnalisées basées sur des déclencheurs exécutées sur les modifications de données, permettant une plus grande personnalisation avec les données.

Mises à niveau avec temps d'arrêt minimal

La mise à niveau des versions majeures de PostgreSQL peut prendre énormément de temps. En fonction de la taille des données et du nombre de tables, une mise à niveau incluant le processus d'analyse après la mise à niveau peut même prendre plusieurs jours. Étant donné que Slony peut répliquer des données entre des clusters PostgreSQL de différentes versions, il peut être utilisé pour configurer la réplication entre une version plus ancienne en tant que maître et une version plus récente en tant qu'esclave. Lorsque la mise à niveau doit avoir lieu, effectuez simplement une "commutation", en faisant de l'esclave le nouveau maître, et l'ancien maître devient l'esclave. Lorsque la mise à niveau est marquée comme un succès, désactivez le cluster de réplication Slony et fermez l'ancienne base de données.

Haute disponibilité avec maintenance fréquente du serveur

Comme le temps d'arrêt minimal pour les mises à niveau, la maintenance du serveur peut être effectuée facilement sans temps d'arrêt en effectuant une « basculement » entre deux nœuds ou plus, permettant à un esclave d'être redémarré avec des mises à jour/autre maintenance. Lorsque l'esclave revient en ligne, il se reconnecte au cluster de réplication et rattrape toutes les données répliquées. Les utilisateurs finaux qui se connectent à la base de données peuvent avoir de longues transactions interrompues, mais le temps d'arrêt lui-même serait de quelques secondes au moment du basculement, plutôt que le temps nécessaire pour redémarrer/mettre à jour l'hôte.

Envoi de journaux

Bien qu'il soit peu probable qu'il s'agisse d'une solution populaire, un esclave Slony peut être configuré comme un nœud de « livraison de journaux », où toutes les données qu'il reçoit via la réplication peuvent être écrites dans des fichiers SQL et expédiées. Cela peut être utilisé pour diverses raisons, telles que l'écriture sur un lecteur externe et le transport vers une base de données esclave manuellement, et non sur un réseau, compressé et conservé archivé pour de futures sauvegardes, ou même pour qu'un programme externe analyse les fichiers SQL et modifier le contenu.

Partage de données de plusieurs bases de données

Étant donné que n'importe quel nombre de tables peut être répliqué à volonté, les ensembles de réplication Slony peuvent être configurés pour partager des tables spécifiques entre les bases de données. Bien qu'un accès similaire puisse être obtenu via des wrappers de données étrangères (qui se sont améliorés dans les récentes versions de PostgreSQL), il peut être préférable d'utiliser Slony en fonction de l'utilisation. Si une grande quantité de données doit être récupérée d'un hôte à un autre, le fait que Slony réplique ces données signifie que les données nécessaires existeront déjà sur le nœud demandeur, ce qui élimine les longs temps de transfert.

Réplication retardée

Généralement, la réplication doit être aussi rapide que possible, mais il peut y avoir certains scénarios où un délai est souhaité. Le démon slon pour un nœud esclave peut être configuré avec un lag_interval, ce qui signifie qu'il ne recevra aucune donnée de réplication jusqu'à ce que les données soient anciennes comme spécifié. Cela peut être utile pour un accès rapide aux données perdues en cas de problème, par exemple si une ligne est supprimée, elle existera sur l'esclave pendant 1 heure pour une récupération rapide.

Ce qu'il faut savoir :

• Toute modification DDL des tables faisant partie de la réplication doit être exécutée à l'aide de la commande slonik execute.
• Toute table à répliquer doit avoir soit une clé primaire, soit un index UNIQUE sans colonnes nullables.
• Les données qui sont répliquées à partir du nœud maître sont répliquées après que toutes les données ont pu être générées de manière fonctionnelle. Cela signifie que si les données ont été générées à l'aide de quelque chose comme "random()", le nombre résultant est stocké et répliqué sur les esclaves, plutôt que "random()" exécuté à nouveau sur l'esclave renvoyant un résultat différent.
• L'ajout de la réplication Slony augmentera légèrement la charge du serveur. Bien qu'écrit de manière efficace, chaque table aura un déclencheur qui consigne chaque INSERT, UPDATE et DELETE dans une table Slony, attendez-vous à une augmentation de la charge du serveur d'environ 2 à 10 %, en fonction de la taille de la base de données et de la charge de travail.

Conseils et astuces :

• Les démons Slony peuvent s'exécuter sur n'importe quel hôte ayant accès à tous les autres hôtes, mais la configuration la plus performante consiste à faire fonctionner les démons sur les nœuds qu'ils gèrent. Par exemple, le démon maître s'exécutant sur le nœud maître, le démon esclave s'exécutant sur le nœud esclave.
• Si vous configurez un cluster de réplication avec une très grande quantité de données, la copie initiale peut prendre un certain temps, ce qui signifie que toutes les modifications qui se produisent depuis le lancement jusqu'à la fin de la copie peuvent nécessiter encore plus de temps pour rattraper et être synchronisées. . Cela peut être résolu soit en ajoutant quelques tables à la fois à la réplication (ce qui prend beaucoup de temps), soit en créant une copie du répertoire de données de la base de données maître sur l'esclave, puis en effectuant un "ensemble d'abonnement" avec l'option OMIT COPY définie sur vrai. Avec cette option, Slony supposera que la table esclave est identique à 100 % à la table maître, et ne l'effacera pas et ne copiera pas les données.
• Le meilleur scénario pour cela est de créer un Hot Standby à l'aide des outils intégrés pour PostgreSQL, et pendant une fenêtre de maintenance avec aucune connexion modifiant les données, mettre le standby en ligne en tant que maître, valider les correspondances de données entre les deux, lancer le cluster de réplication slony avec OMIT COPY =true, et enfin réactivez les connexions client. La configuration de la redondance d'UC peut prendre du temps, mais le processus n'aura pas d'impact négatif énorme sur les clients.

Communauté et documentation

La communauté de Slony se trouve dans les listes de diffusion, situées à http://lists.slony.info/mailman/listinfo/slony1-general, qui comprend également des archives.

La documentation est disponible sur le site officiel, http://slony.info/documentation/, et fournit une aide pour l'analyse des journaux et la spécification de la syntaxe pour l'interface avec slony.