Description de la réplication du système SAP HANA

La réplication du système présente les avantages suivants :

• La mémoire est chargée en continu sur un site secondaire en préparation de la reprise possible et occupe des ressources.

• Le basculement est plus rapide qu'avec la réplication de stockage ou la mise en miroir (2 à 5 minutes).

• Il y a une rampe de performance très courte (seulement des minutes, pas des heures, sans préparation).

La réplication du système présente l'inconvénient suivant :

Le matériel (mémoire et CPU) est activement utilisé sur le site secondaire pour les processus standby ou shadow.

1. Expédition de données delta (operation_mode=delta_datashipping)

   Ce mode établit une réplication du système où occasionnellement (par défaut toutes les 10 minutes) un envoi de données delta a lieu en plus de l'envoi de journal continu. Le journal de restauration expédié n'est pas rejoué sur le site secondaire.

2. Reproduction continue du journal (operation_mode=logreplay)

   Ce mode ne requiert plus d'envoi de données delta. En outre, le journal de restauration expédié est continuellement rejoué sur le site secondaire.

3. Rediffusion continue du journal avec Active/Active (operation_mode=logreplay_readaccess)

   Ce mode est similaire au mode de fonctionnement logreplay dans la mesure où il rejoue en continu le journal de redo sur le site secondaire. En outre, il autorise l'accès en lecture seule au secondaire.

Les événements pour le début d'un transport sont les suivants :

1. Le système primaire crée un paquet de données interne similaire à une sauvegarde complète des données et le transfère initialement au site secondaire. Le transport s'effectue de manière asynchrone.
2. Les informations du journal sont transférées parallèlement au transfert initial des données. Le journal est transporté de manière asynchrone jusqu'à ce que le commit de la transaction terminée ait lieu. Avec le commit, toutes les autres informations de journal qui n'ont pas encore été transférées ou écrites, ainsi que le commit final, doivent également être écrites de manière synchrone. Cela doit se produire avant que la base de données principale utilisée en mode productif puisse poursuivre le travail transactionnel.
3. Toutes les opérations de chargement et de déchargement des index principaux et des colonnes de table sont surveillées et proposées avec le transfert de données incrémentiel vers le système secondaire. Ces index principaux et colonnes de table sont ensuite chargés ou déchargés de manière équivalente dans la mémoire en préparation de la reprise.

Les événements lors du transport incrémentiel sont les suivants :

1. À l'aide de l'opération de concept de mémoire fantôme de SAP HANA, de petites sauvegardes incrémentielles sont transférées vers le paquet de données delta toutes les 10 minutes sur le site secondaire. Le paramétrage par défaut est de 600 secondes.
2. Avec ces informations de données delta, les informations des index principaux chargés dans SAP HANA sur le site primaire sont également transférées vers le site secondaire. Il s'agit de préparer la mémoire principale avec ces index principaux sur le site secondaire également.

Depuis la première version de la réplication du système, le mode d'exploitation delta_datashipping est la méthode de réplication par défaut. Avec le mode d'exploitation Logreplay, les expéditions de données delta ne sont plus nécessaires. Le temps de reprise a été réduit et d'autres composants sont déjà initialisés au moment de la réplication.

En mode d'exploitation logreplay, la réplication du système utilise un envoi initial de données pour initialiser le site secondaire. Ensuite, seule l'expédition du journal est terminée et les tampons de journal reçus par le secondaire y sont relancés. Les points de sauvegarde sont exécutés individuellement pour chaque service et les fusions de tables de colonnes sont exécutées sur le site secondaire.

Dans le mode de fonctionnement logreplay, les segments de journal peuvent être marqués comme conservés afin de pouvoir synchroniser un système secondaire après une déconnexion.

Avec la reprise continue des journaux, l'envoi de données delta ne peut pas être utilisé pour synchroniser un site secondaire. En effet, bien que la persistance primaire et la persistance secondaire soient logiquement compatibles, elles ne sont plus physiquement compatibles. Cela signifie que les données contenues dans la persistance sont identiques, mais la mise en forme des données sur les pages peut être différente sur le site secondaire. Par conséquent, un site secondaire peut uniquement être synchronisé à l'aide de l'envoi de journaux delta. Cela est pertinent pour les situations suivantes :

