DOCUMENTATION EN LIGNE
DE WINDEVWEBDEV ET WINDEV MOBILE

Aide / WLangage / Gestion des bases de données / HFSQL / Gestion de la réplication / Réplication universelle
  • Présentation
  • Mettre en place la réplication universelle
  • Fonctionnement de la réplication
  • Structure de la base de données
  • Etape 1 : Mise en place sur le site maître
  • Etape 2 : Préparation des données du site abonné
  • Etape 3 : Mise en place sur le site abonné
  • Etape 4 : Synchronisation initiale des sites maître et abonnés
  • Etape 5 : Synchronisations quotidiennes
  • Remarques
  • Limitations
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaEtats et RequêtesCode Utilisateur (MCU)
WEBDEV
WindowsLinuxPHPWEBDEV - Code Navigateur
WINDEV Mobile
AndroidWidget AndroidiPhone/iPadWidget IOSApple WatchMac CatalystUniversal Windows 10 App
Autres
Procédures stockées
Présentation
Le but de la réplication universelle est de conserver plusieurs bases de données synchronisées. Ces bases de données peuvent être de types différents. Il est par exemple possible de réaliser une réplication :
  • entre une base de données HFSQL Classic et une base de données Oracle.
  • entre des bases de données HFSQL Classic ou HFSQL Client/Serveur.
  • etc.
La réplication universelle utilise un modèle centralisé : toutes les bases de données se synchronisent avec une base de données maître. La base de données maître répercute ensuite les modifications vers les autres bases de données.
Pour mettre en place simplement la réplication universelle, il est conseillé d'utiliser la réplication universelle assistée.
Remarque : La réplication universelle est disponible pour la réplication des données mobiles (Android ou iOS). Pour plus de détails, consultez Réplication des données mobiles (Android ou iOS).
La réplication universelle utilise plusieurs types de fichiers :
  • Fichier .rpm : fichier permettant de décrire une base maître et les bases qui lui sont abonnées. Contient le nom du fichier ".syn" pour chaque abonné. Ce fichier est un fichier texte. Il est créé et stocké sur le poste qui servira à se connecter à la base maître.
  • Fichier .rpl : fichier décrivant une base abonnée. Pour chaque base abonnée, un fichier "rpl" est créé. Ce fichier est présent sur le poste abonné. Contient le nom du fichier ".syn" de l'abonné. Ce fichier est un fichier texte. Il est créé sur le poste maître puis transféré sur le poste abonné.
  • Fichier .rpa : fichier journal contenant les informations de réplication. Ce fichier est échangé entre la base de données maître et la base de données abonnée. Ce fichier est créé par la fonction HCréeRéplicaTransportable et il est lu et détruit par la fonction HSynchroniseRéplica. Le contenu est incrémentiel : s'il y a deux HCrééRéplicaTransportable dans le même sens effectués à la suite alors le second fichier contiendra l'équivalent du premier en ajoutant les modifications récentes. Si un ".rpa" est "perdu", il suffit de le refaire : il contiendra toutes les modifications. Si plusieurs fichiers "rpa" sont présents sur l'abonné, il suffit d'exécuter le dernier. Ce fichier est dans un format binaire.
  • Fichier .syn : fichier contenant les informations sur la situation de la base distant. Ce fichier permet d'optimiser la taille des fichiers de synchronisation. Ce fichier est présent sur le poste maître et sur chaque poste abonné. Ce fichier est dans un format binaire.
Mettre en place la réplication universelle

Fonctionnement de la réplication

Structure de la base de données

La mise en place d'une réplication universelle ne nécessite pas de modifications de structure sur les bases de données HFSQL (Classic ou Client/Serveur).
En revanche, pour mettre en place la réplication universelle sur des bases de données différentes (Oracle, etc.), il est nécessaire de créer une rubrique de type DateHeure dans chaque fichier pris en compte par la réplication. Cette rubrique devra être mise à jour par l'application lors de la modification ou lors de l'ajout d'un enregistrement.
Si les bases de données utilisent différents fuseaux horaires, il est conseillé d'utiliser un format universel (date et heure GMT par exemple).
Plusieurs fonctions spécifiques peuvent également être utilisées lors de la mise en place de la réplication universelle sur des bases de données non HFSQL :
HRplDéclareLiaisonPermet de signaler au moteur de réplication une liaison entre deux fichiers. Le moteur suivra alors la liaison pour obtenir la liste des enregistrements à répliquer dans le second fichier.
HRplGestionFichierDéfinit les options utilisées pour la réplication universelle d'un fichier.
HRplGestionRubriqueDéfinit les options utilisées pour la réplication universelle d'une rubrique.
HRplProcédureFiltrePermet de spécifier une procédure de filtrage spécifique lorsqu'un fichier donné sera répliqué.
Pour connaître la liste complète des fonctions permettant de gérer la réplication universelle, consultez Fonctions de réplication.

