Miroir logique

4D Server offre une solution intégrée qui permet la mise en place d'un système de sauvegarde via un miroir logique. Cette solution est basée sur deux commandes : New log file et INTEGRATE MIRROR LOG FILE.

Qu'est-ce qu'un miroir logique ?

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

L'utilisation d'un miroir logique consiste à exploiter une application sur une machine et à en conserver une copie qui est périodiquement mise à jour sur une seconde machine. 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 l'application en exploitation, il n’y a qu’à repartir de l'application miroir pour reprendre très rapidement l’exploitation sans aucune perte de données. En outre, l'application en exploitation n’est jamais “bloquée” par les opérations de sauvegarde.

Pourquoi choisir la sauvegarde par miroir logique ?

L'utilisation d'un miroir logique correspond à des besoins spécifiques. La stratégie standard basée sur des sauvegardes périodiques et l'utilisation d'un fichier d'historique offre 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. L'application 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 appropriée.

note

La base miroir ne reflète que les modifications apportées aux données. Ce mode de sauvegarde n'est pas adapté aux projets en cours de développement, où de fréquentes modifications structurelles rendront le miroir rapidement obsolète ou nécessiteront une mise à jour répétée de la structure de la base de données miroir.

Principes de fonctionnement

Setting up a backup system using a logical mirror is based on two new commands: New log file and INTEGRATE MIRROR LOG FILE.

Les principes suivants sont mis en œuvre :

• L'application est installée sur la machine principale 4D Server (poste en exploitation) et une copie identique de l'application est installée sur la machine miroir 4D Server.
• Un test au démarrage de l'application (par exemple, pour la présence d'un fichier spécifique dans un sous-dossier de l'application 4D Server) est utilisé pour distinguer les deux versions (opérationnelle et miroir) et ainsi 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 New log file. Comme aucune sauvegarde n'est effectuée sur le serveur principal, l'application reste en permanence disponible en mode lecture-écriture.
• Chaque “segment” de fichier d’historique est envoyé sur le poste miroir, où il est intégré dans l'application miroir en utilisant la commande INTEGRATE MIRROR LOG FILE.

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 New log file,
• Un système de transfert des “segments” de fichier d’historique entre le poste en exploitation et le poste miroir (HTTP, Web Services, etc.),
• 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 INTEGRATE MIRROR LOG FILE,
• Un système de communication et de gestion d’erreurs entre le serveur principal et le serveur miroir.

attention

Un système de sauvegarde utilisant un miroir logique n'est pas compatible avec des sauvegardes régulières sur une application en cours d'utilisation puisque l'utilisation simultanée de ces deux modes de sauvegarde conduirait à la désynchronisation des applications opérationnelle et miroir. Par conséquent, vous devez vous assurer qu'aucune sauvegarde automatique ou manuelle ne sera effectuée sur l'application opérationnelle. En revanche, il est possible de sauvegarder l'application miroir ou de mettre en place un "miroir du miroir".

Sauvegarde d'un miroir et miroir de miroir

4D Server peut être utilisé pour effectuer des sauvegardes de l'application sur la machine 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 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 l'application miroir.

• Lorsqu’une intégration de l’historique est en cours, il n’est pas possible de déclencher une sauvegarde. Si la commande BACKUP est utilisée, l'erreur 1417 est générée.
• 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.

Vous pouvez activer le fichier d'historique courant sur la machine miroir, ce qui signifie que vous pouvez 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 application 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.

Scénario d'exploitation d'un miroir logique

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 :

Pas	Poste en exploitation	Poste miroir
1	Démarrage de l’application, sauvegarde du fichier de données. Le fichier d’historique est activé par défaut ; pour plus de sûreté, stocker ce fichier sur un disque dur séparé.
	4D crée le fichier MyApp.journal.
	On quitte l’application.
	Copie de tous les fichiers de la base (fichier d’historique inclus) sur le poste miroir.
2	Redémarrage de l’application et passage en exploitation (vérifier qu’il n’y a pas de sauvegarde intégrale de programmée).	Démarrage de l’application miroir. 4D Server demande le fichier journal courant : sélectionnez le fichier MyApp.journal qui a été transféré de la base de données opérationnelle. Ce fichier sera utilisé lors de la configuration d'un miroir de miroir.
3	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 New log file. Le fichier sauvegardé est nommé MyApp[0001-0001].journal.
	Envoi du fichier .journal de MyApp[0001-0001] par programmation vers la machine miroir.
	L'application est en exploitation.
4		Détection d'un fichier en attente d'intégration. Exécution de la méthode contenant la commande INTEGRATE MIRROR LOG FILE afin d'intégrer le fichier MyApp[0001-0001].journal. Si vous utilisez un miroir de miroir, exécution sur la machine miroir d'une procédure similaire à l'étape 3 (à répéter à chaque intégration d'historique).
5	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 MyApp.journal sur la machine miroir, via le dossier de destination habituel
6	Analyse de l'incident et réparation.	Détection d'un fichier en attente d'intégration. Exécution de la méthode contenant la commande INTEGRATE MIRROR LOG FILE afin d'intégrer le fichier MyApp.journal.
		L'application est en exploitation.
7	La machine est réparée. Remplacement des fichiers de la base de données par ceux de la base de données miroir. Démarrage de l'application. 4D Server demande le fichier d’historique : sélection du fichier transféré depuis le poste miroir.	On quitte l’application. Retour à l'étape 2.