Planification de la récupération après sinistre pour les bases de données

Vous pouvez utiliser Oracle GoldenGate, Active Data Guard et Autonomous Data Guard pour implémenter la récupération après sinistre pour vos bases de données déployées dans Oracle Cloud.

• Active Data Guard fournit une protection complète des données, une haute disponibilité et une récupération après sinistre pour Oracle Database de manière simple et économique en conservant une réplique physique (de secours) synchronisée d'une base de données de production à un emplacement distant. La base de données de secours est ouverte en lecture seule pendant le transfert, la validation et la récupération des informations de journalisation.

  Contrairement aux méthodes de réplication de stockage standard, Active Data Guard réplique uniquement les fichiers de journalisation en mémoire et valide la réplication afin d'éviter toute corruption.

• Oracle GoldenGate est un produit de réplication logique avancée qui prend en charge la réplication multimaître, le déploiement de hub et de satellite et la transformation de données. GoldenGate offre aux clients des options flexibles pour répondre à l'ensemble des exigences de réplication, y compris les plates-formes matérielles hétérogènes.
• Autonomous Data Guard assure la protection des données et la récupération après sinistre pour vos instances de base de données autonome dans Oracle Cloud. Lorsque vous activez Autonomous Data Guard pour une instance de base de données autonome, une base de données de secours est créée dans la même région. Dans les régions avec plusieurs domaines de disponibilité, la base de données de secours est provisionnée dans un domaine de disponibilité différent de celui de la base de données principale. Dans les régions avec un seul domaine de disponibilité, la base de données de secours est provisionnée sur une machine physique différente de celle de la base de données principale. Autonomous Data Guard surveille l'instance principale et bascule automatiquement vers la base de données de secours si la base de données principale devient indisponible.

A propos d'Oracle Maximum Availability Architecture

Oracle Maximum Availability Architecture (MAA) est un ensemble de modèles de base de meilleures pratiques pour l'utilisation intégrée des technologies de haute disponibilité d'Oracle. Les meilleures pratiques MAA décrivent des architectures standard conçues pour atteindre différents objectifs de niveau de service en matière de haute disponibilité et de protection des données. Les niveaux d'architecture MAA Bronze, Silver, Gold et Platinum sont conçus pour atteindre différents objectifs de niveau de service et vous offrent des options de haute disponibilité, de protection des données et de récupération après sinistre.

Chacun des niveaux MAA suivants utilise un ensemble optimal de fonctionnalités Oracle qui, lorsqu'elles sont déployées ensemble, atteignent de manière fiable les niveaux de service cible pour les incidents non planifiés et les événements de maintenance planifiés :

• Bronze

  Le niveau Bronze fournit un service de base de données au coût le plus bas possible. Un niveau réduit de haute disponibilité et de protection des données est accepté en échange d'une réduction des coûts et de la complexité d'implémentation. Cette architecture peut être adaptée aux bases de données utilisées pour les applications et les bases de données de test, de développement et de production moins critiques.

  L'architecture utilise les fonctionnalités de haute disponibilité incluses dans Oracle Enterprise Edition. Bronze prend par défaut la valeur de l'architecture à instance unique ou colocative d'Oracle Database. Les fonctions de haute disponibilité d'Oracle Restart ou d'Oracle Clusterware permettent de redémarrer une instance, un serveur de base de données ou tout service géré approprié. Pour les corruptions logiques telles que les erreurs humaines, vous pouvez utiliser les opérations Flashback pour "rembriquer" la base de données à un moment donné. Dans le pire scénario d'une panne de site complète, il faut du temps supplémentaire pour restaurer et récupérer le système et la base de données à partir de sauvegardes, ce qui peut entraîner des heures ou des jours d'inactivité.

  Une sauvegarde locale au sein du même centre de données est toujours recommandée pour une récupération rapide. Oracle recommande également de conserver une deuxième copie des sauvegardes dans un centre de données distant à des fins de protection contre les pannes et les sinistres du site. Vous pouvez utiliser Oracle Database Backup Cloud Service pour conserver une sauvegarde cloud des bases de données sur site.

• Silver

  Le niveau Silver est conçu pour les bases de données qui ne peuvent pas se permettre d'attendre un redémarrage à froid ou une restauration à partir d'une sauvegarde, en cas de défaillance d'une instance de base de données ou d'un serveur irrécupérable. Cette architecture peut s'adapter aux applications de production qui sont essentielles pour l'entreprise et doivent réduire les temps d'arrêt pour les pannes locales et les activités de maintenance planifiées les plus courantes.

  L'architecture Silver repose sur les bases de l'architecture Bronze et ajoute le clustering actif-actif Oracle Real Application Clusters (Oracle RAC) pour un temps d'inactivité minimal ou nul en cas de panne d'instance de base de données ou de serveur, ainsi qu'un temps d'inactivité de base de données nul pour la plupart des événements de maintenance planifiés courants.

  Comme dans l'architecture Bronze, Recovery Manager (RMAN) fournit des sauvegardes optimisées pour la base de données afin de restaurer la disponibilité en cas de panne ou de sinistre complète du cluster.

