Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
449 lines (385 sloc) 17.6 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="introduction">
<title>Introduction à &slony1;</title>
<indexterm><primary>introduction à &slony1;</primary></indexterm>
<sect2> <title>Qu'est-ce que &slony1;&nbsp;?</title>
<para>
&slony1; est un système de réplication entre <quote>un maître et plusieurs
esclaves</quote> qui supporte les cascades et la promotion d'un esclave en
maître. Le schéma directeur du développement de &slony1; est la création
d'un système maître-esclave qui inclue les fonctionnalités nécessaires
pour répliquer de grandes bases de données avec un nombre raisonnable
d'esclaves. <quote>Raisonnable,</quote> dans ce contexte signifie une
douzaine de serveurs. Si le nombre de serveurs évolue au-delà de cette
limite, le coût des communications augmente de manière prohibitive et le
bénéfice d'avoir plusieurs serveurs diminue.
</para>
<para>
Voir la section <xref linkend="slonylistenercosts"/> pour une analyse plus
détaillée des coûts associés à l'augmentation du nombre de n&oelig;uds.
</para>
<para>
&slony1; est un système conçu pour les centres de données et pour les sites
de sauvegarde, où le fonctionnement des opérations est que tous les
n&oelig;uds sont disponibles en permanence, et où tous les n&oelig;uds peuvent
être sécurisés. Si vous avez des n&oelig;uds qui risquent régulièrement d'être
coupés du réseau, ou si la sécurité de vos n&oelig;uds ne peut pas être
garantie, &slony1; n'est probablement pas la solution de réplication idéale
pour vous.
</para>
<para>
Voici notamment quelques exemples de cas où &slony1; ne sera probablement
pas adapté&nbsp;:
<itemizedlist>
<listitem>
<para>
Les sites dont la connectivité est <quote>instable</quote>.
</para>
</listitem>
<listitem>
<para>
La réplication entre des n&oelig;uds qui ne sont pas toujours
interconnectés.
</para>
</listitem>
<listitem>
<para>
Répliquer une base de tarification à partir d'un serveur central vers
l'équipe commerciale qui s'y connecte périodiquement pour en extraire
les mise à jour.
</para>
</listitem>
<listitem>
<para>
Les sites où les changements de configuration sont faits de manière
hasardeuse.
</para>
</listitem>
<listitem>
<para>
Une situation d'<quote>hébergement web</quote> où les utilisateurs
peuvent de manière indépendante et arbitraire changer les schémas des
données.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Il existe une extension du <link linkend="logshipping">log shipping par
fichier</link> qui permet de regrouper les mises à jour dans des fichiers.
Ainsi, les fichiers de mises à jours peuvent être distribués par différents
moyens sans avoir à attendre d'accusé de réception entre le n&oelig;ud
fournisseur et les n&oelig;uds qui sont abonnés au <quote>log
shipping</quote>. Les n&oelig;uds abonnés au <quote>log shipping</quote>
n'augmentent pas les coûts de communication entre les n&oelig;uds &slony1;.
</para>
<para>
Mais &slony1;, ayant une seule origine par ensemble de données répliqué,
n'est pas adapté pour effectuer de la réplication
<emphasis>réellement</emphasis> asynchrone et multi-directionnelle. Pour
celles et ceux qui recherchent une <quote>réplication asynchrone
multi-maîtres avec résolution des conflits</quote> telle que ce que fournit
<productname>Lotus <trademark>Notes</trademark></productname> ou les
protocoles de <quote>synchronisation</quote> présents sur les systèmes PalmOS,
il est nécessaire de se tourner vers d'autres logiciels.
</para>
<para>
Il existe également d'autres modèles de réplication qui ne sont pas sans
avantages mais qui permettent des scénarios de réplication
<emphasis>différents</emphasis> de ce que &slony1; propose.
</para>
</sect2>
<sect2>
<title>Pourquoi proposer encore un autre système de réplication&nbsp;?</title>
<para>
&slony1; est né de l'idée de créer un système de réplication qui ne soit pas
lié à une version spécifique de &postgres;, pour qu'il puisse être lancé et
arrêté sur une base existante sans besoin d'effectuer un cycle d'export/import
des données.
</para>
</sect2>
<sect2>
<title>Ce que &slony1; n'est pas</title>
<itemizedlist>
<listitem>
<para>
&slony1; n'est pas un système de gestion de réseau.
</para>
</listitem>
<listitem>
<para>
&slony1; n'a aucune fonctionnalité permettant de détecter la perte d'un
n&oelig;ud, et ne peut pas transformer automatiquement un n&oelig;ud en
maître ou esclave.
</para>
<para>
Il est toutefois possible que vous ayez besoin de ce type de
mécanisme&nbsp;; cela vous demandera de combiner des outils réseau qui
évaluent <emphasis>selon vos critères</emphasis> quels n&oelig;uds vous
considérez comme <quote>actifs</quote> et quels n&oelig;uds vous
considérez comme <quote>morts</quote>, ainsi qu'une politique locale pour
déterminer ce qu'il faut faire dans telle ou telle circonstance. &slony1;
ne vous impose aucune politique.
</para>
</listitem>
<listitem>
<para>
&slony1; n'est pas un système de réplication multi-maîtres&nbsp;; ce
n'est pas un gestionnaire de connexions, et il ne vous apportera pas
le café et les croissants le matin.
</para>
</listitem>
</itemizedlist>
<para>
Ceci étant dit, il existe des outils à votre disposition pour simplifier
certaines de ces opérations, et il existe un projet en cours de développement,
<productname>Slony-II</productname>, pour fournir des mécanismes
<quote>multi-maîtres</quote>. Mais cela constitue un projet différent et
séparé, implémenté de façon très différente de &slony1;, et les attentes à
propos de &slony1; ne doivent pas se baser sur des espoirs placés dans de
futurs projets.
</para>
</sect2>
<sect2>
<title>Pourquoi &slony1; ne fait pas de bascule automatique en cas de panne
&nbsp;fail over&nbsp;»)&nbsp;?</title>
<para>
Déterminer si un n&oelig;ud est en <quote>échec</quote> est de la
responsabilité d'un logiciel de surveillance de réseau, pas de &slony1;.
La configuration, les mécanismes de bascule et les politiques de reprise sur
panne sont différents selon les sites. Par exemple, la surveillance avec des
NIC redondants et les mécanismes de haute-disponibilité intelligents qui
garantissent un changement d'adresse réseau à la volée sans conflit et une
isolation du n&oelig;ud <quote>en échec</quote>, dépendent de la configuration
du réseau, des choix matériels et de la combinaison entre les logiciels et les
appareils utilisés. Tout cela appartient clairement au domaine de la gestion
de réseau, pas à celui de &slony1;.
</para>
<para>
De plus, choisir comment se comporter selon l'<quote>état</quote> du cluster
concerne la politique commerciale locale, en particulier si on considère
qu'une <link linkend="stmtfailover"><command>bascule en cas de
panne</command></link> («&nbsp;fail over&nbsp;») nécessite d'isoler le
n&oelig;ud en échec. Si &slony1; imposait une politique de bascule en cas de
panne aux utilisateurs, cela entrerait parfois en conflit avec des intérêts
commerciaux et &slony1; serait parfois une solution inadaptée.
</para>
<para>
En conséquence, laissons &slony1; faire ce qu'il fait de mieux&nbsp;:
fournir un service de réplication de bases de données.
</para>
</sect2>
<sect2>
<title>Limitations actuelles</title>
<indexterm><primary>limitations de &slony1;</primary></indexterm>
<para>
&slony1; ne propage pas les changements du schéma de données et ne réplique
non plus les objets volumineux (les «&nbsp;large objects&nbsp;»). Il y a une
raison unique et commune à ces limitations&nbsp;: &slony1; collecte les mises
à jours en utilisant des triggers, et ni les changements de schéma ni les
opérations sur les «&nbsp;large objects&nbsp;», ni les requêtes
<command>TRUNCATE</command> ne sont capables de déclencher des triggers pour
informer &slony1; lorsque ce genre de modifications a lieu. Ainsi les seuls
objets que &slony1; peut répliquer sont les tables et les séquences.
</para>
<para>
Notons que l'<emphasis>utilisation</emphasis> de triggers implique quelques
<emphasis>retouches</emphasis> supplémentaires sur ces triggers. Sur le
n&oelig;ud <quote>origine</quote> pour chaque table répliquée, on ajoute un
trigger supplémentaire qui lance la procédure stockée <xref
linkend="function.logtrigger"/>. Sur chaque n&oelig;ud abonné, les tables
sont complétées avec un trigger qui lance la fonction <xref
linkend="function.denyaccess"/>&nbsp;; cette fonction empêche toute mise à
jour sur les tables répliquées à l'exception de celles effectuées par le
processus <xref linkend="slon"/>. De plus, tous les
<emphasis>autres</emphasis> triggers et règles sur les tables répliquées sont
<emphasis>supprimés</emphasis> sur les n&oelig;uds abonnés&nbsp;; ceci est
réalisé en faisant pointer ces tables, dans le catalogue système, vers les
index des clefs primaires plutôt que sur la table elle-même. Cela s'apparente
à une <quote>corruption</quote> du dictionnaire de données, et cela explique
pourquoi on ne peut pas utiliser directement <application>pg_dump</application>
pour exporter le schéma sur les n&oelig;uds abonnés.
</para>
<para>
Il est possible de propager d'autres types de modifications des bases avec
&slony1;, notamment les ordres DDL si vous les effectuez via la fonction
de <application>slonik</application> nommée <xref
linkend="stmtddlscript"/>. Ceci ne peut pas se faire
<quote>automatiquement</quote>&nbsp;; en tant qu'administrateur de base de
données, vous devez superviser les scripts SQL DDL et les soumettre via
<xref linkend="stmtddlscript"/> car il existe un certain nombre de pièges
à éviter concernant les <link linkend="ddlchanges"></link>.
</para>
<para>
Si vous ne pouvez pas superviser ces modifications, vous devrez peut-être
envisager l'utilisation du mécanisme <acronym>PITR</acronym> (Point In
Time Recovery) de &postgres; (version 8.x), avec lequel les journaux de
transactions sont répliqués sur des n&oelig;uds distants. Malheureusement,
cette solution a deux limitations majeures&nbsp;:
<itemizedlist>
<listitem>
<para>
Le mécanisme PITR réplique <emphasis>tous</emphasis> les changements
de <emphasis>toutes</emphasis> les bases de données&nbsp;; vous ne
pouvez pas exclure les données qui ne sont pas intéressantes&nbsp;;
</para>
</listitem>
<listitem>
<para>
Un réplicat PITR reste endormi jusqu'à ce que les journaux soient
appliqués et que la base soit relancée. Vous ne pouvez pas utiliser la
base et appliquer les mises à jour simultanément. Cela revient à avoir
un <quote>serveur de secours</quote> que vous ne pouvez utiliser sans
stopper la réplication.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
<sect2>
<title>Modèles de réplication</title>
<indexterm><primary>modèles de réplication</primary></indexterm>
<para>
Il existe beaucoup de modèles de réplication différents&nbsp;; il n'existe
pas une seul système de réplication qui puisse répondre à toutes les attentes
de tous les utilisateurs.
</para>
<para>
&slony1; implémente un modèle particulier, la réplication asynchrone, en
utilisant des triggers pour collecter les mises à jour sur les tables, sur
une <quote>origine</quote> unique, puis réplique ces mises à jour sur de
multiples <quote>abonnés</quote>, y compris les abonnés en cascade.
</para>
<para>
Il existe de de nombreux autres modèles de réplication qui sont
<emphasis>différents</emphasis> de celui-ci&nbsp;; il est important de
souligner que d'autres approches sont possibles. &slony1; n'est certainement
pas la seule approche et, pour certaines applications, ce n'est
<emphasis>pas</emphasis> la meilleur approche.
</para>
<itemizedlist>
<listitem>
<para>
Réplication synchrone entre une origine unique et plusieurs abonnés
</para>
<para>
Dans un système synchrone, les mises à jour ne peuvent pas être validées
sur l'origine tant qu'elles n'ont pas été acceptées par les n&oelig;uds
abonnés. Ceci renforce la sécurité en évitant les risques de répudiation
car les mises à jour ne sont pas effectuées sans avoir été confirmées
ailleurs. Malheureusement, la nécessité d'appliquer simultanément les
changements sur de multiples emplacements constitue un frein sur les
performances.
</para>
<para>
Cette approche est similaire au modèle basé sur la validation en deux
phases (NdT&nbsp;: «&nbsp;two phase commit&nbsp;») implémenté dans le
protocole de gestion de transaction XA.
</para>
</listitem>
<listitem>
<para>
Réplication synchrone entre plusieurs origines et plusieurs abonnés
</para>
<para>
Ceci est le modèle implémenté dans l'hypothétique système
<productname>Slony-II</productname>. Les systèmes de réplication synchrones
<quote>souffrent</quote> de problèmes de performances car les mises à jour
doivent être acceptées par tous les n&oelig;uds avant d'être appliquées.
</para>
<para>
En pratique, il est inutile de faire fonctionner un système de réplication
synchrone sur un réseau longue distance (WAN).
</para>
</listitem>
<listitem>
<para>
Réplication asynchrone multi-maîtres avec résolution/prévention des conflits
</para>
<para>
Le système de réplication le plus répandu utilisant ce modèle est
probablement le système <productname>PalmOS HotSync</productname>.
<trademark>Lotus Notes</trademark> fournit également un système de
réplication qui fonctionne de la même manière.
</para>
<para>
Le <quote>problème</quote> caractéristique avec ce style de réplication
est que des conflits peuvent apparaître lorsque des utilisateurs mettent
à jour le même enregistrement de différentes manières sur différents
n&oelig;uds.
</para>
<para>
Dans le cas de <productname>HotSync</productname>, si un conflit est
provoqué par la mise à jour simultanée d'un même enregistrement, la
<quote>résolution</quote> se résume à créer un deuxième enregistrement
pour témoigner des deux mises à jours, puis laisser l'utilisateur
résoudre le conflit à la main.
</para>
<para>
Certains systèmes de réplication multi-maîtres asynchrones essaient de
résoudre les conflits en trouvant des moyens pour appliquer partiellement
les mises à jour. Par exemple, dans le cas de la mise à jour d'un adresse,
si un autre utilisateur tente de mettre à jour le nom de la rue, alors le
système de résolution des conflits essaie d'appliquer les mises à jour
dans un ordre non conflictuel. On peut considérer cette méthode comme
une forme de <quote>partitionnement de table</quote> où l'on considère la
base de données comme une table constituée de plusieurs <quote>sous
tables</quote>.
</para>
<para>
Les systèmes de résolution de conflit nécessite presque toujours une
bonne connaissance du domaine de l'application, ce qui implique qu'ils
ne peuvent résoudre des conflits automatiquement uniquement si vous leur
indiquez une politique de résolution. S'ils rencontrent un conflit et
qu'il n'existe pas de politique définie, la réplication s'arrête jusqu'à
ce que quelqu'un résolve le conflit à la main.
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1 id="slonylistenercosts">
<title> Coûts de communications avec &slony1;</title>
<para>
Le coût de communications augmente de façon quadratique dans plusieurs
directions lorsque le nombre de n&oelig;uds de réplication du cluster
grandit. Notons les relations suivantes&nbsp;:
<itemizedlist>
<listitem>
<para>
Il est nécessaire que les entrées de la table <xref
linkend="table.sl-listen"/> autorisent toutes les connexions entre tous
les n&oelig;uds. Dans la plupart des cas, cela n'est pas très
volumineux mais cela signifie tout de même qu'il faut définir n(n-1)
voies de communications.
</para>
</listitem>
<listitem>
<para>
Chaque événement SYNC appliqué doit être annoncé à tous les n&oelig;uds
participants à la réplication de l'ensemble de données, afin que chaque
n&oelig;ud sache qu'il est possible de purger les données des tables
&sllog1; et &sllog2;,
car n'importe quel n&oelig;ud <quote>fournisseur</quote> peut
potentiellement devenir un <quote>maître</quote> à tout moment. On peut
s'attendre à que les messages SYNC ne soient propagés que sur n/2
n&oelig;uds pour atteindre leur destination&nbsp;; ce qui implique que
chaque SYNC est transmis n(n/2) fois. À nouveau, cela montre que la
croissance des coûts de communication est quadratique selon le nombre
de n&oelig;uds dans le cluster.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Tout ceci prouve qu'il n'est pas judicieux de bâtir un grand réseau de
communication pour supporter un système de réplication contenant beaucoup
de n&oelig;uds. Jusqu'à une demi-douzaine de n&oelig;uds, cela semble
raisonnable&nbsp;; à chaque fois que le nombre de n&oelig;uds double, les
temps de communications quadruplent.
</para>
</sect1>