|
Coûts de communications
avec Slony-I
|
Slony-I™ est un système de réplication entre « un maître et plusieurs esclaves » qui supporte les cascades et la promotion d'un esclave en maître. Le schéma directeur du développement de Slony-I™ 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. « Raisonnable, » 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.
Voir la section Section 2, « Coûts de communications avec Slony-I » pour une analyse plus détaillée des coûts associés à l'augmentation du nombre de nœuds.
Slony-I™ 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œuds sont disponibles en permanence, et où tous les nœuds peuvent être sécurisés. Si vous avez des nœuds qui risquent régulièrement d'être coupés du réseau, ou si la sécurité de vos nœuds ne peut pas être garantie, Slony-I™ n'est probablement pas la solution de réplication idéale pour vous.
Voici notamment quelques exemples de cas où Slony-I™ ne sera probablement pas adapté :
Les sites dont la connectivité est « instable ».
La réplication entre des nœuds qui ne sont pas toujours interconnectés.
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.
Les sites où les changements de configuration sont faits de manière hasardeuse.
Une situation d'« hébergement web » où les utilisateurs peuvent de manière indépendante et arbitraire changer les schémas des données.
Il existe une extension du log shipping par fichier 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œud fournisseur et les nœuds qui sont abonnés au « log shipping ». Les nœuds abonnés au « log shipping » n'augmentent pas les coûts de communication entre les nœuds Slony-I™.
Mais Slony-I™, ayant une seule origine par ensemble de données répliqué, n'est pas adapté pour effectuer de la réplication réellement asynchrone et multi-directionnelle. Pour celles et ceux qui recherchent une « réplication asynchrone multi-maîtres avec résolution des conflits » telle que ce que fournit Lotus Notes™™ ou les protocoles de « synchronisation » présents sur les systèmes PalmOS, il est nécessaire de se tourner vers d'autres logiciels.
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 différents de ce que Slony-I™ propose.
Slony-I™ 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 PostgreSQL™, 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.
Slony-I™ n'est pas un système de gestion de réseau.
Slony-I™ n'a aucune fonctionnalité permettant de détecter la perte d'un nœud, et ne peut pas transformer automatiquement un nœud en maître ou esclave.
Il est toutefois possible que vous ayez besoin de ce type de mécanisme ; cela vous demandera de combiner des outils réseau qui évaluent selon vos critères quels nœuds vous considérez comme « actifs » et quels nœuds vous considérez comme « morts », ainsi qu'une politique locale pour déterminer ce qu'il faut faire dans telle ou telle circonstance. Slony-I™ ne vous impose aucune politique.
Slony-I™ n'est pas un système de réplication multi-maîtres ; ce n'est pas un gestionnaire de connexions, et il ne vous apportera pas le café et les croissants le matin.
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, Slony-II™, pour fournir des mécanismes « multi-maîtres ». Mais cela constitue un projet différent et séparé, implémenté de façon très différente de Slony-I™, et les attentes à propos de Slony-I™ ne doivent pas se baser sur des espoirs placés dans de futurs projets.
Déterminer si un nœud est en « échec » est de la responsabilité d'un logiciel de surveillance de réseau, pas de Slony-I™. 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œud « en échec », 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 Slony-I™.
De plus, choisir comment se comporter selon l'« état » du cluster concerne la politique commerciale locale, en particulier si on considère qu'une bascule en cas de panne (« fail over ») nécessite d'isoler le nœud en échec. Si Slony-I™ imposait une politique de bascule en cas de panne aux utilisateurs, cela entrerait parfois en conflit avec des intérêts commerciaux et Slony-I™ serait parfois une solution inadaptée.
En conséquence, laissons Slony-I™ faire ce qu'il fait de mieux : fournir un service de réplication de bases de données.
Slony-I™ ne propage pas les changements du schéma de données et ne réplique non plus les objets volumineux (les « large objects »). Il y a une raison unique et commune à ces limitations : Slony-I™ collecte les mises à jours en utilisant des triggers, et ni les changements de schéma ni les opérations sur les « large objects », ni les requêtes TRUNCATE ne sont capables de déclencher des triggers pour informer Slony-I™ lorsque ce genre de modifications a lieu. Ainsi les seuls objets que Slony-I™ peut répliquer sont les tables et les séquences.
Notons que l'utilisation de triggers implique quelques retouches supplémentaires sur ces triggers. Sur le nœud « origine » pour chaque table répliquée, on ajoute un trigger supplémentaire qui lance la procédure stockée schemadoclogtrigger( ). Sur chaque nœud abonné, les tables sont complétées avec un trigger qui lance la fonction schemadocdenyaccess( ) ; cette fonction empêche toute mise à jour sur les tables répliquées à l'exception de celles effectuées par le processus slon(1). De plus, tous les autres triggers et règles sur les tables répliquées sont supprimés sur les nœuds abonnés. Sur les versions de Slony-I™ antérieures à la 2.0, cela se fait en les pointant, dans la table système, vers l'index de la clé primaire au lieu de la table elle-même, ce qui représente une « corruption » du dictionnaire des données et qui explique pourquoi vous ne devez pas utiliser directement pg_dump pour sauvegarder les schémas sur les abonnés. En version 2.0, cette fonctionnalité est gérée via une fonctionnalité native de PostgreSQL™. Du coup, avec Slony-I™ 2.0+, pg_dump doit fonctionner correctement.
Il est possible de propager d'autres types de modifications des bases avec Slony-I™, notamment les ordres DDL si vous les effectuez via la fonction de slonik nommée SLONIK EXECUTE SCRIPT(7). Ceci ne peut pas se faire « automatiquement » ; en tant qu'administrateur de base de données, vous devez superviser les scripts SQL DDL et les soumettre via SLONIK EXECUTE SCRIPT(7) car il existe un certain nombre de pièges à éviter concernant les ???.
Si vous ne pouvez pas superviser ces modifications, vous devrez peut-être envisager l'utilisation du mécanisme PITR (Point In Time Recovery) de PostgreSQL™ (version 8.x), avec lequel les journaux de transactions sont répliqués sur des nœuds distants. Malheureusement, cette solution a deux limitations majeures :
Le mécanisme PITR réplique tous les changements de toutes les bases de données ; vous ne pouvez pas exclure les données qui ne sont pas intéressantes ;
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 « serveur de secours » que vous ne pouvez utiliser sans stopper la réplication.
Slony-I™ ne détermine pas automatiquement les séquences devant être répliquées ; vous devez les ajouter explicitement en utilisant SLONIK SET ADD SEQUENCE(7).
Il existe beaucoup de modèles de réplication différents ; il n'existe pas une seul système de réplication qui puisse répondre à toutes les attentes de tous les utilisateurs.
Slony-I™ implémente un modèle particulier, la réplication asynchrone, en utilisant des triggers pour collecter les mises à jour sur les tables, sur une « origine » unique, puis réplique ces mises à jour sur de multiples « abonnés », y compris les abonnés en cascade.
Il existe de de nombreux autres modèles de réplication qui sont différents de celui-ci ; il est important de souligner que d'autres approches sont possibles. Slony-I™ n'est certainement pas la seule approche et, pour certaines applications, ce n'est pas la meilleur approche.
Réplication synchrone entre une origine unique et plusieurs abonnés
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œ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.
Cette approche est similaire au modèle basé sur la validation en deux phases (NdT : « two phase commit ») implémenté dans le protocole de gestion de transaction XA.
Réplication synchrone entre plusieurs origines et plusieurs abonnés
Ceci est le modèle implémenté dans l'hypothétique système Slony-II™. Les systèmes de réplication synchrones « souffrent » de problèmes de performances car les mises à jour doivent être acceptées par tous les nœuds avant d'être appliquées.
En pratique, il est inutile de faire fonctionner un système de réplication synchrone sur un réseau longue distance (WAN).
Réplication asynchrone multi-maîtres avec résolution/prévention des conflits
Le système de réplication le plus répandu utilisant ce modèle est probablement le système PalmOS HotSync™. Lotus Notes™ fournit également un système de réplication qui fonctionne de la même manière.
Le « problème » 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œuds.
Dans le cas de HotSync™, si un conflit est provoqué par la mise à jour simultanée d'un même enregistrement, la « résolution » 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.
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 « partitionnement de table » où l'on considère la base de données comme une table constituée de plusieurs « sous tables ».
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.