• Or

  Le niveau Gold est conçu pour répondre aux exigences de niveau de service qui ne peuvent tolérer de longues périodes d'inactivité et de perte de données. Cet ensemble de modèles d'architecture offre une haute disponibilité et une protection complète des données pour tous les types de pannes non planifiées, y compris les corruptions de données, les défaillances de base de données et les pannes de site. Les applications de production critiques nécessitant un temps de récupération rapide et une perte de données nulle ou minimale pour toutes les pannes de base de données et de système et les activités de maintenance planifiées bénéficieront des fonctionnalités incluses dans l'architecture de référence Gold.

  L'architecture de référence Gold, basée sur l'architecture de référence Silver, fournit quatre modèles d'architecture à l'aide d'Oracle Active Data Guard. Les schémas varient d'une base de données de secours active à distance unique avec Fast Start Failover et HA Observer, à plusieurs configurations de base de données de secours, y compris les groupes de lecteurs de secours, et enfin à une configuration de secours sans perte de données de synchronisation à distance (entre les régions).

• Platine

  Le niveau Platinum a le potentiel de fournir un temps d'inactivité nul pour les pannes et les activités de maintenance planifiées qui ne sont pas réalisables avec l'architecture Gold. L'architecture Platinum repose sur l'architecture Gold en ajoutant la réplication Oracle GoldenGate afin d'éliminer les temps d'inactivité pour les migrations, les mises à niveau d'application et les mises à niveau de base de données. Chaque base de données Oracle GoldenGate est protégée par une base de données de secours afin d'éviter toute perte de données en cas de défaillance d'une base de données, d'un cluster ou d'un site.

  Contrairement aux autres architectures MAA, les considérations relatives à l'application sont requises pour intégrer Oracle GoldenGate à l'architecture, afin de garantir que la détection et la résolution des conflits sont effectuées correctement. Global Data Services ou gestion personnalisée des services d'application peuvent également être requis pour éviter tout temps d'inactivité des applications, par exemple lors de la migration et des mises à niveau de base de données.

Utiliser Active Data Guard

Data Guard fournit un ensemble complet de services permettant de créer, de tenir à jour, de gérer et de surveiller des bases de données de secours afin de permettre aux bases de données Oracle de production de résister aux catastrophes et aux altérations de données. Data Guard conserve ces bases de données de secours en tant que copies cohérentes transactionnellement de la base de données de production. La plupart des meilleures pratiques d'Active Data Guard sont définies, testées et validées dans le cadre d'architectures de référence du niveau Gold MAA.

Si la base de données de production devient indisponible en raison d'un incident planifié ou non planifié, Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, ce qui réduit le temps d'arrêt associé à l'incident. Data Guard peut être utilisé avec des techniques traditionnelles de sauvegarde, de restauration et de cluster pour fournir un niveau élevé de protection des données et de disponibilité des données.

Avantages d'Active Data Guard

Active Data Guard présente plusieurs avantages.

• Réplication physique sécurisée.

  La base de données de secours est ouverte en lecture seule, ce qui garantit la cohérence des données.

  A partir d'Oracle Database 19c, vous pouvez émettre des instructions de mise à jour et d'insertion occasionnelles vers la base de données de secours, qui redirige les instructions vers la base de données principale.

• Réplication simple, rapide et unidirectionnelle d'une base de données Oracle Database complète.

  La configuration par défaut gère la plupart des charges de travail de sorte qu'il y ait peu de frais d'administration.

• Aucune restriction.

  Oracle Data Guard Redo Apply prend en charge toutes les fonctionnalités Oracle et réplique de façon transparente tous les types de données et de stockage, les packages PL/SQL et DDL sans considérations spéciales.

• Meilleure protection des données.

  La réplication directe à partir de la mémoire isole la base de données de secours de toute altération des E/S pouvant se produire au niveau de la base de données principale. Détecte toute altération silencieuse en cas de perte d'écriture qui peut se produire indépendamment sur la base de données principale ou de secours. Détecte et répare automatiquement les corruptions de bloc physique qui peuvent survenir indépendamment sur la base de données principale ou de secours.

