Gestion de copies de base de données de boîtes aux lettres

Article
05/20/2011

S'applique à : Exchange Server 2010

Dernière rubrique modifiée : 2010-01-25

La mobilité de base de données est une nouvelle architecture de Microsoft Exchange Server 2010 qui supprime le concept de groupes de stockage et découple une base de données de boîtes aux lettres Exchange 2010 d’un serveur de boîtes aux lettres. Comme les groupes de stockage ont été supprimés d’Exchange 2010, la réplication continue fonctionne alors au niveau de la base de données. Dans Exchange 2010, les journaux de transactions sont répliqués vers un ou plusieurs serveurs de boîtes aux lettres et relus dans une ou plusieurs copies d’une base de données de boîtes aux lettres stockées sur ces serveurs. Plusieurs concepts utilisés dans la réplication continue d’Exchange Server 2007 ont été conservés dans Exchange 2010, notamment les concepts de divergence, l’utilisation de la numérotation de montage de base de données automatique et des réseaux publics et privés.

Gestion des copies de base de données

Une fois que vous avez créé les copies d’une base de données, vous pouvez utiliser la console de gestion Exchange et l’environnement de ligne de commande Exchange Management Shell pour contrôler la santé et l’état de chaque copie ainsi que pour effectuer les autres tâches de gestion associées aux copies de base de données. Voici quelques tâches de gestion que vous devrez peut-être effectuer : interruption ou reprise de la copie d’une base de données, amorçage de la copie d’une base de données, contrôle des copies de base de données, configuration des paramètres de copie de base de données et suppression d’une copie de base de données.

Interruption et reprise des copies de base de données

Vous pouvez être amené à interrompre et à reprendre la réplication continue de la copie d’une base de données pour plusieurs raisons, telles qu’une opération de maintenance prévue. En outre, certaines tâches administratives, telles que l’amorçage, nécessitent que vous suspendiez d’abord la copie d’une base de données. Il est aussi recommandé de suspendre toute activité de réplication en cas de modification du chemin ou des fichiers journaux de la base de données. Vous pouvez suspendre et reprendre l’activité de copie de base de données à l’aide de la console de gestion Exchange ou en exécutant les cmdlets Suspend-DatabaseCopy et Resume-DatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell. Pour obtenir la procédure détaillée de suspension ou de reprise de l’activité de réplication continue d’une copie de base de données, consultez la rubrique Interrompre ou reprendre une copie de base de données de boîte aux lettres.

La troncation de journal ne s’effectue pas sur la copie de base de données de boîtes aux lettres active lorsque au moins une copie passive est interrompue. Si vos activités de maintenance planifiées doivent s’effectuer sur une période prolongée (par exemple, plusieurs jours), la création de fichiers journaux risque d’être considérable. Afin d’éviter le remplissage du lecteur de journaux de transactions, vous pouvez supprimer la copie de base de données passive concernée au lieu de l’interrompre. Lorsque la maintenance planifiée est terminée, vous pouvez rajouter la copie de base de données passive.

Amorçage d’une copie de base de données

L’amorçage, ou mise à jour, est le processus au cours duquel une base de données, qu’il s’agisse d’une base de données vierge ou de la copie d’une base de données de production, est ajoutée en tant que base de données de production à l’emplacement de copie cible sur un autre serveur de boîtes aux lettres dans le même groupe de disponibilité de base de données (DAG). Cela devient la base de données de base pour la copie gérée par ce serveur.

Selon la situation, l’amorçage peut être un processus automatique ou manuel que vous lancez. Quand une copie de base de données est ajoutée, la copie sera automatiquement amorcée si le serveur cible et son stockage sont configurés comme il faut. Si vous souhaitez amorcer manuellement une copie de base de données et que vous ne voulez pas qu’un amorçage automatique s’effectue lors de la création de la copie, vous pouvez utiliser le paramètre SeedingPostponed au moment de l’exécution de la cmdlet Add-MailboxDatabaseCopy.

