Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Une base de données donnée peut être mise en miroir ou avoir des journaux expédiés ; elle peut également être mise en miroir et avoir des journaux expédiés simultanément. Pour choisir l’approche à utiliser, tenez compte des éléments suivants :
Combien de serveurs de destination avez-vous besoin ?
Si vous avez besoin d’une base de données de destination unique, la mise en miroir de bases de données est la solution recommandée.
Si vous avez besoin de plusieurs bases de données de destination, vous devez utiliser l'expédition de journaux, seule ou en conjonction avec la mise en miroir de bases de données. La combinaison de ces approches vous offre les avantages de la mise en miroir de bases de données, ainsi que la prise en charge multiple des destinations offerte par l'expédition des journaux.
Si vous devez retarder la restauration du journal sur la base de données de destination (généralement, pour vous protéger contre les erreurs logiques), utilisez l'expédition des journaux, seule ou avec la mise en miroir des bases de données.
Cette rubrique traite des considérations relatives à la combinaison de la copie des journaux de transaction et de la mise en miroir de bases de données.
Remarque
Pour obtenir des introductions à ces technologies, consultez La mise en miroir de bases de données (SQL Server) et À propos de la copie des journaux de transaction (SQL Server).
Combinaison de la copie des journaux de transaction et de la mise en miroir de bases de données
La base de données principale d’une session de mise en miroir peut également servir de base de données principale dans une configuration d'expédition des journaux, ou inversement, tant que le partage de sauvegarde pour l'expédition des journaux est intact. La session de mise en miroir de bases de données s’exécute en mode d’exploitation, qu’elle soit synchrone (avec la sécurité des transactions définie sur FULL) ou asynchrone (avec la sécurité des transactions définie sur OFF).
Remarque
Pour utiliser la mise en miroir sur une base de données, le modèle de récupération complète est toujours nécessaire.
En règle générale, lors de la combinaison de la copie des journaux de transaction et de la mise en miroir de bases de données, la session de mise en miroir est établie avant la copie des journaux de transaction, bien que cela ne soit pas obligatoire. Ensuite, la base de données actuelle principale est en configuration en tant que base de données principale du transfert de journaux de transactions (la base de données principale/primaire), ainsi qu’une ou plusieurs bases de données secondaires distantes. En outre, la base de données miroir doit être configurée en tant que base de données de copie des journaux de transaction (la base de données miroir/primaire). Les bases de données secondaires de copie des journaux de transaction doivent se trouver sur différentes instances de serveur que le serveur principal/principal ou le serveur miroir/serveur principal.
Remarque
Les paramètres de confidentialité de la casse des serveurs impliqués dans la copie des journaux de transaction doivent correspondre.
Pendant une session de copie des journaux, les tâches de sauvegarde sur la base de données primaire créent des sauvegardes de journaux dans un dossier de sauvegarde. À partir de là, les sauvegardes sont copiées par les travaux de copie des serveurs secondaires. Pour que les travaux de sauvegarde et les travaux de copie réussissent, ils doivent avoir accès au dossier de sauvegarde de copie des journaux de transaction. Pour optimiser la disponibilité du serveur principal, nous vous recommandons d’établir le dossier de sauvegarde dans un emplacement de sauvegarde partagé sur un ordinateur hôte distinct. Vérifiez que tous les serveurs de copie des journaux de transaction, y compris le serveur miroir/serveur principal, peuvent accéder à l’emplacement de sauvegarde partagé (appelé partage de sauvegarde).
Pour permettre l'expédition de journaux après l'échec du basculement de la mise en miroir de la base de données, vous devez également configurer le serveur miroir en tant que serveur primaire, en utilisant la même configuration que celle utilisée pour la base de données principale. La base de données miroir est dans l’état de restauration, ce qui empêche les travaux de sauvegarde de sauvegarder le journal sur la base de données miroir. Cela garantit que la base de données miroir/primaire n'entrave pas la base de données principale dont les sauvegardes de journaux sont actuellement copiées par des serveurs secondaires. Pour empêcher les alertes intempestives, une fois la tâche de sauvegarde exécutée sur la base de données miroir/primaire, la tâche de sauvegarde enregistre un message dans la table log_shipping_monitor_history_detail et la tâche de l’agent retourne un état de réussite.
La base de données miroir/primaire est inactive dans la session de copie des journaux de transaction. Toutefois, si la mise en miroir échoue, l'ancienne base de données miroir devient la base de données principale. À ce stade, cette base de données devient également active en tant que base de données principale de copie des journaux de transaction. Les tâches de sauvegarde de l'expédition des journaux qui n’étaient précédemment pas en mesure d'expédier le journal pour cette base de données commencent à transmettre les journaux. À l’inverse, un basculement entraîne l'ancien principal/base de données primaire à devenir la nouvelle base de données miroir/primaire et à entrer dans l'état de restauration, et les travaux de sauvegarde sur cette base de données cessent de sauvegarder le journal.
Remarque
En cas de défaillance automatique, le passage au rôle miroir se produit lorsque l'ancienne base de données principale/primaire reprend sa place dans la session de mise en miroir.
Pour s’exécuter en mode haute sécurité avec basculement automatique, la session de mise en miroir est configurée avec une instance de serveur supplémentaire appelée témoin. Si la base de données principale est perdue pour une quelconque raison après la synchronisation de la base de données et si le serveur miroir et le serveur témoin peuvent toujours communiquer entre eux, un basculement automatique a lieu. Un basculement automatique amène le serveur miroir à assumer le rôle principal et à mettre sa base de données en ligne en tant que base de données principale. Si l'emplacement de sauvegarde de l'expédition des journaux est accessible au nouveau serveur principal/primordial, ses travaux de sauvegarde commencent à expédier des sauvegardes de journaux à cet emplacement. Le mode synchrone de mise en miroir de bases de données garantit que la chaîne de journaux n’est pas affectée par un basculement de mise en miroir et que seul le journal valide est restauré. Les serveurs secondaires continuent de copier des sauvegardes de journaux sans savoir qu’une autre instance de serveur est devenue le serveur principal.
Lors de l’utilisation d’un moniteur de copie des journaux de transaction local, aucune considération particulière n’est nécessaire pour prendre en charge ce scénario. Pour plus d’informations sur l’utilisation d’une instance de supervision à distance avec ce scénario, consultez « L’impact de la mise en miroir de bases de données sur une instance de supervision à distance », plus loin dans cette rubrique.
Basculement de la base de données principale vers la base de données miroir
La figure suivante montre comment la copie des journaux de transaction et la mise en miroir de bases de données fonctionnent ensemble lors de l’exécution de la mise en miroir en mode haute sécurité avec basculement automatique. Initialement, Server_A est à la fois le serveur principal pour la mise en miroir et le serveur principal pour la copie des journaux de transaction. Server_B est le serveur miroir et est également configuré en tant que serveur principal, actuellement inactif. Server_C et Server_D sont des serveurs secondaires de copie des journaux de transaction. Pour optimiser la disponibilité de la session de copie des journaux de transaction, l’emplacement de sauvegarde se trouve dans un dossier partagé sur un ordinateur hôte distinct.
Après un basculement de mise en miroir, le nom du serveur principal défini sur le serveur secondaire n’est pas modifié. .
Impact de la mise en miroir de bases de données sur une instance de supervision à distance
Lorsque la copie des journaux de transaction utilise avec une instance de supervision à distance, la combinaison de la session de copie des journaux de transaction et de la mise en miroir de bases de données affecte les informations contenues dans les tables de surveillance. Les informations sur le primaire sont une combinaison de celle qui est configurée au niveau du principal et du moniteur configuré sur chaque secondaire.
Pour que la surveillance reste aussi transparente que possible, lorsque vous utilisez un moniteur distant, nous vous recommandons de spécifier le nom principal d’origine lors de la configuration du serveur principal au niveau secondaire. Cette approche facilite également la modification de la configuration de l'expédition des journaux à partir de Microsoft SQL Server Agent. Pour plus d’informations sur le suivi, consultez Surveiller l'expédition de journaux (Transact-SQL).
Configuration de la mise en miroir et de l'expédition des journaux transactionnels ensemble
Pour configurer ensemble la mise en miroir de bases de données et la journalisation, les étapes suivantes sont nécessaires :
Restaurez les sauvegardes de la base de données principale/primaire avec NORECOVERY sur une autre instance de serveur, afin de l'utiliser ultérieurement comme base de données miroir pour cette base de données principale/primaire. Pour plus d’informations, consultez Préparer une base de données miroir pour la mise en miroir (SQL Server).
Configurez la mise en miroir de bases de données. Pour plus d’informations, consultez Établir une session de mise en miroir de bases de données à l’aide de l’authentification Windows (SQL Server Management Studio) ou configurer la mise en miroir de bases de données (SQL Server).
Restaurez les sauvegardes de la base de données principale/primaire vers d’autres instances de serveur à utiliser ultérieurement comme bases de données secondaires de copie des journaux de transaction pour la base de données primaire.
Configurez la copie des journaux de transaction sur la base de données principale comme base de données primaire pour une ou plusieurs bases de données secondaires.
Vous devez configurer un partage unique en tant que répertoire de sauvegarde (un partage de sauvegarde). Cela garantit qu’après le basculement de rôle entre le principal et les serveurs miroirs, les travaux de sauvegarde continuent d’écrire dans le même répertoire que précédemment. Une bonne pratique consiste à s’assurer que ce partage se trouve sur un serveur physique différent des serveurs hébergeant les bases de données impliquées dans la mise en miroir et la copie des journaux de transaction.
Pour plus d’informations, consultez Configurer la copie des journaux de transaction (Transact-SQL).
Basculement manuel depuis le serveur principal vers le serveur miroir.
Pour effectuer un basculement manuel :
Configurez l'expédition des journaux de transaction sur le nouveau principal (ancien miroir) comme base de données principale.
Important
N’effectuez aucune configuration à partir d’un serveur secondaire.
Vous devez utiliser le même partage de sauvegarde que celui que vous avez utilisé à l’étape 4.
L’interface Transaction Log Shipping dans SQL Server Management Studio ne prend en charge qu’une seule base de données source par configuration de journaux de transaction. Par conséquent, vous devez utiliser des procédures stockées pour configurer le nouveau principal en tant que principal.
Effectuez un autre basculement manuel pour revenir au principal d'origine.