• Choix synchrone avec perte de données nulle ou asynchrone avec protection contre la perte de données quasi nulle.
• RoI amélioré.

  Vous pouvez décharger des charges globales en lecture seule telles que les applications de reporting, les requêtes ad hoc et les extractions de données vers une base de données de secours physique synchronisée.

• Une seule commande convertit une base de données de secours physique en lecture/écriture ouverte par le système de test. Une seconde commande la convertit en base de données de secours physique et la resynchronise avec la base de données principale. Les données principales sont toujours protégées.
• Gestion intégrée d'une configuration complète avec la ligne de commande Oracle Data Guard Broker et le basculement automatique de la base de données.
• Prise en charge pour la configuration de base de données à noeud unique ou à plusieurs noeuds (Real Application Cluster).
• Continuité des applications, pour la protection en vol de vos transactions.

  Active Data Guard masque les pannes de base de données des utilisateurs finals et des applications en récupérant le travail en cours pour les sessions de base de données concernées.

Modes de configuration

• Protection maximale
  Ce mode de protection n'entraîne aucune perte de données en cas de panne de la base de données principale. Pour s'assurer qu'il ne peut y avoir aucune perte de données, la base de données principale s'arrête si un problème l'empêche d'écrire son flux de journalisation dans le fichier de journalisation de secours d'au moins une base de données de secours.

  Remarque :

  Ce mode n'est pas disponible pour les bases de données autonomes. Pour Exadata Cloud Service et Exadata Cloud@Customer, vous pouvez configurer ce mode manuellement, mais le plan de contrôle du cloud ne le reflétera pas.
• Disponibilité maximale

  Ce mode de protection fournit le niveau maximal de protection des données sans compromettre la disponibilité de la base de données principale. A l'instar du mode Protection maximale, une transaction est validée uniquement après que les données de journalisation nécessaires pour la récupérer sont écrites dans le fichier de journalisation en ligne local et dans le fichier de journalisation de secours d'au moins une base de données de secours cohérente de manière transactionnelle. Contrairement au mode Protection maximale, la base de données principale ne s'arrête pas si un problème l'empêche d'écrire son flux de journalisation dans un fichier de journalisation de secours distant. Au lieu de cela, la base de données principale et la configuration Data Guard sont rétrogradées à l'état UNSYNCHRONIZED. Lorsqu'au moins une base de données de secours est disponible, elle est resynchronisée automatiquement.

• Performances maximales

  Ce mode de protection (valeur par défaut) fournit le niveau maximal de protection des données sans affecter les performances de la base de données principale. Pour ce faire, une transaction est validée lorsque les données de journalisation nécessaires à sa récupération sont écrites de manière asynchrone dans le fichier de journalisation en ligne local. Lorsque des liens réseau dotés d'une bande passante suffisante sont utilisés, ce mode fournit un niveau de protection des données qui se rapproche de celui du mode Disponibilité maximale, avec un impact minimal sur les performances de la base de données principale.

Considérations relatives au positionnement de la base de données

Pour améliorer la disponibilité et la récupération après sinistre, placez le système de la base de données de secours dans un domaine de disponibilité différent de celui de la base de données principale.

