Sybase Replication Server, déplacer des partitions (rs_diskpartitions) sans modifier les noms logiques

Introduction

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 :

• Dans la méthode officielle et qui utilise les commandes add partition, create partition et drop partition, les noms logiques des partitions sont amenés à être modifiés et la suppression des anciennes partitions peut être en échec.
• La seconde méthode non supportée permet de conserver les noms logiques mais implique une indisponibilité du moteur de réplication : la table rs_diskpartitions dans la base RSSD (Replication Server SystemDatabase) du moteur de réplication est mise à jour directement.

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 : Sybase Replication Server - Guide pratique, aide-mémoire

La table rs_diskpartitions dans la base RSSD (Replication Server System Database)

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).

exec 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 ...

Déplacer des partitions

Déplacer des partitions avec les commandes add partition, create partition et drop partition

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 :

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:

• les noms logiques des partitions doivent être modifiés afin de ne pas violer la contrainte d’unicité sur la colonne logical_name de la table rs_diskpartitions, ce qui peut être une contrainte si des normes de nomenclature des partitions sont en place et si la conservation de l’architecture initiale est souhaitée.
• le temps de suppression des anciennes partitions n’est pas prédictible en fonction de l’activité transactionnelle en cours et du nombre de segments présents dans les partitions à supprimer (la commande admin disk_space donne le nombre de segments dans une partition). Par ailleurs la commande drop partition peut être en échec dans le contexte de segments remplis partiellement lors de la mise au statut "pending drop" d’une partition.

Déplacer des partitions en mettant à jour la table rs_diskpartitions

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 :

Étape 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

Étape 2. Le moteur de réplication est éteint avec la commande shutdown.

DAL_D1_REP> shutdown
DAL_D1_REP> go

Étape 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

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

DAL_P1_REP_RSSD> checkpoint
DAL_P1_REP_RSSD> go

Étape 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

Étape 5. Le serveur de réplication est redémarré et le mode veille est retiré.