Les copies de base de données nécessitent rarement d’être amorcées à nouveau une fois que l’amorçage initial a eu lieu. Toutefois, si un réamorçage s’avère nécessaire ou si vous voulez amorcer manuellement une copie de base de données au lieu de laisser le système amorcer automatiquement la copie, vous pouvez le faire à l’aide de l’assistant Mise à jour d’une copie de base de données dans la console de gestion Exchange ou à l’aide de la cmdlet Update-MailboxDatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell. Avant d’amorcer une copie de base de données, vous devez d’abord interrompre la copie de la base de données de boîtes aux lettres. Pour obtenir la procédure détaillée d’amorçage d’une copie de base de données, consultez la rubrique Mise à jour d’une copie de la base de données de boîtes aux lettres.

Après une opération d’amorçage manuel, la réplication de la copie de base de données de boîtes aux lettres amorcée reprend automatiquement. Si vous ne souhaitez pas que la réplication reprenne automatiquement, utilisez le paramètre ManualResume lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Choix des éléments à amorcer

Lors d’un amorçage, vous pouvez choisir d’amorcer la copie de la base de données de boîtes aux lettres, son catalogue d’index de contenu ou les deux. L’assistant Mise à jour de la copie de base de données et la cmdlet Update-MailboxDatabaseCopy amorceront les deux par défaut. Pour n’amorcer que la copie de base de données de boîtes aux lettres et pas le catalogue d’index de contenu, utilisez le paramètre DatabaseOnly lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy. Pour n’amorcer que le catalogue d’index de contenu, utilisez le paramètre CatalogOnly lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Sélection de la source d’amorçage

Dans Exchange 2007, la réplication continue ne pouvait amorcer une copie de base de données qu’en copiant la copie active de la base de données. Dans Exchange 2010, toute copie de base de données en bon état peut être utilisée comme source d’amorçage pour une copie supplémentaire de cette base de données. Cela s’avère particulièrement utile quand un groupe de disponibilité de base de données a été étendu sur plusieurs emplacements physiques. Par exemple, imaginez le déploiement d’un groupe de disponibilité de base de données de quatre membres, dont deux membres (MBX1 et MBX2) sont situés à Portland dans l’Oregon et deux membres (MBX3 et MBX4) sont situés à New York. Une base de données de boîtes aux lettres appelée DB1 est active sur MBX1 et des copies passives de DB1 se trouvent sur MBX2 et MBX3. Lorsque vous ajoutez une copie de DB1 à MBX4, vous avez la possibilité d’utiliser la copie sur MBX3 comme source d’amorçage, et ainsi, vous évitez d’amorcer sur la liaison WAN entre Portland et New York.

Pour utiliser une copie spécifique comme source d’amorçage lors de l’ajout d’une nouvelle copie de base de données, il faudrait procéder comme suit :

Utilisez le paramètre SeedingPostponed lors de l’exécution de la cmdlet Add-MailboxDatabaseCopy pour ajouter la copie de base de données. Si le paramètre SeedingPostponed n’est pas utilisé, la copie de base de données sera explicitement amorcée avec la copie active de la base de données comme source.
Utilisez le paramètre SourceServer lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy et indiquez le serveur source souhaité pour l’amorçage. (Dans l’exemple précédent, vous indiqueriez MBX3 comme serveur source.) Si le paramètre SourceServer n’est pas utilisé, la copie de base de données sera explicitement amorcée avec la copie active de la base de données comme source.

Amorçage et réseaux

En plus de choisir un serveur source spécifique pour l’amorçage d’une copie de base de données de boîtes aux lettres, vous pouvez aussi indiquer quels réseaux DAG vous souhaitez utiliser et éventuellement remplacer les paramètres de compression et de chiffrement du réseau DAG pendant l’opération d’amorçage.

Pour indiquer les réseaux que vous souhaitez utiliser pour l’amorçage, utilisez le paramètre Network lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy et indiquez les réseaux DAG que vous voulez utiliser. Si vous n’utilisez pas le paramètre Network, le système utilise la procédure par défaut pour le choix du réseau à utiliser pour l’amorçage :

Si le serveur source et le serveur cible sont sur le même sous-réseau et qu’un réseau de réplication a été configuré incluant le sous-réseau, le réseau de réplication sera utilisé.
Si le serveur source et le serveur cible sont sur différents sous-réseaux, même si un réseau de réplication contenant ces sous-réseaux a été configuré, le réseau client (MAPI) sera utilisé pour l’amorçage.
Si le serveur source et le serveur cible se trouvent dans des centres de données différents, le réseau client (MAPI) sera utilisé pour l’amorçage.