• Le site secondaire est déconnecté depuis un certain temps (par exemple, en raison d'un problème de réseau ou d'un arrêt temporaire du site secondaire).
• Un ancien site principal a été enregistré pour le rebasculement.

Le site secondaire utilise uniquement le journal dans la zone des journaux en ligne du système SAP HANA primaire pour la synchronisation. Pour synchroniser le site secondaire, le journal doit être conservé pendant une période plus longue que précédemment. Si la synchronisation à l'aide de l'envoi de journal delta ne fonctionne pas, par exemple parce que le journal a été réutilisé, une expédition complète des données est nécessaire. Pour éviter cela, le concept de conservation des journaux a été introduit.

Le mode d'exploitation Accès en lecture au journal Replay est identique au mode Journaliser reprise, à l'exception du fait que le système secondaire est disponible en mode lecture seule. Cela signifie qu'une requête SQL peut accéder (lire) aux données dans le secondaire, mais que les données ne peuvent pas être modifiées.

Le mode d'exploitation Journal Replay Read Access peut être utile dans un environnement où les charges de travail OLPT et OLAP sont mélangées et que vous souhaitez les fractionner entre le système principal et le système secondaire.

Les conditions préalables suivantes doivent être prises en compte :

• Un volume de disque indépendant supplémentaire est nécessaire pour les systèmes de développement/d'assurance qualité. Étant donné que le site secondaire requiert la même capacité d'E/S que le site principal, les systèmes supplémentaires ne doivent pas avoir d'impact négatif sur les E/S du site secondaire. Par conséquent, il est recommandé d'avoir une infrastructure de stockage distincte pour chaque système.

• Les SID et les numéros d'instance doivent être différents pour le développement/l'assurance qualité. Le <instance number>+1 du système de production ne doit pas être utilisé, mais doit être libre sur les deux sites, car cette plage de ports est utilisée pour la communication de réplication du système.

• Le préchargement des tables doit être désactivé sur le site secondaire à l'aide du paramètre suivant :

  global.ini/[system_replication]-> preload_column_tables=false

• Le processus de reprise prend plus de temps car aucune donnée n'est préchargée en mémoire sur le site secondaire (peut toujours respecter les accords sur le niveau de service pour la restauration après sinistre).

• Les systèmes de développement/d'assurance qualité doivent être arrêtés en cas de prise de contrôle.

• La limite d'affectation globale sur le secondaire doit être définie de sorte que la mémoire disponible couvre la mémoire requise par le système secondaire ainsi que par les systèmes de développement/d'assurance qualité, à l'aide du paramètre suivant :

  global.ini/[memorymanager]-> global_allocation_limit

Les avantages de la réplication du système avec un système de développement/d'assurance qualité sur un site secondaire sont les suivants :

• Le développement/QA est opéré sur le site secondaire (calcul des coûts mixtes).

• Des solutions synchrones et asynchrones sont disponibles.

• L'impact de la solution synchrone sur le site principal est d'environ 10 % (contrairement à environ 25 % avec la réplication du stockage).

• Le processus de transfert du primaire au secondaire est optimisé et un montant de transfert inférieur est nécessaire par rapport à la réplication du stockage.

• Lors de la reprise sur le site secondaire, seul un transfert automatique est nécessaire car le dernier point de synchronisation des données est nécessaire.

Les inconvénients de la réplication du système avec un système de développement/d'assurance qualité sur un site secondaire sont les suivants :

• Les données de table et de colonne ne peuvent pas être chargées en continu dans la mémoire du site secondaire.

• Le matériel (mémoire et unité centrale) est activement utilisé pour le développement/l'assurance qualité et en partie pour les processus de secours ou fantômes.

• La reprise est similaire à la mise en miroir de stockage (20 à 30 minutes au mieux).

• La rampe de performance est similaire à la mise en miroir de stockage (1 à 3 heures).

• QA et Development ont besoin de leur propre infrastructure de disque soigneusement séparée afin de ne pas avoir d'effets d'influence les uns sur les autres.