Mise en place d'un miroir logique

version 2004.4 (Modifiée)

4D Server propose une solution intégrée permettant de mettre en place un système de sauvegarde des données par miroir logique. Cette solution est basée sur deux commandes : Nouveau fichier historique et INTEGRER FICHIER HISTORIQUE.

Le miroir logique est un mode de sauvegarde sophistiqué, principalement destiné aux bases de données critiques ou à forte charge d'exploitation.

Utiliser un miroir logique consiste à exploiter une base sur un premier poste, et à maintenir sur une deuxième machine une copie de cette base, périodiquement mise à jour. Les deux machines communiquent par le réseau, la machine en exploitation transmettant régulièrement à la machine miroir les évolutions de la base par l'intermédiaire du fichier d'historique.

De cette façon, en cas d'un incident sur la base en exploitation, il n'y a qu'à repartir de la base miroir pour reprendre très rapidement l'exploitation sans aucune perte de données. En outre, la base en exploitation n'est jamais "bloquée" par les opérations de sauvegarde.

L'emploi d'un miroir logique correspond à des besoins spécifiques. La stratégie standard basée sur une sauvegarde périodique et le fichier d'historique constitue dans la plupart des cas une solution simple, fiable et peu coûteuse. La base est sauvegardée régulièrement (toutes les 24 heures en général). Durant la sauvegarde, la base reste accessible en mode lecture seulement. Cette période d'indisponibilité partielle est très courte, et même pour les bases de données importantes (plus de 2 Go) elle ne dépasse pas 5 minutes. Cette opération peut même être programmée en-dehors des périodes d'utilisation de la base.

Cependant, pour certains organismes, comme par exemple les hôpitaux, les bases de données critiques doivent être entièrement opérationnelles 24h/24. La base ne peut pas être en lecture seulement, même durant un laps de temps très court. Dans ce cas, la mise en place d'un miroir logique est une solution adaptée.

Note : La base miroir ne reflète que les modifications apportées aux données. Ce mode de sauvegarde n'est donc pas adapté pour des bases en cours de développement, où les fréquentes modifications de structure rendront rapidement le miroir obsolète ou nécessiteront de multiples réactualisations de la structure de la base miroir.

Principes de fonctionnement

La mise en place d'un système de sauvegarde par miroir logique s'appuie sur deux commandes : Nouveau fichier historique et INTEGRER FICHIER HISTORIQUE. Ces commandes sont décrites dans le manuel Langage de 4D.

Les principes mis en oeuvre sont les suivants :

• La base est installée sur le poste 4D Server principal (poste en exploitation) et une copie identique de la base est installée sur le poste 4D Server miroir.

• Un test au démarrage de l'application (par exemple la présence d'un fichier spécifique dans le dossier 4D Extensions) permet de distinguer chaque version (en exploitation et en miroir) et donc d'exécuter les opérations appropriées.

• Sur le poste 4D Server en exploitation, le fichier d'historique est "segmenté" à intervalle régulier à l'aide de la commande Nouveau fichier historique. Aucune sauvegarde n'étant effectuée sur le serveur principal, la base est en permanence disponible en lecture-écriture.

• Chaque "segment" de fichier d'historique est envoyé sur le poste miroir, où il est intégré à la base miroir à l'aide de la commande INTEGRER FICHIER HISTORIQUE.

La mise en place de ce système nécessite la programmation de code spécifique, notamment :

• un minuteur sur le serveur principal pour la gestion des cycles d'exécution de la commande Nouveau fichier historique,

• un système de transfert des "segments" de fichier d'historique entre le poste en exploitation et le poste miroir (utilisation de 4D Internet Commands pour un transfert via ftp ou messagerie, Web Services, 4D Open pour 4D...),

• un process sur le poste miroir destiné à superviser l'arrivée de nouveaux "segments" de fichier d'historique et à les intégrer via la commande INTEGRER FICHIER HISTORIQUE,