Au niveau du groupe de disponibilité de base de données (DAG), les réseaux DAG sont configurés pour le chiffrement et la compression. Les paramètres par défaut n’utilisent le chiffrement et la compression que pour les communications sur un même sous-réseau. Si la source et la cible sont sur différents sous-réseaux et que le groupe de disponibilité de base de données (DAG) est configuré avec les valeurs par défaut pour NetworkCompression et NetworkEncryption, vous pouvez remplacer ces valeurs à l’aide des paramètres NetworkCompressionOverride et NetworkEncryptionOverride, respectivement, lors de l’exécution de la cmdlet Update-MailboxDatabaseCopy.

Processus d’amorçage

Lorsque vous lancez le processus d’amorçage à l’aide de la cmdlet Add-MailboxDatabaseCopy ou Update-MailboxDatabaseCopy, les tâches suivantes sont effectuées :

Les propriétés de base de données d’Active Directory sont lues pour valider la base de données et les serveurs indiqués et pour vérifier que les serveurs sources et cibles exécutent Exchange 2010, qu’ils sont tous les deux des membres du même groupe de disponibilité de base de données et que la base de données indiquée n’est pas une base de données de récupération. Les chemins d’accès aux fichiers de base de données sont également lus.
Il y a une préparation aux contrôles de réamorçage à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange du serveur cible contrôle la présence de fichiers journaux des bases de données et des transactions dans le répertoire de fichiers lu lors des contrôles Active Directory à l’étape 1.
Le service de réplication Microsoft Exchange renvoie les informations sur l’état du serveur cible à l’interface d’administration à partir de l’emplacement d’exécution de la cmdlet.
Si tous les contrôles préliminaires ont été effectués avec succès, vous serez invités à confirmer l’opération avant de continuer. Si vous confirmez l’opération, le processus se poursuit. Si une erreur se produit lors des contrôles préliminaires, elle est signalée et l’opération échoue.
L’opération d’amorçage est lancée à partir du service de réplication Microsoft Exchange sur le serveur cible.
Le service de réplication Microsoft Exchange suspend la réplication de base de données de la copie de base de données active.
Les informations sur l’état de la base de données sont mises à jour par le service de réplication Microsoft Exchange pour rendre compte de l’état de l’amorçage.
Si le serveur cible ne contient pas déjà les répertoires pour les fichiers journaux et de base de données cibles, ils sont alors créés. Si les répertoires existent et s’il y a déjà des fichiers journaux ou de base de données dans les répertoires cibles, le service de réplication Microsoft Exchange les efface.
Une demande d’amorçage de la base de données est transmise du service de réplication Microsoft Exchange du serveur cible au service de réplication Microsoft Exchange du serveur source à l’aide du protocole TCP. Cette demande et les communications qui suivent pour l’amorçage de la base de données ont lieu sur un réseau DAG qui a été configuré comme réseau de réplication.
Le service de réplication Microsoft Exchange du serveur source lance une sauvegarde en continu ESE (Extensible Storage Engine) via l’interface du service de banque d’informations Microsoft Exchange.
Le service de banque d’informations Microsoft Exchange transmet les données de la base de données au service de réplication Microsoft Exchange.
Les données de la base sont transférées du service de réplication Microsoft Exchange du serveur source au service de réplication Microsoft Exchange du serveur cible.
Le service de réplication Microsoft Exchange du serveur cible écrit la copie de la base de données dans un répertoire temporaire situé dans le répertoire principal de la base de données appelé temp-seeding.
L’opération de sauvegarde en continu sur le serveur source se termine à la fin de la base de données.
L’écriture sur le serveur cible se termine et la base de données est déplacée du répertoire temp-seeding à l’emplacement final. Le répertoire temp-seeding est supprimé.
Sur le serveur cible, le service de réplication Microsoft Exchange traite la demande et la communique au service de recherche Microsoft Exchange pour monter le catalogue d’index de contenu de la copie de base de données, s’il existe. S’il y a des fichiers du catalogue qui n’ont pas été mis à jour depuis la fois précédente sur la copie de base de données, l’opération de montage échoue, ce qui entraîne la nécessité de répliquer le catalogue du serveur source. De la même manière, si le catalogue n’existe pas et qu’il n’existe pas sur un nouvel exemplaire de la copie de base de données du serveur cible, il faut une copie du catalogue. Le service de réplication Microsoft Exchange dirige le service de recherche Microsoft Exchange pour qu’il interrompe l’indexation de la copie de base de données pendant qu’un nouveau catalogue est copié à partir de la source.
Le service de réplication Microsoft Exchange du serveur cible envoie alors une demande d’amorçage du catalogue au service de réplication Microsoft Exchange du serveur source.
Sur le serveur source, le service de réplication Microsoft Exchange demande les informations de répertoire du service de recherche Microsoft Exchange et demande la suspension de l’indexation.
Le service de recherche Microsoft Exchange du serveur source renvoie les informations du répertoire du catalogue de recherche au service de réplication Microsoft Exchange.
Le service de réplication Microsoft Exchange du serveur source lit les fichiers de catalogue du répertoire.
Le service de réplication Microsoft Exchange du serveur source déplace les données de catalogue vers le service de réplication Microsoft Exchange du serveur cible à l’aide d’une connexion sur le réseau de réplication. Une fois la lecture finie, le service de réplication Microsoft Exchange envoie une demande au service de recherche Microsoft Exchange pour qu’il reprenne l’indexation de la base de données source.
Si des fichiers de catalogue existent déjà sur le serveur cible du répertoire, le service de réplication Microsoft Exchange sur le serveur cible les supprime.
Le service de réplication Microsoft Exchange du serveur cible écrit les données de catalogue dans un répertoire temporaire appelé CiSeed.Temp jusqu’à ce que les données soient complètement transférées.
Le service de réplication Microsoft Exchange déplace les données de catalogue complètes vers l’emplacement final.
Le service de réplication Microsoft Exchange du serveur cible reprend l’indexation de recherche sur la base de données cible.
Le service de réplication Microsoft Exchange du serveur cible renvoie un état d’exécution.
Le résultat final de l’opération est transmis à l’interface d’administration à partir de laquelle la cmdlet a été exécutée.

