Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
branch: master
Fetching contributors…

Cannot retrieve contributors at this time

358 lines (306 sloc) 14.363 kb
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="requirements">
<title>Prérequis système</title>
<para>
N'importe quelle plate-forme capable de faire tourner &postgres; devrait
être capable, en principe, de faire fonctionner &slony1;.
</para>
<indexterm><primary>plates-formes sur lesquelles &slony1; fonctionne</primary></indexterm>
<para>
Les plates-formes ayant été testées sont FreeBSD-4X-i368,
FreeBSD-5X-i386, FreeBSD-5X-alpha, OS-X-10.3,
Linux-2.4X-i386 Linux-2.6X-i386 Linux-2.6X-amd64,
<trademark>Solaris</trademark>-2.8-SPARC,
<trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1 et 5.3,
OpenBSD-3.5-sparc64 et &windows; 2000, XP et 2003 (32 bit). Il y a
suffisamment de diversité parmi ces plateformes que rien ne devrait
empêcher &slony1; de s'exécuter sur d'autres plateformes similaires.
</para>
<sect2>
<title>Dépendances logicielles</title>
<indexterm><primary>dépendances logicielles</primary></indexterm>
<para>
À ce jour, &slony1; nécessite d'être compilé depuis ses sources sur votre
site <emphasis>de la même façon que &postgres;</emphasis>.
</para>
<para>
Afin de compiler &slony1;, vous avez besoin des outils suivants&nbsp;:
<itemizedlist>
<listitem>
<para>
GNU make. Les autres programmes make ne fonctionnent pas. GNU make est
souvent installé sous le nom de <command>gmake</command>, qui sera
référencé sous ce nom tout au long de ce document. (Sur les systèmes
linux, GNU make est le make par defaut, et se nomme
<command>make</command>) Pour tester si votre make est GNU make, entrez
<command>make version</command>. La version 3.76 ou supérieure
convient&nbsp;; les versions antérieures ne conviennent pas.
</para>
</listitem>
<listitem>
<para>
Vous avez besoin du compilateur C ISO/ANSI. Les versions récentes de
<application>GCC</application> fonctionnent.
</para>
</listitem>
<listitem>
<para>
Vous avez également besoin d'une version <emphasis>source</emphasis>
récente de &postgres;. &slony1; dépend du support des schémas, ce qui
nécessite au minimum une version 7.3.3 de &postgres; pour pouvoir
compiler et utiliser &slony1;.
</para>
<para>
Les versions antérieures de &postgres; <emphasis>ne sont pas</emphasis>
supportées, mais notez qu'un utilisateur a réussi à <quote>forcer</quote>
l'utilisation de &slony1; dans le cadre d'une migration d'une version
7.2 vers une version 7.4&nbsp;; voir les <link linkend="v72upgrade">notes
sur &postgres; 7.2</link>.
</para>
<para>
Les versions de &postgres; antérieures à la 7.4.8 peuvent rencontrer
une requête sans fin conduisant à un problème de <link
linkend="dupkey"><quote>duplicate keys</quote></link> (clés dupliquées),
vous devrez alors envisager une mise à jour pour éviter ce type d'erreur.
</para>
<para>
Si vous utiliser une version de &postgres; antérieure à la version 8.0,
vous devez vous assurer que les fichiers d'en-tête de serveur sont
installés. Si vous installez depuis les sources, cela se fait par la
commande <command>make install-all-headers</command>. Sinon, vous
rencontrerez le problème <link linkend="missingheaders">missing headers
for libpqserver</link> (en-têtes manquants pour libpqserver), comme
décrit dans la FAQ.
</para>
<para>
Si vous utilisez les versions 8.1.0 à 8.1.3, un bogue (corrigé en
8.1.4) empêche la fonction <xref linkend="stmtupdatefunctions"/>
de s'exécuter correctement. Pour plus de détails, voir
<xref linkend="faq" />, <link linkend="pg81funs">&postgres;
8.1.[0-3]</link>.
</para>
<para>
Certaines versions de &postgres; ne sont pas compatibles avec certaines
versions de &slony1;. Voir <xref linkend="installation"/> pour plus de
détails.
</para>
</listitem>
<listitem>
<para>
Les packages GNU peuvent être inclus dans le packaging standard de
votre système d'exploitation ou doivent être recherchés sur votre
miroir local GNU (voir <ulink url="http://www.gnu.org/order/ftp.html">
http://www.gnu.org/order/ftp.html</ulink> pour une liste) ou
<ulink url="ftp://ftp.gnu.org/gnu">ftp://ftp.gnu.org/gnu</ulink>).
</para>
</listitem>
<listitem>
<para>
Si vous devez obtenir les sources &postgres;, vous pouvez les
télécharger depuis votre miroir &postgres; favori. Voir <ulink
url="http://www.postgresql.org/mirrors-www.html">
http://www.postgresql.org/mirrors-www.html</ulink> pour une liste.
</para>
</listitem>
<listitem>
<para>
Cette documentation est écrite en SGML avec <ulink
url="http://docbook.com/">DocBook</ulink> et peut être traduite dans
de nombreux formats incluant le HTML, le RTF et le PDF en utilisant
des outils <ulink url="http://docbook.sourceforge.net/">dans le dépôt
DocBook</ulink> avec <ulink
url="http://openjade.sourceforge.net/">OpenJade</ulink>.
</para>
</listitem>
<listitem>
<para>
Sous &windows;, vous aurez aussi besoin de la boîte à outils <ulink
url="http://www.postgresql.org/docs/faqs.FAQ_MINGW.html">MinGW/
Msys</ulink> pour compiler les versions 8.0 et supérieures de
&postgres;. De plus, vous devez installer <ulink
url="http://sourceware.org/pthreads-win32/">pthreads-win32 2.x</ulink>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Assurez-vous de disposer de suffisamment d'espace libre. Vous aurez besoin
d'environ 5&nbsp;Mo pour la distribution des sources pendant la compilation
et l'installation.
</para>
<note>
<para>
À partir de la version 1.1 de &slony1;, il est possible de compiler &slony1;
séparemment de &postgres;, rendant libres les distributions
<productname>Linux</productname> et
<productname>FreeBSD</productname> d'inclure des packages binaires
précompilés pour &slony1;. Si de tels packages ne sont pas disponibles,
vous devez vous préparer à compiler &slony1; par vous-même.
</para>
</note>
</sect2>
<sect2>
<title>Obtenir les sources de &slony1;</title>
<indexterm><primary>téléchargement des sources de &slony1;</primary></indexterm>
<para>
Vous pouvez obtenir les sources de &slony1; à partir de l'url <ulink
url="http://main.slony.info/downloads/">http://main.slony.info/downloads/</ulink>.
</para>
</sect2>
<sect2 id="encoding">
<title>Encodage d'une base de données</title>
<indexterm><primary>encodage d'une base de données</primary></indexterm>
<para>
Les bases de données &postgres; peuvent être créés avec plusieurs types
d'encodage, défini par la commande &slony1; <command>createdb
--encoding=$ENCODING databasename</command>. Cela suppose que les bases de
données utilisent des encodages <emphasis>identiques.</emphasis>
</para>
<para>
Des encodages <quote>très proches</quote> peuvent ne provoquer aucun problème.
Par exemple, si le système d'origine utilise <envar>LATIN1</envar>, un
abonné <envar>SQL_ASCII</envar> et un autre abonné <envar>UNICODE</envar>,
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.
</para>
<para>
Dans la version 8.1 de &postgres;, des modifications ont été apportées à
l'encodage <envar>UNICODE</envar> car les versions précédentes acceptaient
des encodages invalides. Cela pouvait conduire à des <link
linkend="faqunicode">problèmes de replication</link>.
</para>
<para>
Notez que si l'encodage client (configuré soit dans
<filename>postgresql.conf</filename>, soit par le paramètre
<envar>client_encoding</envar>, soit par la commande
<application>psql</application> <command>\encoding</command>, soit sous
<application>psql</application> par la variable interne
<envar>ENCODING</envar>) diffère de l'encodage serveur, cette différence
peut conduire &slony1; à être incapable de répliquer les caractères
supportés par l'encodage client et non pas par celui du serveur.
</para>
</sect2>
<sect2 id="times">
<title>Synchronisation horloge</title>
<indexterm><primary>synchronisation horloge</primary></indexterm>
<para>
Tous les serveurs utilisés dans le cluster de réplication doivent avoir
leurs horloges internes synchronisées. Cela garantie que <xref
linkend="slon"/> 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 <application>ntpd</application> sur tous les
n&oelig;uds, où les n&oelig;uds abonnés utilisent le n&oelig;ud
<quote>maître</quote> comme serveur de temps.
</para>
<para>
Il est possible pour &slony1; de fonctionner avec des différences de temps,
mais avoir des systèmes <quote>synchonisés</quote> est normalement très
important pour les applications distribuées.
</para>
<para>
Voir <ulink url="http://www.ntp.org/">www.ntp.org</ulink> pour plus de
détails au sujet de NTP (Network Time Protocol).
</para>
<para>
Quelques utilisateurs ont reporté des problèmes lors de l'utilisation de
certaines zones de temps, non reconnues par &postgres;.
<itemizedlist>
<listitem>
<para>
Sur <productname>AIX</productname>, <command><envar>TZ</envar>=CUT0</command>
était non reconnu, conduisant à des échecs d'appels système lors de la
recherche d'un horodatage.
</para>
<para>
<command>CUT0</command> est une variante pour décrire
<command>UTC</command>.
</para>
</listitem>
<listitem>
<para>
Quelques zones de temps ne sont pas encore incluses dans &postgres;.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Dans tous les cas, ce qui semble être communément une <quote>bonne
pratique</quote> avec &slony1; (et, pour nous &postgres;) est d'utiliser
pour l'utilisateur postmaster et/ou l'utilisateur sous lequel
<application>slon</application> tourne
<command><envar>TZ</envar>=UTC</command> ou
<command><envar>TZ</envar>=GMT</command>. Ces fuseaux horaires sont supportées
de manière <emphasis>sûres</emphasis> par n'importe quelle plate-forme, ont
le mérite par rapport à des fuseaux horaires <quote>locaux</quote> de ne
jamais diverger par rapport aux changements heures été-hiver.
</para>
</sect2>
<sect2>
<title>Connexions réseau</title>
<indexterm><primary>connexions réseau</primary></indexterm>
<para>
Il est nécessaire que les n&oelig;uds devant être répliqués entre eux aient
des communications réseau <emphasis>bidirectionnelles</emphasis> entre les
instances &postgres;. Ainsi, si le n&oelig;ud B est en train de répliquer les
données du n&oelig;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&oelig;uds du cluster &slony1; permettent ce type de communication
bidirectionnelle de n'importe quel n&oelig;ud du cluster vers n'importe quel
autre n&oelig;ud du cluster.
</para>
<para>
Pour faciliter la configuration, les adresses réseau devraient être idéalement
identiques à travers tous les n&oelig;uds. <xref linkend="stmtstorepath"/>
leur permet d'être différentes, mais le maintien de ces différents chemins
pointant sur le même serveur peut devenir problématique.
</para>
<para>
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 <ulink url="http://www.brandonhutchinson.com/ssh_tunnelling.html"
id="tunnelling">tunnels SSH</ulink> 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.
</para>
<para>
Notez que <application>slonik</application> et les instances
<application>slon</application> ne nécessitent pas de connexions ou de
protocoles spéciaux pour communiquer ensemble&nbsp;; ils nécessitent
simplement un accès aux bases de données &postgres;, en s'y connectant comme
<quote>super utilisateur</quote> <link linkend="morethansuper">capable de
mettre à jour les tables du système</link>.
</para>
<para>
Une conséquence d'un tel modèle de communication est que le réseau entier
dans lequel un cluster &slony1; 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 <quote>peer-to-peer</quote>, <emphasis>n'importe quel</emphasis>
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&oelig;ud le plus <emphasis>faible</emphasis>. Faire tourner &slony1;
à une localisation qui ne peut être considérée comme sécurisée compromet la
sécurité du cluster dans son ensemble.
</para>
<para>
Une nouvelle fonctionnalité de &slony1; version 1.1 est que les mises à jour
pour un jeu de réplication particulier peuvent être sérialisées via le schéma
&logshiplink;. La donnée enregistrée dans <envar>sl_log_1</envar> et
<envar>sl_log_2</envar> 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 <quote>clé USB</quote> permettant
l'équivalence d'une <ulink url="http://www.faqs.org/rfcs/rfc1149.html">transmission
de diagramme IP on avian carriers - RFC 1149</ulink>. 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&oelig;uds
&slony1;.
</para>
</sect2>
</sect1>
Jump to Line
Something went wrong with that request. Please try again.