Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
209 lines (170 sloc) 6.09 KB
<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
le $Date$
par $Author$
révision $Revision$ -->
<sect1 id="partitioning">
<title>Support du partitionnement </title>
<indexterm><primary>partitionnement</primary></indexterm>
<para>
&slony1; ne supporte pas directement la méthode de partitionnement
par héritage de &postgres;. Cependant, il n'empêche pas non plus les
utilisateur de répliquer de tels héritages et ainsi que les tables
qui y sont associées.
</para>
<para>
Un des tests du <xref linkend="testbed"/>, appelé
<filename>testinherit</filename>, vérifie que &slony1; se comporte
comme prévu lors de la réplication de données partitionnées. Ce test
crée une table maître <envar>sales_data</envar> dont plusieurs tables filles
héritent&nbsp;:
</para>
<itemizedlist>
<listitem><para><envar>us_east</envar></para></listitem>
<listitem><para><envar>us_west</envar></para></listitem>
<listitem><para><envar>canada</envar></para></listitem>
</itemizedlist>
<para>
Cet exemple est un peu simpliste car il fournit uniquement des règles
d'insertion dans les différentes partitions&nbsp;; il ne permet pas de
migrer des lignes d'une partition à une autre si elles sont modifiées via
une commande <command>UPDATE</command>. Par contre, à la différence de
beaucoup de partitionnements, celui-ci permet à la table
<quote>parente</quote> de contenir des lignes.
</para>
<para>
On peut remarquer quelques points intéressants&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Chaque table de partition doit être ajoutée à la réplication individuellement.
</para>
</listitem>
<listitem>
<para>
&slony1; n'est pas conscient des relations entre les tables de
partition&nbsp;; il les considère comme une série de tables
indépendantes.
</para>
</listitem>
</itemizedlist>
<sect2>
<title>Support de l'ajout dynamique de partition</title>
<para>
Un <quote>cas d'utilisation</quote> fréquent de la réplication consiste à
partitionner de larges ensembles de données selon un critère temporel&nbsp;:
la semaine, le mois, le trimestre ou l'année, ce qui implique par conséquent
l'ajout périodique d'une nouvelle partition.
</para>
<para>
L'approche traditionnelle pour effectuer cela avec &slony1; est la
suivante&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
<xref linkend="stmtddlscript"/> pour ajouter la nouvelle table de
partition sur chaque n&oelig;ud&nbsp;;
</para>
</listitem>
<listitem>
<para>
<xref linkend="stmtcreateset"/> pour créer un ensemble de réplication
temporaire&nbsp;;
</para>
</listitem>
<listitem>
<para>
<xref linkend="stmtsetaddtable"/> pour ajouter la table dans cet
ensemble&nbsp;;
</para>
</listitem>
<listitem>
<para>
<xref linkend="stmtsubscribeset"/>, une fois pour chaque n&oelig;ud
abonné, afin de mettre en place la réplication sur chaque n&oelig;ud&nbsp;;
</para>
</listitem>
<listitem>
<para>
<xref linkend="stmtmergeset"/>, une fois que la réplication fonctionne,
afin de supprimer l'ensemble de réplication temporaire
</para>
</listitem>
</itemizedlist>
<para>
Sachant qu'il y a de fortes chances pour que la nouvelle partition soit vide,
il existe un mécanisme alternatif qui évite la création d'un ensemble de
réplication supplémentaire et l'utilisation de multiples requêtes
<xref linkend="stmtsubscribeset"/>. Cette alternative est la suivante&nbsp;:
on utilise le script <xref linkend="stmtddlscript"/>, pour exécuter le
script DDL suivant&nbsp;:
</para>
<itemizedlist>
<listitem>
<para>
Ajouter la nouvelle partition sur chaque n&oelig;ud&nbsp;
</para>
</listitem>
<listitem>
<para>
Exécuter les fonction stockées pour inscrire la nouvelle partition dans
l'ensemble de réplication&nbsp;;
</para>
<para>
Sur le n&oelig;ud d'origine, si la table de partitionnement contient des
données, le script DDL s'arrêtera car le fait que la table soit vide est
une condition qui ne peut pas être violée.
</para>
<para>
Sur les n&oelig;uds abonnés, on peut effectuer sans danger un
<command>TRUNCATE</command> sur la nouvelle table.
</para>
</listitem>
</itemizedlist>
<para>
Il existe plusieurs fonctions qui prennent en charge cela. L'utilisateur
peut utiliser celle qu'il préfère. La <quote>fonction de base</quote> est
<function>add_empty_table_to_replication()</function>, les autres disposent
d'arguments supplémentaires ou différents.
</para>
<itemizedlist>
<listitem>
<para>
<function>add_empty_table_to_replication (set_id, tab_id, nspname, tabname, idxname, comment);</function>
</para>
<para>
Ceci est la fonction de <quote>base</quote>&nbsp;; vous devez spécifier
l'identifiant de l'ensemble (set_id), l'identifiant de la table (tab_id),
l'espace de nom (nspname), le nom de la table(tabname), le nom de l'index
(idxname) et un commentaire (comment). La table sera alors ajoutée dans
la réplication.
</para>
<para>
Notez que le nom d'index est optionnel. Si la valeur est NULL, alors la
fonction utilisera la clé primaire de la table, en supposant qu'il en
existe une. La fonction échouera s'il n'existe pas de clé primaire.
</para>
</listitem>
<listitem>
<para>
<function>replicate_partition(tab_id, nspname, tabname, idxname, comment);</function>
</para>
<para>
Si l'on sait que la table qui doit être répliquée hérite d'une table mère
répliquée elle-aussi, alors cette fonction peut récupérer les
informations sur l'ensemble de réplication et l'origine à partir de la
table mère.
</para>
</listitem>
</itemizedlist>
<note>
<para>
Comme il a été remarqué précédemment, &slony1; n'est pas conscient que les
tables sont partitionnées. Ainsi, cette approche peut être utilisée pour
ajouter une table vide dans la réplication.
</para>
</note>
</sect2>
</sect1>