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
Microsoft 365 Tenant Resilience
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Attaques edge : les fournisseurs, nouvelle cible prioritaire des cybercriminels
- Analyse Patch Tuesday Août 2026
- Model Context Protocol : le contexte, grand oublié du débat
- Microsoft dévoile MAI-Thinking-1 : un modèle de raisonnement « enterprise-grade » en preview publique
Articles les + lus
Quand les « travailleurs numériques » pallient le manque de bras dans l’industrie
Model Context Protocol : le contexte, grand oublié du débat
Microsoft dévoile MAI-Thinking-1 : un modèle de raisonnement « enterprise-grade » en preview publique
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
À la une de la chaîne Tech
- Quand les « travailleurs numériques » pallient le manque de bras dans l’industrie
- Model Context Protocol : le contexte, grand oublié du débat
- Microsoft dévoile MAI-Thinking-1 : un modèle de raisonnement « enterprise-grade » en preview publique
- 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
