Mise en place d'un miroir logique

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 MIROIR.

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 des données 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, tous les process sont gelés. 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 ê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 cours de sauvegarde", 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.

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 MIROIR. 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 un sous-dossier de l'application 4D Server) 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 accessible 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 MIROIR.

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...),
• 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 MIROIR,
• 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 ou de mettre en place un "miroir du miroir" (cf. paragraphe suivant).

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 Propriétés de la base 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 (1401 -> 1421)).
• 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.

A compter de 4D v14, il est possible d'activer le fichier d'historique courant sur le poste miroir. Vous pouvez ainsi mettre en place un "miroir de miroir" (voire des miroirs en série), ou encore une architecture de miroirs "en étoile" (plusieurs miroirs pour une même base en exploitation). Dans le premier cas, le fichier d'historique courant du miroir est à son tour envoyé à un miroir (le "miroir du miroir") pour intégration, et ainsi de suite si vous utilisez plusieurs miroirs en série. Dans le second cas, l'historique courant est envoyé à plusieurs serveurs miroirs identiques. Ce type de redondance permet de s'assurer d'une disponibilité permanente du serveur, même en cas de défaillance simultanée du serveur et du miroir principal.

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