Configuration de copies de base de données

Après la création d’une copie de base de données, vous pouvez afficher et modifier ses paramètres de configuration, si nécessaire. Vous pouvez afficher certaines informations de configuration sur la page Propriétés d’une copie de base de données dans la console de gestion Exchange. Vous pouvez aussi utiliser les cmdlets Get-MailboxDatabase et Set-MailboxDatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell pour afficher et configurer les paramètres de copie de base de données, tels que le délai d’attente de relecture, le délai d’attente de troncation et l’ordre de préférence pour l’activation. Pour obtenir la procédure détaillée d’affichage et de configuration des paramètres de copie de base de données, consultez la rubrique Configurer les propriétés des copies de la base de données de boîtes aux lettres.

Utilisation des options de délai d’attente de relecture et de troncation

Les copies de base de données de boîtes aux lettres prennent en charge l’utilisation d’un délai d’attente de relecture et d’un délai d’attente de troncation ; les deux sont définis en minutes. Le paramétrage d’un délai d’attente de relecture vous permet de renvoyer la copie de base de données à un certain moment dans le temps. Le paramétrage d’un délai d’attente de troncation vous permet d’utiliser les fichiers journaux sur une copie passive de base de données à récupérer après la perte de fichiers journaux sur la copie active de base de données.

Délai d’attente de relecture

Le délai d’attente de relecture est une propriété de la copie de base de données de boîtes aux lettres qui indique la durée, en minutes, du retard de relecture du journal de la copie de base de données. Le minuteur de retard de relecture se déclenche quand un fichier journal est répliqué dans la copie passive et passe l’inspection avec succès. En retardant la relecture des journaux de la copie de base de données, vous avez la possibilité de récupérer la base de données à un certain moment dans le temps passé.

Une stratégie qui utilise la copie de la base de données et les fonctionnalités de conservation légale dans Exchange 2010 peut apporter une protection contre une série de pannes qui seraient d’habitude à l’origine de la perte de données. Toutefois, ces fonctionnalités ne peuvent pas fournir de protection contre la perte de données en cas d’altération logique qui, bien que rare, peut entraîner une perte de données. Les copies retardées sont faites pour éviter la perte de données en cas d’altération logique. En règle générale, il existe deux types d’altération logique :

