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
- Partager vos images, vidéos, musique et imprimante avec le Groupe résidentiel
- N° 2 : Il faut supporter des langues multiples dans SharePoint Portal Server
- Activer la mise en veille prolongée dans Windows 10
- Cybersécurité Active Directory et les attaques de nouvelle génération
- Les 6 étapes vers un diagnostic réussi
Les plus consultés sur iTPro.fr
- Réforme de la facturation électronique : une préparation largement théorique
- Le futur de la cryptographie post-quantique
- Couchbase lance AI Data Plane pour industrialiser l’IA agentique
- Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
Articles les + lus
Couchbase lance AI Data Plane pour industrialiser l’IA agentique
Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
Computex 2026 : 5 signaux forts à retenir
La chaîne d’approvisionnement, point de rupture récurent du SI
Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
À la une de la chaîne Tech
- Couchbase lance AI Data Plane pour industrialiser l’IA agentique
- Windows 11 : Microsoft généralise le point-in-time restore pour accélérer la remise en service des PC
- Computex 2026 : 5 signaux forts à retenir
- La chaîne d’approvisionnement, point de rupture récurent du SI
- Microsoft Build 2026 : contre-offensive des modèles maison face à OpenAI et Anthropic
