La plupart des installations Actian Ingres en production nécessitent un certain niveau de reprise après sinistre DR). Les options vont de l'envoi quotidien de points de contrôle de la base de données vers des sites de stockage hors site à la réplication en temps quasi réel vers un site de reprise après sinistre dédié situé hors site.    

La base de données hybride d'entreprise Actian Ingres intègre des fonctionnalités de point de contrôle et de transfert de journaux qui constituent les éléments de base nécessaires à la mise en place de solutions de reprise après sinistre (DR) efficaces et économiques. IngresSync, par exemple, exploite Fonctionnalités natives de point de contrôle et de transfert de journaux d'Actian Ingres, ainsi que Fonctionnalités de mise à jour incrémentielle, Fonctionnalités mettre en œuvre une solution de reprise après sinistre (DR) économique. 

ingressync

IngresSync repose sur le concept d'installations Actian Ingres source et cible. L'installation source correspond à l'environnement de production actuellement actif. La cible, ou les cibles multiples si nécessaire, est mise à jour par une tâche IngresSync programmée pour s'exécuter à un intervalle utilisateur. Chaque opération de synchronisation ne copie que les journaux créés depuis la synchronisation précédente et applique ces transactions aux cibles. Les points de contrôle enregistrés sur le nœud source sont automatiquement copiés et mis à jour sur toutes les cibles.

Exemple

Imaginons un environnement dans lequel l'installation de production est hébergée sur le nœud « corp » et où nous devons créer deux sites de reprise après sinistre, « dreast » et « drwest ».

Chaque nœud DR a besoin de :

  • Une installation d'Ingres correspondant à la même version et au même niveau de correctifs que celle de l'entreprise.
  • Le protocole SSH sans mot de passe a été configuré pour les communications avec les autres nœuds.
  • Enregistrements Ingres/Net VNODE vers les autres nœuds.

Nœuds DR pour Ingress

Pour configurer cet environnement, nous devons d'abord désigner les hôtes source et cible, puis appliquer le dernier point de contrôle source aux cibles.

ingresSync --source=corp --target=dreast,drwest --database=corpdb --iid=II --ckpsync --restart

hôtes source et destination pour Ingress

Les deux installations cibles sont désormais synchronisées avec la source, et les bases de données cibles se trouvent en état de mise à jour incrémentielle (INCR_RFP). Cet état permet d'appliquer les journaux de manière incrémentielle afin de maintenir la synchronisation entre les cibles et la source. La mise à jour incrémentielle s'effectue comme suit :

ingresSync --hosts=corp,dreast,drwest --database=corpdb --iid=II --jnlsync

Une fois exécutée, cette opération fermera le journal actuel sur la source, copiera les nouveaux journaux vers les cibles et les répercutera sur celles-ci. L'étape de synchronisation des journaux doit être configurée pour s'exécuter à intervalles réguliers à l'aide du planificateur système, tel que cron. Une exécution fréquente permet de réduire au minimum le délai de synchronisation entre la source et les cibles.

Les installations cibles sur dreast et drwest sont désormais synchronisées avec l'installation source sur corp. Si l'environnement corp venait à subir une panne matérielle ou logicielle, nous pourrions désigner l'un des nœuds cibles comme nouvelle source et rediriger les connexions des clients vers ce nœud. Dans ce cas, nous désignerons drwest comme nouvelle source et dreast restera une cible (site de reprise après sinistre).

ingresSync --target=drwest --database=corpdb --iid=II --incremental_done

Cette opération fait sortir la base de données « drwest corpdb » du mode de mise à jour incrémentielle ; la base de données exécutera désormais à la fois les transactions de lecture et de mise à jour et constituera la nouvelle source. La base de données « dreast » reste en mode de mise à jour incrémentielle et continuera à fonctionner comme nœud cible de reprise après sinistre.

drwest pour Ingress

Le nœud « corp » n'étant plus disponible, la tâche de synchronisation du journal doit être lancée soit sur « drwest », soit sur « dreast ». La tâche de synchronisation du journal peut être configurée et planifiée pour s'exécuter sur les trois nœuds à l'aide de l'indicateur « –strict ». Dans ce cas, la tâche vérifie si elle s'exécute sur le nœud source actuel ; si tel est le cas, elle s'exécute normalement. Si elle s'exécute sur une cible, la tâche s'arrête tout simplement. Cette configuration permet à la synchronisation de se poursuivre même lorsque les rôles des nœuds changent.

Une fois que le serveur est de nouveau opérationnel, il peut être réintégré dans la configuration en tant que cible de reprise après sinistre.

ingresSync --source=drwest --target=corp --database=corpdb --iid=II --ckpsync --restart

Cible DR pour Ingress

Il se peut qu'à un moment donné, nous devions revenir à la configuration d'origine avec « corp » comme source. Voici la marche à suivre :

  • Fermer toutes les connexions à la base de données drwest
  • Synchroniser

    société

     avec

    drwest

     pour garantir

    société

     est en cours
    ingresSync --source=drwest --target=corp --database=corpdb --iid=II
    
    --jnlsync
  • Réattribuer les rôles des nœuds
    
    ingresSync --target=corp --database=corpdb --iid=II --incremental_done
    
    ingresSync --source=corp --target=drwest --database=corpdb --iid=II
    
    --ckpsync --restart

revenir à la société d'origine comme source pour Ingress

Résumé

IngresSync est un mécanisme permettant de mettre en œuvre une solution de reprise après sinistre. Il convient généralement aux cas où un certain délai est acceptable et où les installations cibles ne présentent que peu ou pas utilisateur des bases de données utilisateur . Les bases de données cibles peuvent être utilisées pour des applications en lecture seule, à condition qu'aucune mise à jour incrémentielle ne soit exécutée tant qu'il existe des connexions actives à la base de données. Le processus de mise à jour rattrapera son retard lors du premier cycle de rafraîchissement, lorsqu'il n'y aura plus de connexions actives à la base de données.

Les principaux avantages et inconvénients des différentes méthodes de reprise après sinistre Actian Ingres sont présentés ci-dessous :

Fonctionnalité Expédition Checkpoint IngresSync Réplication
Champ d'application Base de données Base de données Tableau
Niveau de détail Base de données Journal Transaction
Fréquence de synchronisation Point de contrôle utilisateur Transaction
Base de données cible Lecture/Écriture(1) en lecture seule Lecture/Écriture (2)

 

  1. La base de données cible prend en charge les opérations de lecture et d'écriture, mais toutes les modifications sont perdues lors de la prochaine actualisation du point de contrôle.
  2. La base de données cible prend en charge les opérations de lecture et d'écriture, mais des conflits de mise à jour peuvent survenir et nécessiter une résolution manuelle.

Remarque : IngresSync fonctionne actuellement sous Linux et Microsoft Windows. Les environnements Windows nécessitent le paquet de base Cygwin et rsync.