Corruption logique de la base de données Le total de contrôle des pages de la base de données correspond, mais les données sur les pages sont erronées au niveau logique. Cela peut arriver quand l’ESE tente d’écrire sur une page de base de données et, même si le système d’exploitation envoie un message de succès, soit les données ne sont pas écrites sur le disque soit elles sont écrites à la mauvaise place. Il s’agit d’un vidage perdu. Afin d’éviter la perte de données par les vidages perdus, l’ESE comporte un mécanisme de détection des vidages perdus dans la base de données ainsi qu’une fonctionnalité de mise à jour corrective (restauration d’une seule page).
Corruption logique de banque d’informations Les données sont ajoutées, supprimées ou manipulées d’une manière à laquelle l’utilisateur ne s’attend pas. Ces cas sont généralement provoqués par des applications tierces. Ce n’est généralement de la corruption que dans le sens où l’utilisateur voit cela comme une altération. La banque d’informations Exchange considère la transaction qui est à l’origine de l’altération logique comme une série d’opérations MAPI valides. Dans Exchange 2010, la fonctionnalité de conservation légale apporte une protection contre l’altération logique de la banque d’informations (car elle évite que le contenu soit supprimé définitivement par un utilisateur ou une application). Toutefois, il peut y avoir des cas où une boîte aux lettres d’utilisateur est si altérée qu’il serait plus facile de restaurer la base de données à un moment antérieur à l’altération, puis ensuite d’exporter la boîte aux lettres d’utilisateur pour récupérer les données non altérées.

La combinaison des copies de base de données, de la stratégie de rétention et de la restauration ESE des pages uniques ne laisse que les cas rares mais catastrophiques d’altération logique de banque d’informations. Votre choix d’utiliser une copie de base de données avec retard de relecture (une copie retardée) dépendra des applications tierces que vous utilisez et de l’historique de votre organisation quant à l’altération logique de banque d’informations.

Si vous choisissez d’utiliser des copies retardées, prenez en compte les conséquences suivantes lors de leur utilisation :

Contrairement à la réplication continue de secours (SCR) dans Exchange 2007, qui avait un retard de relecture de 50 fichiers journaux codés de manière irréversible, il n’y a pas de nombre de fichiers journaux retardés codés de manière irréversible. À la place, le délai d’attente de relecture est une valeur configurée par l’administrateur qui est désactivée par défaut.
Par défaut, le paramètre de délai d’attente de relecture est défini sur 0 jour et le paramètre maximal sur 14 jours.
Les copies retardées ne sont pas considérées comme des copies hautement disponibles. Elles sont plutôt prévues à des fins de récupération d’urgence pour éviter l’altération logique de la banque d’informations.
Plus le délai d’attente de relecture est important, plus le processus de récupération de base de données est long. Selon le nombre de fichiers journaux qui doivent être relus pendant la récupération, et selon la vitesse à laquelle votre matériel peut les relire, le processus peut mettre plusieurs heures à récupérer une base de données.
Nous vous recommandons de déterminer si les copies retardées sont essentielles à votre stratégie générale de récupération d’urgence. Si elles sont essentielles à votre stratégie, nous vous recommandons d’utiliser plusieurs copies retardées ou un RAID (Redundant array of independant disks) pour protéger une seule copie retardée, si vous n’avez pas plusieurs copies retardées. Si vous perdez un disque ou si une altération se produit, vous ne perdez pas votre moment retardé dans le temps.
Les copies retardées ne peuvent pas être corrigées avec la fonctionnalité de restauration de page unique ESE. Si une copie retardée rencontre une altération de page de base de données (par exemple, une erreur -1018), elle devra être réamorcée (ce qui entraînera la perte de l’aspect retardé de la copie).

L’activation et la récupération d’une copie retardée de base de données de boîtes aux lettres est un processus simple si vous voulez que la base de données relise tous les fichiers journaux et actualise la copie de la base de données. Si vous souhaitez relire les fichiers journaux jusqu’à un moment spécifique dans le temps, l’opération se complique car il vous faut manipuler manuellement les fichiers journaux et exécuter l’outil Eseutil.

Pour obtenir la procédure détaillée d’activation d’une copie retardée de base de données de boîtes aux lettres, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres retardée.

Délai d’attente de troncation

