{"id":149129,"date":"2023-09-19T03:07:22","date_gmt":"2023-09-19T03:07:22","guid":{"rendered":"https:\/\/www.stellarinfo.com\/blog\/?p=149129"},"modified":"2023-09-19T03:20:04","modified_gmt":"2023-09-19T03:20:04","slug":"reinitialiser-une-copie-de-base-de-donnees-qui-a-echoue-dans-le-serveur-exchange","status":"publish","type":"post","link":"https:\/\/www.stellarinfo.com\/blog\/fr\/reinitialiser-une-copie-de-base-de-donnees-qui-a-echoue-dans-le-serveur-exchange\/","title":{"rendered":"Comment r\u00e9affecter les donn\u00e9es apr\u00e8s l’\u00e9chec et la suspension de la copie de la base de donn\u00e9es de la bo\u00eete aux lettres ?"},"content":{"rendered":"

Sur un serveur Exchange autonome, il ne suffit pas d’assurer la continuité des activités. Pour répondre aux exigences de basculement et de continuité des activités, vous pouvez utiliser les groupes de disponibilité des bases de données (DAG) de Microsoft pour vous assurer que votre serveur Exchange continue de fonctionner si l’une des instances tombe en panne. Pour que cela fonctionne, vous devez disposer d’au moins deux serveurs pour réaliser un DAG, avec Microsoft Exchange Server Standard ou Enterprise. La décision d’opter pour l’édition Standard ou Enterprise dépend entièrement de la conception et du volume de vos boîtes aux lettres.<\/p>

Si vous n’avez pas besoin de plus de cinq bases de données de boîtes aux lettres, vous pouvez opter pour l’édition Standard. En ce qui concerne les licences, vous devez acheter Exchange Server Standard\/Enterprise pour chaque serveur. En ce qui concerne les licences d’accès client (CAL), vous ne devez les acheter qu’une seule fois.<\/p>

Un groupe de disponibilité de base de données (DAG) typique, avec deux serveurs Exchange et un serveur File Share Witness, ayant un quorum et une majorité de vote, est illustré ci-dessous.<\/p>

\"Groupe<\/figure>

Lorsque vous créez des groupes de disponibilité de base de données (DAG), vous disposez d’une copie d’une base de données sur un serveur et d’une copie passive sur un autre serveur. Ainsi, la copie active est toujours celle à laquelle on accède et l’autre base de données est répliquée à partir d’elle.<\/p>

Dans l’illustration ci-dessous, vous pouvez voir qu’il y a deux bases de données où la copie active de DB1 se trouve sur le serveur EX01 et la copie passive sur le serveur EX02. La copie active de DB2 se trouve sur le serveur EX02 et la copie passive sur le serveur EX01.<\/p>

\"les<\/figure>

Lorsque vous ajoutez une nouvelle base de données de boîtes aux lettres à un groupe de disponibilité des bases de données (DAG), vous devez d’abord effectuer une copie sur le deuxième serveur (dans le cas de notre illustration, il s’agit de EX02). Une fois que la copie complète, appelée première graine, est terminée, le groupe de disponibilité des bases de données (DAG) continue à reproduire toutes les modifications. Vous pouvez également effectuer cette opération en prenant une copie de la base de données et en la copiant sur le serveur secondaire. Tout dépend de la taille et de la vitesse du réseau entre les deux nœuds.<\/p>

Parfois, en raison de problèmes matériels ou logiciels, vous devez réensemencer la base de données. Cela peut être dû à des informations corrompues sur la copie de la base de données ou à une erreur sur la base de données qui a rendu la copie inutilisable par le groupe de disponibilité de la base de données (DAG).<\/p>

Pendant l’ensemencement, vous pouvez rencontrer un problème avec la base de données passive et l’ensemencement s’arrête avec l’erreur “Mailbox Database Copy Failed or Suspended” (Échec ou suspension de la copie de la base de données de la boîte aux lettres). Après investigation, vous trouverez le message suivant dans l’observateur d’événements.<\/p>

MSExchangeRepl ID de l’événement : 4113<\/p>

Le contrôle de redondance de la base de données a échoué. Copie de la base de données : DB01 Nombre de redondances : 1<\/p>

Erreur : La copie passive ‘DB01\\EX02’ n’est pas en bon état. Statut : Échec et suspension<\/p>

\"Échec<\/figure>

Pour commencer le dépannage, vous devez d’abord obtenir l’état de la copie à partir de l’Exchange Management Shell (EMS) en utilisant la cmdlet PowerShell – Get-MailboxDatabaseCopyStatus.<\/p>

\"MailboxDatabaseCopyStatus\"<\/figure>

Pour comprendre la cause première du problème, vous pouvez utiliser l’analyseur de bonnes pratiques Exchange sur les serveurs. À partir de l’Exchange Management Shell (EMS), exécutez Test-ServiceHealth et Test-ReplicationHealth. Cela vous permettra de savoir si tous les services nécessaires sont en cours d’exécution. Bien entendu, vous pouvez également effectuer un autocontrôle sur les serveurs Exchange.<\/p>

\"Exchange<\/figure>

Essayons de réparer la base de données en suspendant la copie entre la base de données active et la base de données passive. Cela peut être fait en utilisant la commande Suspend-MailboxDatabaseCopy.<\/p>

Suspend-MailboxDatabaseCopy -Identity “DB01\\EX01”<\/p>

\"MailboxDatabaseCopy<\/figure>

C’est ici que vous pouvez enquêter sur la question. Vous devez réensemencer la base de données. Pour commencer, vous devez supprimer toutes les copies de la base de données. Vous pouvez utiliser la cmdlet PowerShell Update-MailboxDatabaseCopy avec l’option -DeleteExistingFiles pour nettoyer la configuration et supprimer les copies. Un exemple de commande est donné ci-dessous :<\/p>

Update-MailboxDatabaseCopy -Identity “DB01\\EX01” -DeleteExistingFiles<\/p>

\"DeleteExistingFiles\"<\/figure>

Cette opération permet de réensemencer la base de données de la copie active à la copie passive.<\/p>

Quelques éléments à prendre en compte avant de lancer le processus de réensemencement :<\/p>