Etape 1 : Mise en place sur le site maître

Cette étape permet de créer la base de données principale de l'application. Cette étape doit se faire à la première exécution du programme (ou au travers d'un programme spécifique dédié à l'administrateur).
  1. Pour activer la réplication universelle, il suffit d'utiliser la fonction HGèreRéplication avec la constante rplRéplicationUniverselle.
    HGèreRéplication(rplRéplicationUniverselle)

    Cette fonction permet de désactiver le mode de réplication standard (s'il était actif) et d'activer la réplication universelle.
  2. Création du répertoire d'accueil des données (optionnel)
    Vous pouvez créer un répertoire qui recevra les fichiers de la base de données. Ce répertoire sera partagé sur le serveur du site maître pour que les utilisateurs puissent accéder aux données.
    // Création du répertoire des données
    fRepCrée(gsRépertoireMaître)
    // Connexion à cet emplacement
    HOuvreConnexion(ConnexionMaître)
    HChangeConnexion(CLIENT, ConnexionMaître)
  3. Création des fichiers de données de l'application (optionnel)
    Si les fichiers de données n'existent pas, vous pouvez créer les fichiers de données vides (fonction HCréation). Ces données seront manipulées par les utilisateurs du site maître.
  4. Création du réplica maître
    Pour déclarer la base maître, il suffit d'utiliser la fonction HCréeRéplicaMaître.
    HCréeRéplicaMaître(gsRépertoireMaître)

    Cette ligne de code crée le fichier "RéplicaMaître.rpm" sur le disque. Il ne reste plus qu'à inscrire les abonnés dans ce fichier.

Etape 2 : Préparation des données du site abonné

Cette étape permet de créer une seconde base de données. Cette étape est réalisée sur le site "maître". Cette étape doit se faire grâce à une option spécifique de l'application (ou au travers d'un programme spécifique dédié à l'administrateur).
  1. Création d'un répertoire d'accueil des données (optionnel)
    Vous pouvez créer un répertoire qui recevra les fichiers de la base de données.
  2. Création du réplica abonné
    Pour créer un nouvel abonné, utilisez la fonction HCréeRéplicaAbonné. Cette fonction crée un abonné (fichier "rpl") avec le nom fourni. Cette fonction renvoie également un numéro d'abonné.
    Dès sa création, l'abonné est prêt à recevoir les données du réplica maître qui a permis de l'initialiser. Cette première synchronisation permet d'obtenir un contenu de l'abonné identique à celui du maître.
    // Création du réplica abonné
    HCréeRéplicaAbonné(gsRepertoireMaître, gsRepertoireAbonne, ...
    "Abonné1", 0, "Client" + TAB + "IDDATEHEURE")

    Dans cet exemple, la rubrique "IDDATEHEURE" correspond à une rubrique de type "DateHeure" dont la base de données doit disposer (cas d'une base non HFSQL Classic ou Client/Serveur). Cette rubrique devra être mise à jour par l'application lors de la modification ou lors de l'ajout d'un enregistrement. Si les bases de données utilisent différents fuseaux horaires, il est conseillé d'utiliser un format universel (date et heure GMT par exemple).
    Cette rubrique n'est pas nécessaire dans le cas d'une base de données HFSQL Classic ou Client/Serveur.
    Remarque : Un paramètre de la fonction HCréeRéplicaAbonné permet d'indiquer si la modification automatique des données doit être prise en compte. Pour plus de détails, consultez Les remarques.
Exemple : Gestion d'une rubrique spécifique pour la réplication entre une base de données HFSQL Classic et une base de données MySQL :
Un trigger est mis en place pour renseigner automatiquement la rubrique "Rub_DateHeure" présente dans la base MySQL :
  • Code du trigger :
    ResultatTrigger est un booléen
    ResultatTrigger = HDécritTrigger("*", "HAJOUTE,HMODIFIE,HSUPPRIME,HRAYE,HECRIT", ...
    		"AjoutDateHeure",hTriggerAvant)
    SI ResultatTrigger = Faux ALORS Erreur(HErreurInfo())
  • Procédure appelée par le trigger :
    PROCÉDURE AjoutDateHeure()
    TestReplic.Rub_DateHeure = DateSys() + HeureSys()

Etape 3 : Mise en place sur le site abonné

  1. Lorsque les données sont "préparées" pour le site abonné (fichiers ".rpl", ".syn"), il suffit d'activer le mécanisme de réplication sur le site abonné (fonction HGèreRéplication).
    HGèreRéplication(rplRéplicationUniverselle)
  2. Le site abonné doit créer sa base de données vierge (fonction HCréation) avant la première synchronisation :
    HCréation(CLIENT)

    Cette base de données sera initialisée lors de la première synchronisation.

Etape 4 : Synchronisation initiale des sites maître et abonnés

Cette étape est nécessaire au bon fonctionnement de la réplication universelle. Grâce à la synchronisation initiale, la base abonnée va contenir toute ou partie de la base maître (avant la mise en exploitation de l'abonné).
  1. Création d'un réplica transportable :
    A partir de la base maître, un réplica transportable va être créé. il va contenir les données de la base depuis laquelle le réplica maître a été créé. Cette opération est réalisée grâce à la fonction HCréeRéplicaTransportable. La fonction HCréeRéplicaTransportable crée un fichier journal (fichier ".rpa").
    HCréeRéplicaTransportable(sReplicaMaître, "Maitre","")
  2. Intégration du réplica transportable dans la base abonnée :
    Les données de la base maître sont importées dans la base abonnée grâce à la fonction HSynchroniseRéplica.
    sReplicaTransportable = gsRépertoireMaître + RPL.Fichier
    HSynchroniseRéplica(sReplicaTransportable, ...
    	gsRepertoireAbonne + "Replica_Abonne1.rpl", rplVersAbonné)
    fSupprime(sReplicaTransportable)
  3. La création de l'abonné est terminée. Il est alors possible de transporter les fichiers de l'abonné sur le site d'exploitation de l'abonné. Cette opération peut être effectuée par un moyen de copie quelconque, le tout étant de créer une base vide, et d'effectuer une première réplication sur le site.
Attention :
  • Dès qu'un réplica abonné a été initialisé, il ne faut plus remplacer/restaurer l'un des fichiers maître (car ils contiennent des informations relatives aux plages d'identifiants des réplicas abonnés).
  • Tous les fichiers d'une base de données ne doivent pas obligatoirement être répliqués. Répliquez uniquement les fichiers de données nécessaires.

Etape 5 : Synchronisations quotidiennes

Lorsque la synchronisation initiale est réalisée, le mécanisme de réplication est dans son mode de fonctionnement "Normal".
Pour synchroniser une base de données, il suffit de :
  1. Générer un réplica transportable (fonction HCréeRéplicaTransportable).
  2. Transmettre le réplica transportable au site concerné (maître ou abonné).
  3. Synchroniser la base de données à l'aide du réplica transportable grâce à la fonction HSynchroniseRéplica.
Ces opérations peuvent être initiées depuis le site "Maître" ou depuis les sites "Abonnés".
Il est possible de paramétrer le type de réplication mis en place afin de définir le fonctionnement de la réplication. Les différents types de réplications sont les suivants :
  • rplMaîtrePrioritaire : ce mode de réplication est le mode par défaut. Il permet de protéger la base de données du site "maître" des modifications apportées sur le site "abonné". Les modifications effectuées sur les sites abonnés ne seront donc pas propagées dans ce mode (seuls les ajouts seront propagés).
  • rplAbonnéPrioritaire : ce mode de réplication rend le ou les sites abonnés prioritaires par rapport au site maître. Dans ce mode, le site maître n'est qu'une copie des différents abonnés mais ne propage pas les modifications entre les différents abonnés.
  • rplPlusRécentPrioritaire : ce mode permet de propager toutes les modifications effectuées sur les bases de données. Ce mode de fonctionnement est celui à utiliser dans le cas où toutes les bases de données ont la même priorité (les modifications effectuées sont propagées sur toutes les bases de données).
Il est bien entendu possible de définir une procédure personnalisée de réplication : vous pouvez ainsi définir les priorités utilisées lors du mécanisme de synchronisation.
Remarques
  • Vérifiez les fichiers répliqués. Tous les fichiers d'une base de données ne doivent pas obligatoirement être répliqués. Répliquez uniquement les fichiers de données nécessaires.
  • Les échanges de fichiers ".rpa" ne sont pas obligatoirement symétriques : il est possible de créer et d'exécuter plusieurs journaux dans un sens sans créer ni exécuter un seul journal dans l'autre sens. Cependant, pour optimiser les performances, il est conseillé d'éviter d'effectuer des échanges toujours dans le même sens.
  • La réplication respecte les filtres posés sur les tables ou les fichiers (sauf dans le cas de liaisons, pour respecter l'intégrité).
  • Un filtre peut être mis en place du coté du maître : les abonnés recevront alors un sous-ensemble des données de la base maître. Dans ce cas, il n'est pas nécessaire de mettre en place un filtre du coté de la base abonnée.
    Si par le filtre, un enregistrement n'est plus "visible" sur la base de données maître, cet enregistrement sera considéré comme supprimé. Il sera alors automatiquement supprimé sur le poste abonné.
  • La fonction HRecréeRéplicaAbonné permet de recréer un réplica abonné à partir du réplica maître.
  • Prise en compte de la modification automatique des données (bases de données HFSQL Classic ou Client/Serveur) :
    Lors de la création du réplica abonné avec la fonction HCréeRéplicaAbonné, il est possible d'indiquer si la modification automatique des données doit être effectuée lors de la réplication. Dans ce cas :
    • Une modification de la structure de la base de données maître sera reportée sur la base de données abonnée. Cette opération sera effectuée lors de la réplication.
      Attention : Cette opération peut augmenter de façon significative le temps nécessaire à la réplication.
    • Les nouvelles rubriques seront prises en compte par la réplication.
    Remarques :
    • Le mécanisme ne fonctionne pas en cas d'ajout ou de suppression d'une clé unique.
    • Pour une réplication existante, il est nécessaire de recréer cette réplication (et notamment les abonnés) pour prendre en compte cette fonctionnalité.
Limitations
  • Chaque fichier ou table doit avoir au moins une rubrique clé unique.
  • Il est nécessaire de pouvoir dater un enregistrement. Si la rubrique permettant de dater l'enregistrement est remplie automatiquement par un trigger, ce trigger doit être désactivé durant l'exécution de la fonction HSynchroniseRéplica (pour éviter de remplir cette rubrique avec la date de réplication).
    Remarque : Pour les bases de données HFSQL (Classic ou Client/Serveur), la rubrique permettant de dater l'enregistrement est automatiquement gérée.
  • La réplication n'ouvre pas les fichiers ou les tables. Les fichiers ou les tables doivent avoir été ouverts par le programme avant de lancer la réplication.
  • Pendant la réplication, l'occupation mémoire peut être très importante. Il est donc conseillé de répliquer uniquement les enregistrements nécessaires vers un poste abonné.
  • Attention : cas spécifique : une partie seulement des tables reliées n'est pas répliquée. Dans ce cas, la réplication rejoue parfois certaines modifications comme un couple {ajout, suppression}. Si une table (non répliquée) est reliée avec l'option de modifications en cascade, les enregistrements reliés risquent d'être supprimés abusivement.
  • La réplication ne sera pas effectuée dans le cas suivant : un des fichiers à répliquer est sécurisé, protégé par un mot de passe et il est utilisé dans une liaison comprenant des règles d'intégrité.
Liste des exemples associés :
WD Réplication Universelle Exemples didactiques (WINDEV) : WD Réplication Universelle
[ + ] Cet exemple montre comment synchroniser les données de différents sites en utilisant la réplication universelle.
La réplication universelle permet depuis les traitements d'une application de synchroniser les données d'un site (maître), avec les mêmes données d'un ou plusieurs autres sites (abonnés). Les structures des données sont identiques sur chaque site, mais peuvent être exploitées via différents gestionnaires de données. Pour l'exemple HFSQL classic et Access sont utilisés.
L'exemple présente de façon didactique les traitements à placer dans vos applications pour permettre à l'utilisateur par une simple action (menu, bouton...) de :
- créer un réplica maître,
- créer un ou plusieurs réplicas abonnés,
- consulter / modifier les données de ces réplicas,
- exporter les données nouvellement créées ou modifiées sur un site (réplica transportable),
- importer les données créées ou modifiées sur un autre site...
Version minimum requise
  • Version 10
Documentation également disponible pour…
Commentaires
Cliquez sur [Ajouter] pour publier un commentaire

Dernière modification : 20/03/2024

Signaler une erreur ou faire une suggestion | Aide en ligne locale