 Installation de Slony-I
|
 
|
Définir les clusters
Slony-I
|
Afin de mettre en place une réplication Slony-I™, il est nécessaire de comprendre la terminologie utilisée :
Cluster ;
Noeud (« node ») ;
Ensemble de réplication (« replication set ») ;
Origine (« Origin »), Fournisseurs (« Providers ») et Abonnés (« Subscribers ») ;
Les démons slon ;
La commande slonik.
Il est également nécessaire de connaître quelques mots de russe :
slon signifie « éléphant » en russe ;
slony est le pluriel de slon, et désigne ainsi un groupe d'éléphants ;
slonik désigne un « petit éléphant ».
L'utilisation de ces termes dans Slony-I™ est un « coup de chapeau » à Vadim Mikheev qui est l'auteur du prototype rserv qui inspira une partie des algorithmes utilisé dans Slony-I™.
Selon Slony-I™, un « cluster » est ensemble nommé d'instances de bases de données PostgreSQL™. Une réplication a lieu entre ces bases.
Le nom du cluster est spécifié dans chaque script Slonik via la directive :
cluster name = quelque_chose;
Si le nom du cluster est plop, alors Slony-I™ crée, dans chaque instance du cluster, le schéma _plop.
Un nœud Slony-I™ est une base PostgreSQL™ nommée qui participe à la réplication.
Le nom du nœud est défini au début de chaque script Slonik, avec la directive :
NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
La ligne SLONIK ADMIN CONNINFO(7) précise les informations de connexion qui seront utilisées par la fonction libpq PQconnectdb().
Ainsi un cluster Slony-I™ se compose :
d'un nom de cluster ;
d'un ensemble de nœuds Slony-I™, qui disposent chacun d'un schéma portant le nom du cluster.
Un ensemble de réplication est défini comme un ensemble de tables et de séquences qui doivent être répliquées entre plusieurs nœuds dans un cluster Slony-I™.
Vous pouvez avoir plusieurs sets, et le « flux » de réplication n'est pas nécessairement identique pour tous les ensembles.
Chaque ensemble de réplication a un nœud d'origine, qui est le seul endroit où les applications sont autorisées à modifier les données répliquées. On peut aussi rencontrer le terme « nœud maître ». Il s'agit du nœud principal qui fournit les données.
Les autres nœuds du cluster s'abonnent à l'ensemble de réplication, ce qui indique qu'ils veulent recevoir les données.
Le nœud d'origine ne sera jamais considéré comme un « abonné » (on ignore ici le cas ou le cluster est restructuré et où l'origine est explicitement déplacée sur un autre nœud). Mais Slony-I™ supporte la notion d'abonnements en cascade, c'est-à-dire qu'un nœud qui est abonné à un ensemble de réplication, peut également se comporter comme un « fournisseur » du même ensemble de réplication pour d'autres nœuds du cluster.
Pour chaque nœud du cluster, il y a un processus slon(1) qui gère l'activité de réplication pour le nœud.
slon(1) est un programme implémenté en C qui traite les évènements de réplication. Il y a deux principaux types d'événements :
Les évènements de configuration
Ils se produisent en général lorsqu'un script slonik(1) est exécuté et qu'il modifie la configuration du cluster.
Les événements SYNC
Les mises à jour des tables répliquées sont regroupées dans des événements SYNC ; ces groupes de transactions sont appliquées ensemble sur les nœuds abonnés.
La commande slonik(1) traite des scripts écrits dans un « langage spécial » qui est utilisé pour soumettre des événements de configuration du cluster Slony-I™. Cela comprend des actions telles que l'ajout et la suppression de nœuds, la modification des voies de communications, l'ajout ou la suppression d'abonnements.