Compréhension de l’envoi et de la réapplication asynchrones des journaux

que la charge du système le permet. En cas de panne d’un serveur, vous perdez le contenu de la mémoire du système, mais le journal des transactions demeurera intact et pourra servir à mettre à jour la base de données une fois le système de nouveau en ligne.

Exchange gère un ensemble unique de journaux pour les bases de données d’un groupe de stockage. Les journaux des transactions sont créés selon une procédure séquentielle appelée flux de journaux. Ces fichiers journaux ont désormais une taille de 1 Mo dans Exchange 2007 (contre 5 Mo dans Exchange 2003).

Cette taille réduite constitue une des modifications apportées pour permettre la réplication en continu. Un flux de journaux peut contenir au maximum 2 147 483 647 fichiers journaux. (Cette limite supérieure est liée au nombre de noms de fichiers journaux qu’il est possible de créer et non à la quantité d’espace disque sur le serveur.)

Dans Exchange 2003, les fichiers journaux sont nommés comme suit : E nn fffff.log (où nn est le préfixe modifié d’un groupe de stockage à un autre, et où fffff est limité à environ un million de journaux). Dans Exchange 2007, toutefois, la convention de nommage devient E nn ffffffff.log, d’où la possibilité de gérer 400 fois plus de données. Ainsi, même si les fichiers sont plus petits, l’extension de la convention de nommage vous permet, au final, d’ajouter plus de fichiers avant d’épuiser votre réserve de journaux.

Notez que cet aspect s’applique par groupe de stockage et non par serveur. La licence standard pour Exchange 2007 vous permet de créer un maximum de cinq groupes de stockage et de monter jusqu’à cinq bases de données. La licence entreprise, quant à elle, vous permet de créer jusqu’à 50 groupes de stockage et 50 bases de données. L’envoi des journaux est le processus par lequel les journaux sont copiés vers leur emplacement secondaire et réappliqués sur une copie de la base de données.

Vous disposez ainsi d’une sauvegarde pour le basculement (soit un serveur complet prêt à intervenir en tant que serveur actif, soit simplement un ensemble de données de basculement prêt à être employé en cas de défaillance d’un serveur unique et comportant presque toutes les données des journaux des transactions). Le qualificatif « asynchrone » s’explique par le fait qu’il existe un intervalle de temps pendant lequel un journal des transactions demeure ouvert et actif, auquel cas il ne peut être envoyé vers la copie secondaire des journaux.

Certaines données peuvent donc être perdues. Dans le cas d’une solution LCR, vous devez décider si cette perte de données est acceptable. Dans une solution CCR, un autre serveur peut contribuer à limiter la perte. Il s’agit du rôle de serveur de transport Hub et celui-ci contient une fonctionnalité intitulée « transport dumpster », laquelle conserve une quantité prédéfinie de messages transitant vers le cluster.

En cas de défaillance du noeud actif du cluster, le noeud passif prend automatiquement le relais. Par ailleurs, ce noeud passif contacte le ou les serveurs de transport Hub afin de savoir s’il existe des messages dans le transport dumpster. Le noeud passif parcourt alors les messages, vérifie dans la base de données si certains sont manquants et met au rebut les doublons.