• un système de communication et de gestion d'erreurs entre le serveur principal et le serveur miroir.

ATTENTION : La sauvegarde par miroir logique est incompatible avec les sauvegardes "standard" sur la base en exploitation car l'emploi simultané de ces deux modes de sauvegarde entraîne la désynchronisation de la base en exploitation et de la base miroir. Par conséquent, vous devez veiller à ce qu'aucune sauvegarde, automatique ou manuelle, ne soit effectuée sur la base en exploitation. En revanche, il est possible de sauvegarder la base miroir (cf. paragraphe suivant).

A compter de la version 2004.4, 4D Server permet d'effectuer des sauvegardes de la base sur le poste miroir.

Tous les moyens classiques peuvent être utilisés pour effectuer les sauvegardes sur le poste miroir : sauvegarde manuelle via la commande du menu Fichier, sauvegarde périodique définie dans les Préférences ou sauvegarde programmée à l'aide des commandes du langage.

Pour éviter tout risque de désynchronisation avec le poste en exploitation, 4D verrouille automatiquement le poste miroir lorsqu'il effectue l'une ou l'autre des deux opérations fondamentales : intégration de l'historique en provenance du poste en exploitation et sauvegarde de la base miroir.

- Lorsqu'une intégration de l'historique est en cours, il n'est pas possible de déclencher une sauvegarde. Si la commande SAUVEGARDER est utilisée, l'erreur 1417 est générée (cf. section Erreurs du gestionnaire de sauvegarde).

- Lorsqu'une sauvegarde est en cours, tous les process sont gelés, il n'est donc pas possible de démarrer une intégration d'historique.

Le scénario suivant illustre, du point de vue de chaque poste 4D Server, la mise en place d'un système de sauvegarde avec miroir :

Démarrage de l'application, sauvegarde du
fichier de données et activation (si
nécessaire) du fichier d'historique.
4D crée le fichier MaBase.4DL

On quitte l'application

Copie de tous les fichiers de la base (fichier
d'historique inclus) sur le poste miroir

Démarrage de l'application et passage en	Démarrage de l'application miroir. 4D Server
exploitation.	demande le fichier d'historique : sélection du
	fichier MaBase.4DL transféré depuis le poste
	en exploitation.

Décision de mettre à jour le miroir (par
exemple, après une certaine durée
d'exploitation)

Exécution de la méthode contenant la
commande Nouveau fichier historique. Le
fichier sauvegardé est nommé
MaBase[0001-0000].4DL

Envoi par programmation du fichier
MaBase[0001-0000].4DL au poste miroir
(utilisation de 4DIC, 4D Open pour 4D, etc.)

La base est en exploitation	Détection qu'un fichier est en attente d'intégration.
	Exécution de la méthode contenant la commande
	INTEGRER FICHIER HISTORIQUE pour intégrer le
	fichier MaBase[0001-0000].4DL. Ce fichier devient
	le nouveau fichier d'historique courant.

Incident sur le poste, la base de données
est inutilisable. Décision de passer sur la
machine miroir

Copie du fichier d'historique courant
MaBase.4DL sur le poste miroir, dans le
dossier de réception habituel

Réparation de la machine...	Détection qu'un fichier est en attente d'intégration.
	Exécution de la méthode contenant la commande
	INTEGRER FICHIER HISTORIQUE pour intégrer le
	fichier MaBase.4DL. Ce fichier devient le nouveau
	fichier d'historique courant.

La base est en exploitation

La machine est réparée On quitte la base

Remplacement des fichiers de la base par
ceux de la base miroir

Démarrage de l'application. 4D Server	Démarrage de l'application miroir.
demande le fichier d'historique : sélection
du fichier MaBase.4DL transféré depuis le
poste miroir.

La base est en exploitation

INTEGRER FICHIER HISTORIQUE, Nouveau fichier historique.