|
|
|
|
|
|
|
|
|
|
- Présentation
- Mettre en place la réplication de serveurs HFSQL
- Pré-requis
- Questions fréquentes sur la réplication de serveurs HFSQL
- Lors de la mise en place d'une réplication entre des serveurs HFSQL, pourquoi les identifiants automatiques doivent-ils être sur 8 octets ?
- Pourquoi les valeurs des identifiants automatiques ajoutés après la mise en place de la réplication de serveurs sont-elles aussi élevées ?
- Quelle est la configuration réseau nécessaire pour mettre en place une réplication de serveurs ?
- J'ai modifié la structure des fichiers dans l'analyse (ajouts, modifications ou suppressions de rubriques). Comment appliquer les modifications sur des fichiers qui se trouvent sur des serveurs HFSQL avec une réplication de serveurs ?
- Réplication de serveurs : Est-ce que les transactions sont gérées sur les serveurs HFSQL ?
- Réplication de serveurs : Quelle est la sécurisation propre à la réplication de serveurs ?
- Réplication de serveurs : Comment sont exécutés les triggers serveur ?
Réplication de serveurs HFSQL
 Disponible uniquement avec ce type de connexion
La réplication entre serveurs HFSQL consiste à répliquer les données automatiquement de serveur en serveur, de manière asynchrone. Cette réplication peut également être effectuée avec un serveur SPARE. Un exemple simple : une entreprise peut disposer de plusieurs serveurs HFSQL géographiquement dispersés, par exemple, un serveur par agence. La réplication entre serveurs permet de répliquer les données de chaque serveur. Plusieurs topologies de réplication peuvent être envisagées : - la réplication linéaire : Deux serveurs ou plus sont reliés deux à deux.
- la réplication en étoile : Par exemple, un siège et des agences utilisent des serveurs HFSQL. A intervalle de temps réguliers, les agences peuvent synchroniser leurs données avec le siège.
- la réplication arborescente : Par exemple, une entreprise multi-nationale peut synchroniser ses agences par continent, puis par pays.
Dans toutes ces configurations, la réplication se définit par couple de serveurs. La réplication peut être : - mono ou bi-directionnelle.
Dans une réplication mono-directionnelle, les données ne circulent que dans un sens. Les mises à jour sont effectuées d'un serveur maître vers un serveur abonné.
Dans une réplication bi-directionnelle, les données sont synchronisées dans les 2 sens. Les mises à jour sont effectuées sur chacun des serveurs. - périodique ou continue.
Une réplication périodique est effectuée à intervalle de temps prédéfini : tous les soirs à 20h, etc.
Une réplication continue est effectuée à chaque modification de la base de données (un délai peut exister entre la modification initiale et le report sur les autres serveurs).
Mettre en place la réplication de serveurs HFSQL La mise en place de la réplication de serveurs HFSQL peut être réalisée : | Attention : La mise en place de la réplication entre plusieurs serveurs HFSQL nécessite quelques adaptations de l'application (voir paragraphe suivant).
Si ces adaptations ne sont pas réalisées, l'application risque de ne pas fonctionner correctement et des données pourront être perdues. |
La mise en place de la réplication mono-birectionnelle ou bi-directionnelle entre plusieurs serveurs HFSQL nécessite quelques adaptations de l'application. Adaptions nécessaires quelque soit le mode de réplication des serveurs (réplication spare ou non)L'application ne doit pas utiliser la fonction HRaye.
Adaptations nécessaires uniquement pour une réplication classique de serveurs HFSQL (ces adaptations ne sont pas nécessaires pour une réplication spare) : 1. Au niveau de l'analyse de l'application
Dans l'analyse, les fichiers de données pris en compte dans la réplication de serveurs HFSQL doivent posséder : - soit un identifiant automatique sur 8 octets. Si l'identifiant automatique est sur 4 octets, vous devez le modifier.
Attention : Cette modification peut entraîner des modifications au niveau du code de l'application. Par exemple, au niveau de la manipulation des identifiants de fichiers avec des variables de type entier. - Recherchez "n est un entier = fic.idauto" dans votre application pour remplacer l'entier par un entier sur 8.
- Vérifiez si vous passez vos identifiants de fichiers à des procédures qui attendent un entier. Dans ce cas, il faut soit enlever le typage dans la déclaration de la procédure, soit utiliser un entier sur 8.
- soit une clé primaire (c'est-à -dire une clé unique, simple ou composée, qui n'accepte pas de valeur nulle, et dont les composants n'acceptent pas de valeur nulle).
2. Au niveau de l'application - Il ne faut pas utiliser la fonction HRaye.
- Un fichier ne peut pas être copié s'il est répliqué : la fonction HCopieFichier ne doit pas être utilisée.
Remarque : Dans le cas d'une réplication mono-directionnelle : - la copie vers le serveur maître est interdite.
- la copie depuis le serveur maître est autorisée.
- Il n'est pas possible de restaurer un fichier répliqué : la fonction HRestaureSauvegarde ne peut pas être utilisée.
- Les clusters HFSQL ne doivent pas être utilisés sur les données répliquées.
3. Sélection des informations à répliquer : La mise en place de la réplication de serveurs diminue les performances des serveurs HFSQL. Il est conseillé de mettre en place la réplication entre les serveurs uniquement pour les fichiers de données vraiment concernés par la réplication. N'hésitez pas à exclure certains fichiers de la réplication. Attention : - La réplication bi-directionnelle entre plusieurs serveurs HFSQL nécessite l'utilisation d'adresses IP fixes ou de "reverse-DNS" : il faut pouvoir trouver le nom du serveur sur lequel la réplication a été créée.
- La communication du serveur HFSQL abonné vers le serveur HFSQL maître se fera avec l'adresse IP que le serveur maître a utilisée pour contacter l'abonné lors de la création de la réplication. Il est possible de connaître cette adresse IP (utilisée par le serveur abonné pour contacter le serveur maître) via le Centre de Contrôle HFSQL du serveur abonné, dans la configuration de la réplication (champ "Serveur destination").
Questions fréquentes sur la réplication de serveurs HFSQL Lors de la mise en place d'une réplication entre des serveurs HFSQL, pourquoi les identifiants automatiques doivent-ils être sur 8 octets ? Lorsque la clé primaire est un identifiant automatique, le serveur doit s'assurer de l'unicité des identifiants sur l'ensemble des serveurs de la réplication. Pour cela, chaque serveur de réplication utilise une plage de valeurs différentes pour les identifiants automatiques des enregistrements qu'il crée. Pour que chaque serveur dispose de plages d'identifiants automatiques suffisamment grandes, les identifiants automatiques doivent être sur 8 octets. Pourquoi les valeurs des identifiants automatiques ajoutés après la mise en place de la réplication de serveurs sont-elles aussi élevées ? Chaque serveur pris en compte dans la réplication possède une plage d'identifiants automatiques différente basée sur l'identifiant du serveur de réplication. La première plage d'identifiants automatiques (celle qui part de 0) ne sera utilisée par aucun serveur pris en compte dans la réplication : cette plage d'identifiants est réservée aux données existantes au moment de la mise en place de la première réplication. Donc, dès qu'un nouvel enregistrement est créé dans une réplication de serveurs, si le fichier possède un identifiant automatique, la valeur de cet identifiant sera une valeur élevée. Quelle est la configuration réseau nécessaire pour mettre en place une réplication de serveurs ? La réplication de serveurs utilise le port 4996 pour effectuer les transferts de données. - Dans le cas d'une réplication bidirectionnelle, le port 4996 doit être ouvert sur les deux serveurs (maître et abonné).
- Dans le cas d'une réplication monodirectionnelle ou d'un réplication de type spare, ce port 4996 peut être ouvert uniquement sur le serveur abonné ou le serveur spare.
J'ai modifié la structure des fichiers dans l'analyse (ajouts, modifications ou suppressions de rubriques). Comment appliquer les modifications sur des fichiers qui se trouvent sur des serveurs HFSQL avec une réplication de serveurs ? Il suffit d'appliquer la modification de structure (modification automatique des données) sur le serveur de réplication maître. Cette modification automatique des données peut être exécutée : - depuis l'éditeur d'analyses,
- lors de l'installation de l'application
- par programmation.
Lors de la prochaine synchronisation des données entre les serveurs, la modification de la structure des fichiers sera automatiquement appliquée sur les serveurs HFSQL abonnés. Les procédures stockées et les triggers serveur seront également mis à jour lors de cette synchronisation. Réplication de serveurs : Est-ce que les transactions sont gérées sur les serveurs HFSQL ? Lorsque des enregistrements sont modifiés, ajoutés ou supprimés en transaction sur un serveur HFSQL en mode réplication, les enregistrements sont répliqués sur les serveurs abonnés uniquement lorsque la transaction est validée. En cas d'annulation de la transaction (rollback), aucune réplication ne sera effectuée pour les enregistrements concernés. En cas de validation de la transaction, l'ensemble des opérations en transaction seront transmises aux serveurs répliqués. Réplication de serveurs : Quelle est la sécurisation propre à la réplication de serveurs ? La communication entre les serveurs est authentifiée. Elle est également cryptée. Réplication de serveurs : Comment sont exécutés les triggers serveur ? Un trigger serveur associé à la mise à jour d'un fichier de données est exécuté uniquement sur le serveur HFSQL pour lequel la fonction qui déclenche le trigger est appelée. Tous les enregistrements modifiés sont synchronisés par la réplication de serveurs. Ainsi, si un trigger serveur apporte des modifications dans les données, elles seront automatiquement reportées sur les serveurs répliqués sans avoir à exécuter les triggers sur les serveurs répliqués.
Documentation également disponible pour…
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|