Si vous activez Data Guard pour une base de données et que votre base de données de secours se trouve dans le même domaine de disponibilité que la base de données principale (par choix ou si la région dispose d'un seul domaine de disponibilité), placez la base de données de secours dans un domaine de pannes différent de celui de la base de données principale.

Si vos bases de données principale et de secours sont des systèmes de base de données de machine virtuelle RAC à 2 noeuds et que ces deux bases se trouvent dans le même domaine de disponibilité, nous vous recommandons de répartir les quatre noeuds (deux pour la base principale et deux pour la base de données de secours) entre les trois domaines de pannes du domaine de disponibilité. Cette configuration garantit la disponibilité la plus élevée possible, en tirant parti des trois domaines de pannes. Dans ce scénario, seul l'un des deux noeuds de la base de données de secours peut se trouver dans un domaine de pannes qui n'inclut aucun autre noeud de la base de données principale ou de secours.

Pour garantir des transitions de rôle optimales entre la base de données principale et la base de données de secours, Oracle vous recommande de dimensionner et de configurer les deux bases de données de manière symétrique.

Meilleures pratiques de configuration

Reportez-vous à "Oracle Data Guard Best Practices" dans le manuel Oracle Database High Availability Overview and Best Practices.

Utiliser Oracle GoldenGate

Oracle GoldenGate est un package logiciel complet destiné à l'intégration et à la réplication de données en temps réel dans des environnements informatiques hétérogènes. L'ensemble de produits propose des solutions haute disponibilité, une intégration de données en temps réel, une capture de données de modification transactionnelle, une réplication de données, des transformations et une vérification entre les systèmes d'entreprise opérationnels et analytiques. La majorité des meilleures pratiques Oracle GoldenGate sont définies, testées et validées dans le cadre d'architectures de référence dans le niveau MAA Platinum.

Utilisez Oracle GoldenGate lorsqu'une base de données de réplique doit être ouverte en lecture/écriture pendant que la réplication est active, y compris dans les scénarios suivants :

• Exigences de réplication avancées, telles que la réplication multimaître et bidirectionnelle, la réplication sous-ensemble, la réplication plusieurs à un, la réplication inter-endian et les transformations de données
• Maintenance et migrations sans temps d'arrêt à l'aide d'une réplication bidirectionnelle
• Migration interplate-forme non prise en charge par Data Guard (par exemple, migration interplate-forme)
• Prise en charge des systèmes distribués de version interbases de données (par exemple, la réplique 1 est sur 12.2 et la réplique 2 sur 19c)
• Prise en charge des plates-formes interbases de données (par exemple, la réplique 1 se trouve sur Oracle et la réplique 2 se trouve sur une base autre qu'Oracle DB)

Modes de configuration

Utilisez l'architecture des microservices Oracle GoldenGate, qui fournit une plate-forme de réplication sécurisée, complète et évolutive dans le cloud. Pour réduire la surcharge sur les serveurs de base de données, Oracle recommande de déployer GoldenGate dans la configuration du hub.

GoldenGate prend en charge plusieurs topologies, comme indiqué dans le diagramme suivant. Choisissez un mode qui convient à votre cas d'utilisation.

Description de l'illustration gg-config-modes.png

Meilleures pratiques de configuration

Etant donné qu'Oracle GoldenGate réplique les données au niveau transactionnel, nous recommandons d'implémenter la détection et la résolution des conflits (CDR) pour assurer la cohérence des données entre deux sites. Les conflits sont identifiés immédiatement et gérés à l'aide de scripts automatisés.

Si vous utilisez principalement GoldenGate à des fins de récupération après sinistre et que la réplication ne représente qu'une seule manière, nous vous recommandons d'ajouter Data Guard entre deux régions. Vous obtenez ainsi une solution sans perte de données avec une cohérence de données forte entre l'instance principale et l'instance Data Guard. Cette configuration réduit également la surcharge liée à l'exécution de l'extraction GoldenGate à partir de la base de données principale.

Description de l'illustration db-dg-gg.png

Remarque :

L'architecture présente plusieurs domaines de disponibilité. Pour une région disposant d'un seul domaine de disponibilité, ajustez l'architecture afin de répartir les ressources entre les domaines de pannes du domaine de disponibilité.

Déployez Oracle GoldenGate et dans une configuration HA. Vous pouvez utiliser la réplication Oracle ASM Cluster File System (ACFS) pour les fichiers GoldenGate critiques.

Utilisation d'Active Data Guard et de GoldenGate

Oracle GoldenGate et Active Data Guard ne s'excluent pas mutuellement. Vous pouvez les utiliser ensemble pour atteindre un objectif de point de récupération égal à zéro (c'est-à-dire sans risque de perte de données), car GoldenGate est de nature asynchrone alors que Active Data Guard peut fournir une réplication synchrone avec d'autres fonctionnalités clés telles que la validation de bloc de données, la réparation automatique de blocs et la continuité des applications.

Voici quelques scénarios tirant parti d'Oracle GoldenGate et d'Active Data Guard :

• Utilisez une base de données de secours Active Data Guard pour la protection contre les sinistres et les mises à niveau non simultanées d'une base de données OLTP essentielle. Utilisez GoldenGate pour extraire des données de la base de données principale Data Guard (ou de la base de données de secours à l'aide du mode ALO GoldenGate) pour la mise à jour ETL d'un entrepôt de données d'entreprise.
• Utilisez la réplication de sous-ensemble GoldenGate pour extraire, transformer et agréger les données de nombreuses sources de données dans une banque de données opérationnelle centrale (ODS). ODS prend en charge les systèmes d'applications stratégiques qui génèrent des revenus importants pour l'entreprise. Utiliser une base de données de secours Active Data Guard pour protéger ODS, offrant ainsi une protection et une disponibilité optimales des données.
• Utilisez la réplication multimaître GoldenGate pour synchroniser plusieurs bases de données, chacune située dans des zones géographiques différentes. Chaque copie GoldenGate dispose de sa propre base de données de secours Data Guard synchrone locale qui active le basculement sans perte de données en cas de panne.

Remarque :

Pour implémenter l'architecture de disponibilité maximale au niveau Platinum, utilisez Oracle Real Application Clusters (Oracle RAC), Active Data Guard et Oracle GoldenGate.