Le délai d’attente de troncation est une propriété de la copie de base de données de boîtes aux lettres qui indique le temps, en minutes, du retard de suppression de la copie de base de données après relecture du fichier journal dans la copie de base de données. Le minuteur de délai d’attente de troncation se déclenche quand un fichier journal est répliqué dans la copie passive, a passé l’inspection avec succès et a été relu avec succès dans la copie de la base de données. En retardant la troncation des fichiers journaux de la copie de base de données, vous avez la possibilité de récupérer des échecs concernant les fichiers journaux de la copie active de la base de données.

Copies de la base de données et troncation de journaux

La troncation de journaux fonctionne de la même manière dans Exchange 2010 que dans Exchange 2007. Le comportement de troncation est déterminé par les paramètres de délai d’attente de relecture et de délai d’attente de troncation de la copie.

Les critères suivants doivent être remplis pour que le fichier journal d’une copie de base de données soit tronqué lorsque les paramètres sont laissés par défaut sur 0 (désactivé) :

Le fichier journal doit avoir été sauvegardé ou la journalisation circulaire doit être activée.
Le fichier journal doit être en-dessous du point de contrôle (fichier journal minimum nécessaire pour la récupération) de la base de données.
Toutes les autres copies retardées doivent avoir inspecté le fichier journal.
Toutes les autres copies (copies non retardées) doivent avoir relu le fichier journal.

Pour la troncation d’une copie retardée de base de données, les critères suivants doivent être remplis :

Le fichier journal doit être inférieur au point de contrôle de la base de données.
Le fichier journal doit être plus ancien que ReplayLagTime + TruncationLagTime.
Le fichier journal doit avoir été tronqué sur la copie active.

Stratégie d’activation de la base de données

Les stratégies d’activation de la base de données sont des scénarios dans lesquels vous voulez créer une copie de base de données de boîtes aux lettres et éviter que le système active automatiquement cette copie en cas de panne. Par exemple :

Si vous déployez une ou plusieurs copies de base de données de boîtes aux lettres dans un centre de données secondaire ou de veille.
Si vous configurez une copie de base de données comme copie retardée à des fins de récupération.
Si vous effectuez la maintenance ou la mise à niveau d’un serveur.

Dans chacun des scénarios évoqués ci-dessus, vous avez des copies de base de données que vous ne voulez pas voir activées automatiquement par le système. Si vous voulez éviter que le système active automatiquement une copie de base de données de boîtes aux lettres, vous pouvez configurer la copie pour qu’elle soit bloquée (suspendue) à l’activation. Cela permet au système de maintenir l’actualité de la base de données par l’envoi de fichiers journaux et la relecture, mais l’empêche d’activer et d’utiliser automatiquement la copie. Les copies bloquées pour l’activation doivent être activées manuellement par un administrateur. Vous pouvez configurer une stratégie d’activation de base de données à l’aide de la cmdlet Set-MailboxServer et définir le paramètre DatabaseCopyAutoActivationPolicy sur Bloqué.

Pour plus d’informations sur la configuration des stratégies d’activation de la base de données, consultez la rubrique Configurer la stratégie d’activation pour une copie de base de données de boîte aux lettres.

Surveillance des copies de base de données

Une copie de base de données est votre premier recours en cas de panne touchant la copie active de la base de données. Il est donc essentiel de contrôler l’intégrité et l’état des copies de base de données pour s’assurer qu’elles seront disponibles, si nécessaire. Vous pouvez afficher certaines informations sur l’intégrité et l’état sur la page Propriétés d’une copie de base de données dans la console de gestion Exchange. Vous pouvez aussi utiliser la cmdlet Get-MailboxDatabaseCopyStatus dans l’environnement de ligne de commande Exchange Management Shell pour afficher les diverses informations sur l’état d’une copie de base de données.

Pour plus d’informations sur la surveillance des copies de base de données, consultez la rubrique Analyse de la haute disponibilité et de la résilience de site.

Suppression d’une copie de base de données

Une copie de base de données peut être supprimée à tout moment à l’aide de la console de gestion Exchange ou de la cmdlet Remove-MailboxDatabaseCopy dans l’environnement de ligne de commande Exchange Management Shell. Après suppression d’une copie de base de données, vous devez manuellement supprimer tout fichier journal de transaction et de base de données du serveur à partir duquel la copie de base de données est en cours de suppression. Pour obtenir la procédure détaillée de suppression d’une copie de base de données, consultez la rubrique Supprimer une copie de base de données de boîte aux lettres.

