1. Lorsqu'une opération apparaît, la page de données est lue depuis le disque (Ou la mémoire si celle ci se trouve en cache). Elle est alors placée
au sein du cache ESE. Pendant ce temps, la mémoire tampon du journal est notifiée et enregistre cette opération en mémoire.
2. Les modifications sont alors apportées sur la base de données mais ne sont pas écrites immédiatement sur disque. Ces dernières reposent toujours dans le cache ESE. Elles sont nommées Dirty Page car elles ne sont pas encore "commitées" dans le fichier de base de données.
3. Une fois les pages modifiées, la mémoire cache des journaux est notifiée et valide les opérations de changement. Les données changées sont alors enregistrées dans le fichier journal. Si celui ci atteint une taille supérieure à 1MB, le journal est fermé et un nouveau journal est créé.
4. Les pages de bases de données sont écrites sur le disque
5. Le point de validation est ensuite avancé.
Une fois ces 5 étapes réalisées, c’est au tour des fonctions du service de réplication de se mettre en route. Le service de réplication installé sur chaque serveur possédant le rôle de boîte aux lettres, va alors détecter la fermeture d’un journal de transaction, va ensuite le copier, l’inspecter et le rejouer sur la base de données de secours mais nous allons le voir, sans omettre quelques vérifications de principe.
Le service de réplication comporte en fait 7 sous services présentés ci-dessous qui vont jouer chacun leurs rôles. Tous ne seront pas utilisés régulièrement comme c’est le cas pour les processus de renvoi incrémental ou global. Vous voulez savoir comme cela fonctionne intrinsèquement ? Alors allons y !
Etape 1 : Génération
Lorsque qu’un fichier journal est clôturé au sein du répertoire source, la valeur LastlogNotified est modifiée en conséquence avec la dernière génération de journal qui aura été constatée dans le répertoire source. Le processus Store.exe met à jour cette valeur au sein de la base de données cluster ou dans la base de registre toute les 20 secondes. Le service de réplication sur la cible est attentif aux notifications de changement du système de fichiers et met à jour son propre compteur. Si sur la cible, le service de réplication n’est pas en état de marche, alors la valeur LastLogGenerated sera utilisée.
Etape 2 : Recopie
Le service de réplication sur la cible utilise un processus appeler logcopier afin de tirer les fichiers sur le serveur cible en utilisant le protocole SMB (Protocole amélioré dans Windows 2008 Server). Les fichiers ainsi copiés sont alors positionnés dans le répertoire d’inspection existant pour chaque groupe de stockage. La valeur LastLogCopier est alors mise à jour lors de cette opération.
Etape 3 : Inspection
Les fichiers journaux sont alors inspectés par le processus Log Inspector puis déplacés vers le répertoire des journaux de la base passive. La valeur Last LogInspected est alors également mise à jour. Si l’opération de copie ou d’inspection échoue pour x raisons, le service de réplication tentera de recopier le journal en question et ceci trois fois de suite. Si cela est impossible, le fichier journal sera déclaré irrécupérable et une synchronisation de bases de données sera alors nécessaire. (Reseed).
Le processus d’inspection utilise la commande ESEUTIL /K sur le fichier en question et vérifie également le contenu de l’entête de ce dernier en vérifiant que la valeur de génération n’est pas supérieure à la valeur constatée pour le groupe de stockage en question et que la génération enregistrée dans l’entête correspond au nom du fichier. Juste au cas où l’on viendrait positionner un journal étranger 😉
NOTE : Avant que le journal inspecté ne soit déplacé vers le répertoire de journal pour y être rejoué, le service de réplication doit supprimer les fichiers Exx.log. Ses fichiers sont placés dans un autre répertoire de journal (ExxOutOfDate). Un journal du type Exx.log n’existera que si le serveur cible été à un moment donné utilisé comme source. Ces fichiers doivent d’ailleurs être supprimés avant que la réplication ne démarre car ils contiennent des données anciennes qui peuvent venir se superposer avec des journaux de même génération.
Etape 4 : on rejoue
Le journal, une fois l’inspection passée est alors après une série de tests, rejoué par le service de réplication via le processus LogReplayer. La valeur LasLogReplayer est alors modifiée une fois que le journal a correctement été rejoué.
