Changer les noms de répliques et de sites

Pour changer le nom d'une réplique de base de données, vous devez supprimer la réplique et créer une nouvelle réplique avec un nom différent. Le changement de nom de sites nécessite une planification et une coordination entre les sites du clan, plus particulièrement pour le site désigné pour l'opération de changement de nom et le site maître en cours. Synchronisez tous les sites avant d'effectuer le changement de nom.

Changement de noms de sites

La plupart des clients Rational ClearQuest définissent les informations de connexion en utilisant un nom d'ensemble de bases de données. Les noms d'ensembles de bases de données sont stockés dans le registre Windows sur chaque client et dans des fichiers sous Linux et UNIX. Dans les environnements MultiSite, ils sont généralement nommés CQMS.CLAN.SITE mais ce schéma de désignation est facultatif. La plupart des clients peuvent utiliser n'importe quel nom pour accéder à un ensemble de bases de données Rational ClearQuest MultiSite. En revanche, la commande multiutil construit un nom d'ensemble de bases de données à partir des différents arguments de clan et de site transmis via la ligne de commande. De plus, la commande multiutil vérifie que le nom de site est valide pour le clan en comparant les informations dans les bases de données avec le nom indiqué dans la ligne de commande. Lors de l'accès à un ensemble de bases de données à partir de la commande multiutil, le nom de l'ensemble de bases de données doit donc correspondre aux informations stockées dans la base de données.

La commande renamesite change le nom d'ensemble de bases de données stocké dans le registre. Si vous changez le nom du site maître en cours, le nom de l'ensemble de bases de données change lorsque vous exécutez la commande renamesite. Si vous changez le nom d'un autre site, le nom de l'ensemble de bases de données change lorsque la réplique de base de données maître sur ce site reçoit une notification du changement de nom au cours d'une opération syncreplica -import. De ce fait, lorsque le nom de site est changé, les informations de connexion sur le serveur de synchronisation du site renommé doivent être mises à jour pour que ce serveur puisse effectuer d'autres opérations multiutil. Cela nécessite généralement l'édition de fichiers de traitement par lots ou de scripts de shell. Les éléments à prendre en considération pour la mise à jour d'autres clients varient, en fonction de la raison du changement de nom. Voici trois scénarios de changement de nom, répertoriés ici du plus simple au plus complexe :
  1. Vous voulez mettre un site hors service et l'indiquer dans le nom du site. Par exemple, en renommant Austin en Austin_obsolète.

    Dans ce cas, pouvez utiliser la commande rmreplica pour supprimer chaque base de données utilisateur du site, et empêcher ainsi l'accès aux bases de données obsolètes.

  2. Vous souhaitez continuer à utiliser les bases de données utilisateur mais vous voulez utiliser un nom différent pour le site. Par exemple, vous déplacez des opérations de Vancouver à Toronto et vous voulez renommer le site Vancouver en Toronto.

    Dans ce cas, le site est renommé mais les bases de données restent sur le même serveur et les noms des ensembles de bases de données n'ont pas besoin d'être modifiés. Vous pouvez cependant choisir de changer le nom de l'ensemble de base de données pour correspondre au changement de nom du site. Si vous déplacez les bases de données sur d'autres serveurs, vous devez également mettre à jour les informations de connexion sur chaque client.

  3. Vous souhaitez conserver l'accès au site avec un autre nom et créer un nouveau site avec l'ancien nom. Par exemple, après avoir déplacé des bases de données de Vancouver à Toronto, vous créez un nouveau site Vancouver.

    Dans ce cas, les anciennes bases de données continuent à fonctionner, mais avec un nom de site différent. Les clients n'ayant pas mis à jour les informations relatives à l'ensemble de bases de données peuvent sembler fonctionner, mais ils ne se connecteront pas au bon site. Dans cet exemple, l'utilisateur peut penser que le client se connecte au niveau site Vancouver alors qu'il se connecte en fait à l'ancien site Vancouver (et nouveau site Toronto). Mettez les informations de connexion à jour sur chaque client pour garantir l'accès aux bases de données appropriées.

Concepts associés
Suppression de réplique
Création de répliques de base de données
Référence associée
rmreplica
mkreplica
syncreplica
renamesite

Retour d'informations