Permutation de base de données

Le serveur de boîtes aux lettres qui héberge la copie active de la base de données est le maître de la base de données de boîtes aux lettres. Le processus d’activation d’une copie passive de base de données modifie le maître de la base de données de boîtes aux lettres. Ce processus est appelé basculement de base de données. Dans un basculement de base de données, la copie active de la base de données est démontée d’un serveur de boîtes aux lettres et une copie passive de cette base est montée en tant que nouvelle base de données de boîtes aux lettres active sur un autre serveur de boîtes aux lettres. Lorsque vous effectuez un basculement, vous pouvez éventuellement remplacer les paramètres de numérotation de montage de la base de données sur le nouveau maître de la base de données de boîtes aux lettres.

Vous pouvez rapidement identifier le serveur de boîtes aux lettres qui est actuellement le maître de la base de données de boîtes aux lettres en affichant la colonne État de la copie sous l’onglet Copies de base de données dans la console de gestion Exchange. Seule la copie active présente l’état Monté. Toutes les autres copies de base de données afficheront l’état de réplication actuel pour la copie de base de données. Vous pouvez effectuer un basculement à l’aide de l’assistant Déplacement d’un maître de base de données de boîtes aux lettres dans la console de gestion Exchange ou à l’aide de la cmdlet Move-ActiveMailboxDatabase dans l’environnement de ligne de commande Exchange Management Shell.

Plusieurs vérifications internes seront effectuées avant l’activation de la copie passive :

L’état de la copie de base de données est contrôlé. Si la copie de base de données est indisponible, le basculement est bloqué. Vous pouvez modifier ce comportement et éviter le contrôle d’état en utilisant le paramètre SkipHealthChecks de la cmdlet Move-ActiveMailboxDatabase. Ce paramètre vous permet de déplacer la copie active vers une copie de base de données indisponible.
Les longueurs de la file d’attente de copie et de relecture de la copie de base de données sont contrôlées afin de veiller à ce que les valeurs correspondent aux critères configurés. De même, la copie de base de données est vérifiée pour s’assurer qu’elle n’est pas utilisée actuellement comme source d’amorçage. Si les valeurs des longueurs de file d’attente ne font pas partie des critères configurés ou si la base de données est actuellement utilisée comme source d’amorçage, le basculement est bloqué. Vous pouvez modifier ce comportement et éviter ces contrôles en utilisant le paramètre SkipLagChecks de la cmdlet Move-ActiveMailboxDatabase. Ce paramètre permet d’activer une copie disposant de files d’attente de relecture et de copie en dehors des critères configurés.
L’état du catalogue de recherche (index du contenu) de la copie de base de données est contrôlé. Si le catalogue de recherche n’est pas à jour, n’est pas en bon état ou est endommagé, le basculement est bloqué. Vous pouvez modifier ce comportement et éviter le contrôle du catalogue de recherche en utilisant le paramètre SkipClientExperienceChecks de la cmdlet Move-ActiveMailboxDatabase. Grâce à ce paramètre, la recherche n’effectue pas le contrôle d’état du catalogue. Si le catalogue de recherche de la copie de base de données que vous activez n’est pas en bon état ou est inutilisable et que vous utilisez ce paramètre pour passer le contrôle d’état du catalogue et activer la copie de base de données, il vous faudra à nouveau analyser ou amorcer le catalogue de recherche.

Lorsque vous effectuez un basculement de base de données, vous avez la possibilité de remplacer les paramètres de numérotation de montage configurés pour le serveur hébergeant la copie passive de base de données en train d’être activée. Le paramètre MountDialOverride de la cmdlet Move-ActiveMailboxDatabase donne l’ordre au serveur cible de remplacer ses propres paramètres de numérotation de montage et d’utiliser ceux indiqués par le paramètre MountDialOverride.

Pour obtenir la procédure détaillée de basculement d’une copie de base de données, consultez la rubrique Activer une copie de la base de données de boîtes aux lettres. Pour plus d’informations sur les basculements de base de données, consultez la rubrique Switchovers et basculements.

Partager via