Options de reprise après sinistre pour les charges de travail des bases de données Oracle
Ce guide décrit les options de reprise après sinistre disponibles pour les utilisateurs qui exécutent des charges de travail de bases de données Oracle critiques dans un environnement solution Bare Metal.
Ce guide part du principe que vous exécutez Oracle Enterprise Edition. Certaines des fonctionnalités décrites dans ce guide sont concédées sous licence séparément d'une licence Enterprise Edition. Voici quelques exemples :
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
Consultez vos contrats de licence Oracle pour déterminer les fonctionnalités que vous êtes autorisé à utiliser lorsque vous planifiez la reprise après sinistre et la haute disponibilité.
RTO et RPO des applications
La reprise après sinistre pour les technologies de base de données Oracle doit être déterminée en fonction de l'objectif de temps de récupération (RTO) et de l'objectif de point de récupération (RPO) d'une application. En général, le RTO décrit la durée d'indisponibilité acceptable pour un système, tandis que le RPO décrit la quantité de données que vous acceptez de perdre. Le coût et la complexité d'un système augmentent à mesure que chacune de ces valeurs diminue. Pour en savoir plus sur le RTO et le RPO, consultez Principes de base de la planification de la reprise après sinistre.
Les architectures portant la mention "RPO = 0" ou "aucune perte de données" exigent que les données soient écrites à plusieurs endroits avant d'être considérées comme "validées" dans la base de données. La latence devient un problème lorsque le RPO se rapproche de zéro.
Si elle n'est pas correctement prise en compte lors de la phase de conception, l'implémentation d'une architecture sans perte de données peut avoir des effets négatifs sur les performances globales de l'application.
Haute disponibilité et reprise après sinistre
La haute disponibilité et la reprise après sinistre sont des concepts complémentaires lors de la conception d'architectures de bases de données fiables. Dans le contexte de ce guide, la haute disponibilité désigne la capacité d'un système à se rétablir automatiquement en cas de défaillances individuelles ou en cascade. En revanche, la reprise après sinistre fait partie d'un plan de continuité d'activité global et s'applique aux défaillances plus importantes qui peuvent rendre des groupes entiers de systèmes indisponibles. La reprise après sinistre a une portée plus large en raison du nombre de composants intégrés qui doivent être récupérés en cas de sinistre.
La haute disponibilité doit être considérée comme la "première ligne de défense" lors de la conception d'un système fiable. Une architecture de base de données à disponibilité élevée doit pouvoir résister à des défaillances individuelles et continuer à fonctionner sans provoquer de temps d'arrêt pour l'application. Les composants de haute disponibilité d'un système doivent inclure, sans s'y limiter, les éléments suivants :
- Alimentation redondante dans le matériel de serveur, de réseau ou de stockage
- Interfaces réseau, commutateurs et câbles multiples
- Structures de stockage, contrôleurs et périphériques de disque redondants
- Interconnexions partenaires tolérantes aux pannes entre Google Cloud et l'extension de région de la solution Bare Metal
- Oracle RAC pour empêcher les défaillances de serveur de désactiver une base de données
Une conception de reprise après sinistre doit inclure des processus de récupération en cas de défaillances en cascade multiples qui rendent les composants indisponibles. La planification de la reprise après sinistre doit tenir compte des éléments suivants :
- Pannes régionales
- Catastrophes naturelles
- Incidents entraînant une indisponibilité totale d'un ou de plusieurs composants d'une application
Outils Oracle de reprise après sinistre et de haute disponibilité
Voici quelques outils Oracle de reprise après sinistre et de haute disponibilité :
- Oracle Real Application Clusters
- Oracle Recovery Manager
- Oracle Data Guard
- Base de données Flashback
- Oracle GoldenGate
Oracle Real Application Clusters
Oracle RAC (Real Application Clusters) est utilisé pour mettre à l'échelle horizontalement les charges de travail de base de données afin qu'elles soient traitées par plusieurs serveurs de base de données. Les bases de données qui utilisent RAC permettent une configuration actif/actif entre les serveurs d'une extension de région.
Le RAC est généralement utilisé pour assurer la haute disponibilité des systèmes qui doivent se protéger contre la défaillance d'un seul serveur. En raison de l'approche "tout partagé" (stockage et réseaux partagés) pour le clustering, un cluster RAC s'exécutant dans un environnement de solution Bare Metal doit exister dans un seul pod de solution Bare Metal. RAC est donc une solution pour les problèmes de haute disponibilité, mais ne répond pas à l'exigence de reprise après sinistre.
Oracle Recovery Manager
Oracle Recovery Manager (RMAN) est l'outil principal de sauvegarde et de récupération des bases de données Oracle, car il est capable de lire le format de fichier de données propriétaire d'Oracle. Il peut être utilisé pour cloner des bases de données, effectuer une récupération à un moment précis ou même récupérer une seule table dans une base de données Oracle.
RMAN est le seul outil qui peut être utilisé pour effectuer des sauvegardes lorsque la base de données est ouverte. Il permet également de gérer le catalogue des fichiers de sauvegarde disponibles pour la récupération.
Oracle Data Guard
Oracle Data Guard effectue la réplication de la base de données sur des clusters RAC distants ou d'autres installations de base de données. Data Guard accepte les bases de données de secours dans une configuration physique ou logique.
Les bases de données physiques de secours sont des copies bloc par bloc qui permettent d'ouvrir une copie de la base de données en écriture. Toutes les autres sont montées (mais pas ouvertes) pour appliquer les modifications ou ouvertes en lecture seule pour prendre en charge les applications de reporting.
Pour savoir comment configurer Data Guard sur la solution Bare Metal, consultez Déployer Oracle Data Guard sur la solution Bare Metal.
FLASHBACK DATABASE
La fonctionnalité FLASHBACK DATABASE d'Oracle Enterprise Edition permet aux administrateurs de revenir rapidement à un point précis dans le temps sans avoir à effectuer de restauration de base de données chronophage.
Dans le contexte de la reprise après sinistre, FLASHBACK DATABASE est couramment utilisé conjointement avec Data Guard lors des opérations de basculement pour rétablir plus rapidement la base de données. La base de données ayant échoué est restaurée à un moment précis cohérent avec les journaux de la nouvelle base de données principale, et la commande "redo" est exécutée pour qu'elle puisse se resynchroniser complètement.
Oracle GoldenGate
Oracle GoldenGate est un outil de réplication logique couramment utilisé pour activer les déploiements multisites actif/actif ou pour déplacer des données entre des plates-formes matérielles. Lorsque vous utilisez GoldenGate, un processus extract sur la base de données source capture les modifications apportées aux journaux de rétablissement en ligne et les écrit dans les fichiers de trace, qui sont ensuite transférés vers la base de données cible. Un processus replicat sur la base de données cible convertit les transactions des fichiers de fin en SQL et exécute le code SQL sur la base de données cible.
Cette architecture fait de GoldenGate un outil puissant pour transférer des données entre des plates-formes de bases de données ou transformer des données lors de leur réplication. Contrairement à Data Guard, GoldenGate nécessite l'installation et la maintenance d'un logiciel distinct sur les systèmes source et cible. GoldenGate ne peut pas être utilisé pour la réplication synchrone, car les transactions sont traduites et appliquées en tant que SQL sur la base de données cible. Bien que GoldenGate puisse fournir un temps de latence minimal pour la réplication, il ne peut pas garantir à lui seul un RPO de zéro.
Modèles de déploiement de reprise après sinistre (base de données uniquement)
Oracle a créé le framework MAA (Maximum Availability Architecture) pour vous fournir des modèles de reprise après sinistre recommandés pour le déploiement de vos applications et bases de données.
Chacun des modèles suivants fournit des objectifs RTO et RPO spécifiques :
Les modèles sont mis en correspondance avec des schémas de déploiement spécifiques qui répondent aux RPO et de temps de reprise en cas d'indisponibilité planifiée ou imprévue. Chaque charge de travail de base de données doit être évaluée en fonction de ses exigences de disponibilité et conçue avec un modèle correspondant. Il est courant que les bases de données de développement utilisent un modèle avec un niveau de protection inférieur à celui de leurs homologues de production et d'assurance qualité.
Le modèle Bronze est destiné aux bases de données qui n'ont pas besoin d'un RTO mesuré en minutes. Les modèles Silver et supérieurs incluent des bases de données de secours exécutées sur un site distant. Chaque modèle intègre les fonctionnalités des modèles de niveau inférieur. Par exemple, le modèle Bronze utilise des concepts de sauvegarde et de récupération qui doivent toujours être suivis, même si une base de données de secours est déployée.
Modèle Copper
Le modèle Copper fournit un déploiement minimal pour sauvegarder les bases de données sur des supports de stockage locaux et les copier dans un stockage situé en dehors de l'extension de région. Ce déploiement nécessite une approche en deux étapes, mais peut être scripté pour utiliser Google Cloud SDK afin d'automatiser la transmission des sauvegardes.
L'utilisation de ce déploiement augmente également le RTO en raison de la récupération en deux étapes requise. RMAN ne peut pas accéder directement aux sauvegardes. Elles doivent donc être déplacées vers un emplacement accessible à RMAN avant que la récupération puisse commencer.
| Indisponibilité | Type de panne | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable d'un nœud ou d'une instance | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes : altérations | Dernière sauvegarde complète, incrémentielle ou de journaux d'archive transférée hors du RE | Heures, en fonction de la taille de la base de données et de la bande passante attribuée à interconnexion partenaire | |
| Catastrophes : échecs d'extension de région | Dernière sauvegarde archivelog, incrémentielle ou complète transférée hors de l'environnement de récupération | Jours / semaines, selon le temps nécessaire pour rétablir l'extension de région | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures |
Modèle Bronze
Le modèle Bronze propose deux options de déploiement. Les deux utilisent le stockage natifGoogle Cloudpour conserver les sauvegardes de bases de données.
Déploiement Bronze 1 : Sauvegarde sur un stockage régional
Dans ce déploiement, les sauvegardes sont directement écrites sur des supports hors site. Dans la plupart des cas, la destination de sauvegarde privilégiée est Cloud Storage avec Cloud Storage FUSE, qui présente un bucket Cloud Storage comme un système de fichiers.
Les recommandations pour l'utilisation de Cloud Storage FUSE sont disponibles dans la section "Sauvegardes Oracle avec NFS et Cloud Storage". Google Cloud Filestore, qui présente des partages NFS aux instances solution Bare Metal, peut également être utilisé.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type de panne | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable d'un nœud ou d'une instance | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes : altérations | Dernière sauvegarde archivelog, incrémentielle ou complète | Heures, en fonction de la taille de la base de données et de la bande passante attribuée à interconnexion partenaire | |
| Catastrophes : échecs d'extension de région | Dernière sauvegarde archivelog, incrémentielle ou complète | Jours / semaines, selon le temps nécessaire pour rétablir l'extension de région | |
| Planifié | Correctifs de base de données, mises à jour de l'OS/du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures |
Déploiement Bronze 2 : Sauvegarde à l'aide de Backup and DR
Dans ce déploiement, le service Backup and DR est utilisé pour stocker les sauvegardes dansGoogle Cloud. Backup and DR propose une approche de sauvegarde incrémentielle permanente, qui est stockée sur un support hautes performances soutenu par Cloud Storage pour la conservation à long terme.
La sauvegarde et la reprise après sinistre offrent également un RTO plus rapide que le stockage des sauvegardes sur Filestore ou Cloud Storage, car elles peuvent immédiatement mettre des images de fichiers de base de données à la disposition de l'instance Oracle. La fonctionnalité de montage et de migration permet de mettre rapidement une base de données en ligne tout en la copiant sur le support de stockage de production, ce qui réduit considérablement le RTO.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type de panne | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable d'un nœud ou d'une instance | 0 | Temps nécessaire pour redémarrer l'instance
En secondes si vous utilisez RAC |
| Catastrophes : altérations | Dernière sauvegarde archivelog, incrémentielle ou complète | De quelques minutes à quelques heures, selon les exigences de performances, la taille de la base de données et la bande passante attribuée à l'interconnexion partenaire | |
| Catastrophes : échecs d'extension de région | Dernière sauvegarde archivelog, incrémentielle ou complète | Jours / semaines, selon le temps nécessaire pour rétablir l'extension de région ou la possibilité pour le client de passer à une autre extension de région. | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures |
Silver
Le modèle Silver introduit la réplication de base de données à l'aide d'Oracle Data Guard. Data Guard fournit une réplication de base de données en temps réel avec une ou plusieurs bases de données servant de base de données de secours. Étant donné que Data Guard repose sur le transfert et l'application des modifications de la base de données à mesure qu'elles se produisent, le RPO peut être proche de zéro. Le modèle Silver repose sur la réplication asynchrone. L'utilisation de la réplication synchrone garantit l'absence de perte de données, mais le temps nécessaire pour envoyer des données entre les régions dépasse généralement les limites acceptables pour le temps de réponse des applications.
La fonctionnalité de basculement rapide de Data Guard permet d'effectuer des opérations de basculement automatiques si une base de données principale devient indisponible pendant une période définie par l'utilisateur. La configuration est surveillée par un processus d'observateur Data Guard, qui peut s'exécuter.
Le modèle Silver présente l'avantage de garantir la disponibilité de la base de données en cas de défaillance régionale totale. Toutefois, les opérations de basculement et de permutation peuvent avoir un impact sur les performances de l'application, car la latence réseau entre les serveurs d'application et la base de données augmente. Il est rarement recommandé d'exécuter des applications et des bases de données associées dans différentes régions. Bien que le RTO de la base de données puisse être inférieur à une minute, les cas de basculement d'application peuvent prendre de quelques minutes à quelques heures avant que les services ne soient pleinement fonctionnels. Dans la plupart des cas, l'exécution de plans de reprise après sinistre interrégionaux implique généralement des processus manuels en raison du nombre de composants déplacés.
Dans le modèle Silver, vous pouvez toujours prévoir des temps d'arrêt ou des intervalles de maintenance lors des activités de correction trimestrielles. L'introduction d'Oracle RAC peut réduire les temps d'arrêt pour les correctifs ou les défaillances de serveur.
Le schéma suivant illustre un exemple de configuration.
L'exemple de configuration du diagramme montre des bases de données RAC s'exécutant dans les régions us-west2 et us-east4. La réplication est configurée à l'aide de Data Guard asynchrone. Tout le trafic entre la solution Bare Metal et Google Cloudtransite par une interconnexion partenaire, et le trafic multirégional transite par le réseau principal de Google. Les serveurs d'application sont configurés dans chaque région, mais sont généralement arrêtés dans la région de reprise après sinistre jusqu'à ce qu'un événement de basculement soit déclaré.
| Indisponibilité | Type de panne | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable d'un nœud ou d'une instance | 0 | Temps nécessaire pour redémarrer l'instance
En secondes si vous utilisez RAC |
| Catastrophes : altérations | < 60 s | De quelques minutes à plusieurs heures, selon le basculement de l'application. | |
| Catastrophes : échecs d'extension de région | < 60 s | De quelques minutes à plusieurs heures, selon le basculement de l'application. | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
En secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
en minutes si vous utilisez |
Modèle Gold
Si vous craignez de perdre des données dans le modèle Silver, vous pouvez opter pour le modèle Gold, qui utilise une instance de synchronisation distante pour fournir une réplication synchrone à une instance exécutée dans Compute Engine Google Cloud.
Une instance de synchronisation distante inclut un fichier de contrôle de base de données et un ensemble de journaux redo de secours qui s'exécutent à proximité géographique de la base de données principale. Cette instance est configurée pour recevoir le rétablissement de manière synchrone avec une faible latence, ce qui permet d'enregistrer toutes les modifications en dehors de l'extension de région de la base de données principale. L'instance de synchronisation distante transmet ensuite le rétablissement à la base de données de secours de la région distante pour qu'il soit appliqué de manière asynchrone.
Une instance de synchronisation différée n'est pas une copie complète de la base de données et ne peut donc pas traiter le trafic des applications. L'instance de synchronisation distante est utilisée pour fournir un emplacement tolérant aux pannes où les modifications de la base de données peuvent être écrites de manière synchrone, ce qui permet une solution sans perte de données. Lors de la réplication synchrone sur l'instance de synchronisation distante, les transactions ne sont pas validées sur la base de données principale tant que les modifications n'ont pas été reçues et validées sur l'instance de synchronisation distante.
Les instances Compute Engine sont généralement sélectionnées comme candidates pour héberger une instance de synchronisation distante. Placer l'instance de synchronisation distante dans une zone Compute Engine à proximité de la base de données principale ajoute une latence minimale (généralement inférieure à 1,5 ms) et protège contre les défaillances dans l'extension de région.
Le schéma suivant illustre un exemple de déploiement.
L'exemple de configuration du diagramme montre une base de données RAC principale exécutée dans us-west2 avec des applications exécutées dans Compute Engine. Une instance Compute Engine dans us-west2 exécute une instance de synchronisation distante et reçoit des journaux redo synchrones. L'instance de synchronisation distante est configurée pour envoyer des journaux redo de manière asynchrone à une base de données RAC exécutée dans la région us-east4. Les instances d'application sont configurées dans la région us-east4 sur Compute Engine pour gérer le trafic d'application en cas de sinistre.
| Indisponibilité | Type de panne | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable d'un nœud ou d'une instance | 0 | Temps nécessaire pour redémarrer l'instance
En secondes si vous utilisez RAC |
| Catastrophes : altérations | 0 | De quelques minutes à plusieurs heures, selon le basculement régional de l'application. | |
| Catastrophes : échecs d'extension de région | 0 | De quelques minutes à plusieurs heures, selon le basculement régional de l'application. | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
En secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
en minutes si vous utilisez |
Modèle Platinum
Le modèle Platinum propose deux options de déploiement. Chaque option de déploiement offre une protection à l'aide d'une technologie différente et présente des caractéristiques de RTO et de RPO différentes.
Déploiement Platinum 1 : Data Guard avec basculement rapide
Le déploiement Platinum 1 s'appuie sur le déploiement du modèle Gold en ajoutant une deuxième base de données de secours Data Guard dans la région locale, qui s'exécute sur une instance Compute Engine. Cette configuration utilise la réplication synchrone entre la base de données principale et la base de données de secours exécutée dans Compute Engine, ce qui garantit l'absence de perte de données dans la région principale.
La création d'une base de données de secours dans la région permet d'effectuer des opérations de basculement et de permutation de base de données sans affecter les applications. Lors des modifications apportées aux rôles de base de données, les applications configurées conformément aux considérations relatives aux clients d'Oracle se reconnectent automatiquement à la nouvelle base de données principale sans nécessiter d'intervention manuelle. Les applications correctement configurées subissent une indisponibilité de moins de deux minutes lors d'un événement de basculement.
Bien que la base de données de secours dans Compute Engine n'exécute pas RAC, elle doit être dimensionnée pour prendre en charge le trafic d'application normal lorsqu'elle est exécutée en tant que base de données principale. Cette instance peut s'exécuter avec une forme plus petite en tant qu'instance de secours et être mise à l'échelle lors des événements de basculement, ou s'exécuter à pleine capacité à tout moment. Le redimensionnement de l'instance lors d'un événement de basculement a un impact négatif sur le RTO, car l'instance doit être redémarrée lors de l'opération de redimensionnement.
Le basculement à démarrage rapide est configuré sur une instance Compute Engine exécutant le broker Data Guard avec un observateur. L'observateur exécute un client Oracle de base avec des connexions à toutes les bases de données principales et de secours. Si l'observateur détecte une défaillance dans la base de données principale, il lance un basculement vers l'une des bases de données de secours. La base de données de secours exécutée sur Compute Engine doit être configurée comme cible de basculement préférée lorsque vous utilisez le déploiement de niveau Gold.
Oracle recommande de placer l'observateur dans une région distincte de celles des bases de données principale et de secours. Cela offre la meilleure protection contre les défaillances régionales et les événements de partitionnement du réseau. Si une troisième région n'est pas possible, l'observateur doit être installé dans la région principale et s'exécuter dans une zone différente de celle de la région de secours à proximité.
Le schéma suivant illustre un exemple de déploiement.
L'exemple de déploiement illustré dans le schéma comprend les éléments suivants :
- Une base de données principale exécutant RAC sur un serveur de solution Bare Metal dans la région
us-west2. - Base de données de secours quasi sur site s'exécutant sur une instance Compute Engine dans la région
us-west2. - Base de données de secours distante s'exécutant sur un serveur de solution Bare Metal dans la région
us-east4. - Observateur Data Guard s'exécutant sur l'instance Compute Engine dans la région
us-central1.
La réplication synchrone est configurée pour la base de données de secours dans la région s'exécutant sur l'instance Compute Engine, et la réplication asynchrone est configurée pour la région distante. Dans chaque cas, le rétablissement est envoyé de la base de données principale à la base de données de secours. Il n'est pas transféré d'une base de données de secours à l'autre. L'observateur est configuré dans une troisième région et maintient la connectivité à toutes les bases de données de la configuration. Les instances d'application sont configurées dans la région principale et se connectent à la base de données principale sur le serveur de solution Bare Metal (ou à la base de données sur l'instance Compute Engine lors des opérations de basculement et d'inversion). Les instances d'application sont configurées dans la région us-east4 sur Compute Engine pour gérer le trafic d'application en cas de sinistre.
| Indisponibilité | Type de panne | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable d'un nœud ou d'une instance | 0 | Temps nécessaire pour redémarrer l'instance
En secondes si vous utilisez RAC |
| Catastrophes : altérations | 0 | < 60 s | |
| Catastrophes : échecs d'extension de région | 0 | < 60 s | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
En secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
en minutes si vous utilisez |
Déploiement Platinum 2 : GoldenGate pour la réplication
Le déploiement Platinum 2 s'appuie sur Oracle GoldenGate pour la réplication. Étant donné que GoldenGate ne réplique pas au niveau du bloc. Il permet à chaque base de données de traiter les sessions d'application en lecture et en écriture de manière indépendante. Il réplique les modifications de manière bidirectionnelle, ce qui permet une configuration de base de données actif/actif.
Les applications doivent être soigneusement validées avant de s'engager dans un déploiement actif/actif, et vous devez tenir compte de la détection et de la résolution des conflits.
Contrairement à Data Guard, GoldenGate nécessite l'installation et la maintenance de logiciels supplémentaires sur les serveurs de base de données Oracle. Les déploiements actif/actif nécessitent généralement une conception sophistiquée du schéma et de l'application pour tirer parti d'un déploiement de base de données multisite. De nombreuses applications pré-emballées ne sont pas compatibles avec ce type d'architecture.
Les déploiements qui dépendent de GoldenGate pour toute la réplication ne peuvent pas prendre en charge un RPO sans perte de données en raison de la nature asynchrone de la réplication logique. Les bases de données de secours locales exécutées dans Compute Engine à l'aide de Data Guard peuvent être déployées pour fournir un RPO nul avec réplication synchrone.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type de panne | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable d'un nœud ou d'une instance | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes : altérations | De secondes à minutes
0 si vous utilisez Data Guard dans chaque emplacement |
0 | |
| Catastrophes : échecs d'extension de région | De secondes à minutes
0 si vous utilisez Data Guard dans chaque emplacement |
0 | |
| Planifié | Correctifs de base de données, mises à jour de l'OS / du micrologiciel | 0 | Temps nécessaire pour mettre à jour et redémarrer l'instance.
En secondes si vous utilisez RAC |
| Mise à niveau majeure de la base de données | 0 | 0 |