Documentation Slony-I 2.0.3 -

Administration Slony-I

22. Support du partitionnement

Slony-I™ ne supporte pas directement la méthode de partitionnement par héritage de PostgreSQL™. 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.

Un des tests du Section 25, « Banc d'essai Slony-I », appelé testinherit, vérifie que Slony-I™ se comporte comme prévu lors de la réplication de données partitionnées. Ce test crée une table maître sales_data dont plusieurs tables filles héritent :

Cet exemple est un peu simpliste car il fournit uniquement des règles d'insertion dans les différentes partitions ; il ne permet pas de migrer des lignes d'une partition à une autre si elles sont modifiées via une commande UPDATE. Par contre, à la différence de beaucoup de partitionnements, celui-ci permet à la table « parente » de contenir des lignes.

On peut remarquer quelques points intéressants :

22.1. Support de l'ajout dynamique de partition

Un « cas d'utilisation » fréquent de la réplication consiste à partitionner de larges ensembles de données selon un critère temporel : la semaine, le mois, le trimestre ou l'année, ce qui implique par conséquent l'ajout périodique d'une nouvelle partition.

L'approche traditionnelle pour effectuer cela avec Slony-I™ est la suivante :

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 SLONIK SUBSCRIBE SET(7). Cette alternative est la suivante : on utilise le script SLONIK EXECUTE SCRIPT(7), pour exécuter le script DDL suivant :

  • Ajouter la nouvelle partition sur chaque nœud 

  • Exécuter les fonction stockées pour inscrire la nouvelle partition dans l'ensemble de réplication ;

    Sur le nœ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.

    Sur les nœuds abonnés, on peut effectuer sans danger un TRUNCATE sur la nouvelle table.

Il existe plusieurs fonctions qui prennent en charge cela. L'utilisateur peut utiliser celle qu'il préfère. La « fonction de base » est add_empty_table_to_replication(), les autres disposent d'arguments supplémentaires ou différents.

  • add_empty_table_to_replication (set_id, tab_id, nspname, tabname, idxname, comment);

    Ceci est la fonction de « base » ; 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.

    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.

  • replicate_partition(tab_id, nspname, tabname, idxname, comment);

    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.

[Note]

Note

Comme il a été remarqué précédemment, Slony-I™ 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.

PrécédentScripts d'administration Niveau supérieurSommaire Mise à jour de Slony-ISuivant