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
Plan de sécurité Microsoft 365
Les attaquants savent comment prendre le contrôle de votre tenant Microsoft 365, et vous, savez-vous comment le reprendre en main ?
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- CRM et souveraineté : le choix technologique est devenu un choix politique
- France : la maturité data devient le moteur du retour sur investissement de l’IA
- Cloud et IA : une maturité en retard face à l’explosion des usages
- On ne peut pas gouverner ce qu’on ne peut pas voir : pourquoi la visibilité doit-elle passer avant la gouvernance en matière de sécurité des identités ?
Articles les + lus
Les coûts cachés des merge requests générées par l’IA
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
À la une de la chaîne Tech
- Les coûts cachés des merge requests générées par l’IA
- Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
- Moderniser le développement logiciel : de la fragmentation à l’intégration
- Analyse Patch Tuesday Mars 2026
- Une nouvelle ère de la modernisation du mainframe
