Pour accomplir une inversion de rôles de log shipping complète, il suffit d'établir le log shipping du nouveau serveur primaire sur le nouveau serveur secondaire. Comme le nouveau serveur primaire contient un nouveau plan de maintenance de base de données, la tendance naturelle est d'ajouter le nouveau serveur secondaire comme
Inverser les rôles
un serveur de destination dans ce plan. Mais après avoir essayé plusieurs fois d’ajouter le nouveau serveur secondaire comme un serveur de destination, j’ai constaté que le job de sauvegarde du journal des transactions sur le nouveau serveur primaire échoue, et log shipping ne démarrera pas du nouveau serveur primaire vers le nouveau serveur secondaire.
Il faut une stratégie alternative. Après avoir appliqué les procédures cataloguées et tâches de changement de rôles de log shipping que j’ai détaillées précédemment, vous pouvez effectuer une inversion de rôles complète en établissant un nouveau plan de log shipping du nouveau serveur primaire vers l’ancien serveur secondaire. Pour établir le plan, effectuez les opérations suivantes :
1. Supprimez log shipping du plan de maintenance de base de données sur le nouveau serveur primaire.
2. Supprimez le plan de maintenance de base de données sur le serveur primaire.
3. Supprimez le plan de maintenance de base de données sur le serveur secondaire.
4. Gardez tous les fichiers transaction-log.
5. Créez un nouveau plan de maintenance de base de données sur le nouveau serveur primaire, en indiquant les nouveaux serveur secondaire et base de données et les emplacements du fichier transaction-log approprié, comme décrit dans la 1e partie de cette série.
6. Reprenez l’activité de réplication sur le nouveau serveur primaire.
Après avoir établi l’inversion de rôles et la nouvelle paire de log shipping, Log Shipping Monitor d’Enterprise Manager pourrait signaler que la nouvelle base de données du serveur secondaire est désynchronisée par rapport à la nouvelle base de données du serveur primaire. Vous recevrez ce rapport si la différence de temps entre le dernier journal de transactions chargé et la sauvegarde du journal de transactions provenant du nouveau serveur primaire dépasse le seuil de désynchronisation. Si vous attendez jusqu’à ce que le job de chargement charge le dernier fichier de sauvegarde, l’état de Log Shipping Monitor reviendra à son état sans erreur habituel.
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
