Dans la vie d'un moteur de réplication Replication Server, les partitions doivent parfois être déplacées.
2 méthodes sont disponibles pour déplacer des partitions :
La structure de la table rs_diskpartitions est décrite dans cet article.
Le contexte du schéma de réplication de l'article est le suivant
et on se propose de déplacer les partitions du moteur de réplication DAL_P1_REP du système de fichiers (filesystem) /dal/sybase/DAL_P1_REP/stabledevices vers le système de fichiers /DAL/sybase/DAL_P1_REP/stabledevices en utilisant la méthode de mise à jour directe de la table rs_diskpartitions. Les partitions n'ont pas pour support des raw devices.
Le déplacement des partitions en mettant à jour la table rs_diskpartitions dans la base RSSD Adaptive Server Enterprise est disponible dans le guide pratique Sybase Replication Server - §4 : Guide pratique et astuces Sybase Replication Server »
La table rs_diskpartitions dans la base RSSD d'un moteur de réplication stocke les informations sur les partitions. La structure de la table rs_diskpartitions est la suivante :
Les colonnes name et logical_name correspondent respectivement au chemin et au nom logique d'une partition dans un moteur de réplication.
select id,name,logical_name from rs_diskpartitions
id name logical_name ------ ------------------------------------------------ --------------- 101 /dal/sybase/DAL_P1_REP/stabledevices/PART01.dat PART01 102 /dal/sybase/DAL_P1_REP/stabledevices/PART02.dat PART02
La table rs_diskpartitions comporte deux indexes uniques : un index unique clustered sur le nom logique de la partition (logical_name) et un index unique non clustered sur le chemin de la partition (name).
sp_helpindex rs_diskpartitions
index_name index_keys index_description index_max_rows_per_page index_fillfactor ... ---------------------- ------------- -------------------- ----------------------- ---------------- ... rs_key_diskpartitions logical_name clustered, unique 0 0 ... rs_key1_diskpartitions name nonclustered, unique 0 0 ...
La méthode officielle supportée consiste à créer une nouvelle partition avec les commandes add partition / create partition, puis à supprimer l'ancienne partition.
Pour créer les nouvelles partitions sur le système de fichiers /DAL/sybase/DAL_P1_REP/stabledevices :
| Replication Server 12.6 | Replication Server 15.0 |
|---|---|
add partition logical_name on 'physical_name' with size sizeMB [starting at vstart] add partition part01 on '/DAL/sybase/DAL_P1_REP/stabledevices/PART01.dat' with size 1000 |
create partition logical_name on 'physical_name' with size sizeMB [starting at vstart] create partition part01 on '/DAL/sybase/DAL_P1_REP/stabledevices/PART01.dat' with size 1000 |
Compte tenu de l'unicité de la colonne logical_name de la table rs_diskpartitions, il est impossible de créer les partitions avec les noms logiques PART01 et PART02 car celles-ci existent déjà. C'est pourquoi dans l'exemple ci-dessus, le nom logique part01 en minuscules est donnée à la partition PART01.dat créée sur le système de fichiers /DAL/sybase/DAL_P1_REP/stabledevices.
%> cd /DAL/sybase/DAL_P1_REP/stabledevices touch PART01.dat touch PART02.dat
Pour supprimer les anciennes partitions :
drop partition <partition_name>
drop partition PART01 go drop partition PART02 go
La commande drop partition marque la partition avec le statut "en attente de suppression" ou "pending drop". Une fois marquée, aucun nouveau segment n'est créé sur cette partition. Lorsque toutes les données de la partition ont été distribuées, la partition est supprimée.
En revanche, lorsqu'une partition contient un segment partiellement rempli, la file ne peut pas être supprimée tant que le segment n'est pas rempli. Si la partition a reçu le statut "pending drop", le segment ne pourra jamais être rempli complètement et la commande de suppression de la partition est en échec. Ce cas de figure est problématique et peut se présenter en environnement transactionnel intensif.
Dans cette première méthode, dite méthode classique:
La seconde méthode permet de conserver les noms logiques des partitions et est bien plus rapide et plus efficace. Cette méthode alternative consiste à déplacer physiquement les partitions avec les commandes systèmes de l'OS (mv, move, ufsdump, ufsrestore, snapshot zfs etc...) et mettre à jour directement la table rs_diskpartitions dans la base RSSD.
Seule contrainte : durant cette opération, le moteur de réplication est mis en veille et éteint. Il y a indisponibilité du moteur de réplication mais le temps de déplacement des partitions avec les commandes systèmes de l'OS sera toujours plus court et moins risqué qu'avec les commandes add partition/create partition - drop partition surtout si l'activité transactionnelle est forte dans les partitions durant le déplacement à chaud.
Voici la procédure :
| 1. | Le moteur de réplication est mis en veille (mode quiesced). Pour la
procédure de mise en veille d'un moteur de réplication, consulter
l'article Procédure de mise en veille (mode quiesced) de Sybase
Replication Server ». La mise en veille du moteur de réplication est vérifiée avec la commande admin quiesce_check. DAL_D1_REP> admin quiesce_check DAL_D1_REP> go Replication Server DAL_D1_REP is quiesced |
| 2. | Le moteur de réplication est éteint avec la commande shutdown.DAL_D1_REP> shutdown |
| 3. | La table rs_diskpartitions est mise à jour directement pour spécifier
les nouveaux chemins des partitions : DAL_P1_REP_RSSD> update rs_diskpartitions set name='/DAL/sybase/DAL_P1_REP/stabledevices/PART01.dat' where logical_name='PART01' DAL_P1_REP_RSSD> go (1 row affected) DAL_P1_REP_RSSD> update rs_diskpartitions set name='/DAL/sybase/DAL_P1_REP/stabledevices/PART02.dat' where logical_name='PART02' DAL_P1_REP_RSSD> go (1 row affected) DAL_P1_REP_RSSD> checkpoint DAL_P1_REP_RSSD> go |
| 4. | Les partitions sont physiquement déplacées avec la commande mv. après
avoir vérifié qu'il n'y a plus aucun process sur les partitions avec la
commande fuser%> cd /dal/sybase/DAL_P1_REP/stabledevices %> fuser *.dat PART01.dat: PART02.dat: %> mv /dal/sybase/DAL_P1_REP/stabledevices/PART01.dat /DAL/sybase/DAL_P1_REP/stabledevices %> mv /dal/sybase/DAL_P1_REP/stabledevices/PART02.dat /DAL/sybase/DAL_P1_REP/stabledevices |
| 5. | Le serveur de réplication est redémarré. |
| Version | Date | Commentaires |
|---|---|---|
| 1.0 | 12/2009 | Version initiale |