3. Prérequis système

À ce jour, Slony-I™ nécessite d'être compilé depuis ses sources sur votre site de la même façon que PostgreSQL™.

Afin de compiler Slony-I™, vous avez besoin des outils suivants :

Assurez-vous de disposer de suffisamment d'espace libre. Vous aurez besoin d'environ 5 Mo pour la distribution des sources pendant la compilation et l'installation.

Vous pouvez obtenir les sources de Slony-I™ à partir de l'url http://main.slony.info/downloads/.

Les bases de données PostgreSQL™ peuvent être créés avec plusieurs types d'encodage, défini par la commande Slony-I™ createdb --encoding=$ENCODING databasename. Cela suppose que les bases de données utilisent des encodages identiques.

Des encodages « très proches » peuvent ne provoquer aucun problème. Par exemple, si le système d'origine utilise LATIN1, un abonné SQL_ASCII et un autre abonné UNICODE, et que votre application ne dépasse pas les conditions limites de frontière entre ces différents encodages, vous pouvez ne jamais rencontrer de problème.

Notez que si l'encodage client (configuré soit dans postgresql.conf, soit par le paramètre client_encoding, soit par la commande psql \encoding, soit sous psql par la variable interne ENCODING) diffère de l'encodage serveur, cette différence peut conduire Slony-I™ à être incapable de répliquer les caractères supportés par l'encodage client et non pas par celui du serveur.

Tous les serveurs utilisés dans le cluster de réplication doivent avoir leurs horloges internes synchronisées. Cela garantie que slon(1) ne génère pas d'erreur indiquant qu'un abonné est en avance par rapport à son fournisseur pendant la réplication. L'analyse des journaux applicatifs sur des serveurs ayant une idée différente du temps est source de confusion et de frustration. Il est recommandé de faire tourner le démon ntpd sur tous les nœuds, où les nœuds abonnés utilisent le nœud « maître » comme serveur de temps.

Il est possible pour Slony-I™ de fonctionner avec des différences de temps, mais avoir des systèmes « synchonisés » est normalement très important pour les applications distribuées.

Voir www.ntp.org pour plus de détails au sujet de NTP (Network Time Protocol).

Quelques utilisateurs ont reporté des problèmes lors de l'utilisation de certaines zones de temps, non reconnues par PostgreSQL™.

Dans tous les cas, ce qui semble être communément une « bonne pratique » avec Slony-I™ (et, pour nous PostgreSQL™) est d'utiliser pour l'utilisateur postmaster et/ou l'utilisateur sous lequel slon tourne TZ=UTC ou TZ=GMT. Ces fuseaux horaires sont supportées de manière sûres par n'importe quelle plate-forme, ont le mérite par rapport à des fuseaux horaires « locaux » de ne jamais diverger par rapport aux changements heures été-hiver.

Il est nécessaire que les nœuds devant être répliqués entre eux aient des communications réseau bidirectionnelles entre les instances PostgreSQL™. Ainsi, si le nœud B est en train de répliquer les données du nœud A, il est nécessaire qu'il y ait un chemin de A vers B et de B vers A. Il est recommandé que, dans la mesure du possible, tous les nœuds du cluster Slony-I™ permettent ce type de communication bidirectionnelle de n'importe quel nœud du cluster vers n'importe quel autre nœud du cluster.

Pour faciliter la configuration, les adresses réseau devraient être idéalement identiques à travers tous les nœuds. SLONIK STORE PATH(7) leur permet d'être différentes, mais le maintien de ces différents chemins pointant sur le même serveur peut devenir problématique.

Un contournement possible de cela, dans les environnements où les règles de parefeu sont particulièrement difficiles à implémenter, peut être d'établir des tunnels SSH crés sur chaque hôte permettant un accès distant au travers d'une adresse IP locale telle 127.0.0.1, en utilisant un port différent pour chaque destination.

Notez que slonik et les instances slon ne nécessitent pas de connexions ou de protocoles spéciaux pour communiquer ensemble ; ils nécessitent simplement un accès aux bases de données PostgreSQL™, en s'y connectant comme « super utilisateur » capable de mettre à jour les tables du système.

Une conséquence d'un tel modèle de communication est que le réseau entier dans lequel un cluster Slony-I™ opère doit être sécurisé. Si une des bases de données du cluster ne peut être considérée comme sécurisée, cela représente une vulnérabilité pour tout le cluster. De la même manière que dans un système « peer-to-peer », n'importe quel hôte est capable d'envoyer un évènement de réplication affectant tout le cluster. Ainsi, les règles de sécurité du cluster doivent être celles du nœud le plus faible. Faire tourner Slony-I™ à une localisation qui ne peut être considérée comme sécurisée compromet la sécurité du cluster dans son ensemble.

Une nouvelle fonctionnalité de Slony-I™ version 1.1 est que les mises à jour pour un jeu de réplication particulier peuvent être sérialisées via le schéma log shipping. La donnée enregistrée dans sl_log_1 et sl_log_2 est aussi écrite dans des journaux de transactions sur disque. Ces fichiers peuvent ensuite être transmis de n'importe quelle manière via scp, FTP, écrits sur DVD-ROM puis adressés par messagerie ou, pourquoi pas, en les enregistrant sur une « clé USB » permettant l'équivalence d'une transmission de diagramme IP on avian carriers - RFC 1149. Quelque soit le mécanisme de transmission, cela permet un seul accès de communication tel que les abonnés utilisant le log shipping ne nécessitent aucun accès aux autres nœuds Slony-I™.