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 exécution de charges de travail critiques de bases de données Oracle dans une solution Bare Metal environnement.
Ce guide suppose que vous exécutez Oracle Enterprise Edition. Certaines des fonctionnalités décrites dans ce guide sont concédées sous licence distincte de la licence Enterprise Edition. Ces fonctionnalités incluent, sans s'y limiter, par:
- Clusters Oracle Real Application
- 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 de l'application
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'arrêt acceptable pour un système, et le RPO décrit la perte de données acceptable. Les coûts la complexité d'un système augmente à mesure que chacune de ces valeurs diminue. Pour en savoir plus sur le RTO et le RPO, consultez la section Principes de base d'un plan de reprise après sinistre.
Architectures libellées "RPO = 0" ou « zéro perte de données » nécessitent les données doivent être écrites à plusieurs emplacements avant d’être considérées comme « validées ». à 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é par rapport à la reprise après sinistre
La haute disponibilité et la reprise après sinistre sont des concepts complémentaires concevoir des architectures de base de données fiables. Dans le contexte de ce guide, la haute disponibilité désigne la capacité d'un système à récupérer automatiquement contre les défaillances individuelles ou en cascade sur le système. 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 couvre un champ d'application 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 hautement disponible doit pouvoir faire face aux défaillances individuelles et continuer à s'exécuter sans entraîner de temps d'arrêt pour l'application. Les composants de haute disponibilité d'un système doivent inclure, mais sans s'y limiter, les éléments suivants :
- Alimentation redondante sur le serveur, le réseau ou le matériel de stockage
- Plusieurs interfaces réseau, commutateurs et câbles
- Des fabrics, des contrôleurs et des dispositifs de stockage redondants
- Des interconnexions partenaires tolérantes aux pannes entre Google Cloud et le Extension de région de la solution Bare Metal
- Oracle RAC pour éviter que les défaillances du serveur ne désactivent une base de données
Une conception de reprise après sinistre doit inclure des processus de reprise après sinistre les défaillances en cascade qui rendent les composants indisponibles. Reprise après sinistre la planification doit tenir compte des points suivants:
- Pannes régionales
- Catastrophes naturelles
- Incidents entraînant l'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é:
- Clusters Oracle Real Application
- Oracle Recovery Manager
- Oracle Data Guard
- Base de données Flashback
- Oracle GoldenGate
Clusters Oracle Real Application
Oracle Real Application Clusters (RAC) permet de faire évoluer horizontalement les charges de travail de base de données à être gérées par plusieurs serveurs de base de données. Les bases de données qui utilisent RAC permettent une configuration active/active entre les serveurs d'une extension de région.
RAC est généralement utilisé pour assurer une haute disponibilité aux 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) du clustering, un cluster RAC exécuté dans un environnement de solution Bare Metal doit exister dans un seul pod de solution Bare Metal. RAC est donc une solution aux problèmes de haute disponibilité, mais ne répond pas aux exigences de reprise après sinistre.
Pour savoir comment configurer RAC pour la solution Bare Metal, consultez Installez Oracle RAC sur la solution Bare Metal.
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 peut lire le format de fichier de données propriétaire d'Oracle. Il peut être utilisé pour effectuer des clones de base de données, une récupération à un moment précis ou même la récupération d'une table unique dans une base de données Oracle.
RMAN est le seul outil qui permet de créer des sauvegardes lorsque la base de données est ouverte. Il est également utilisé pour 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 les clusters RAC distants de base de données. Data Guard prend en charge les bases de données de secours une configuration physique ou logique.
Les bases de données de secours physiques 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 création de rapports.
Pour découvrir comment configurer Data Guard sur la solution Bare Metal, consultez la section 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 spécifique dans le temps sans avoir à effectuer de restaurations de base de données fastidieuses.
Dans le contexte de la reprise après sinistre, FLASHBACK DATABASE est couramment utilisé avec Data Guard lors des opérations de basculement pour une restauration plus rapide de la base de données. La base de données défaillante est flashée à un moment précis qui est cohérent avec les journaux de la nouvelle instance principale, et la relecture est envoyée afin qu'elle puisse se resynchroniser complètement.
Oracle GoldenGate
Oracle GoldenGate est un outil de réplication logique couramment utilisé pour
permettre des déploiements multisites actifs/actifs ou déplacer des données sur du matériel ;
plates-formes. Lorsque vous utilisez GoldenGate, un processus extract sur la base de données source capture les modifications dans les journaux de rétablissement en ligne et les écrit dans les fichiers de trace, qui sont transportés vers la base de données cible. Un processus replicat sur le
la base de données cible convertit les transactions des fichiers de queue en SQL et exécute la
SQL sur la base de données cible.
Cette architecture fait de GoldenGate un outil puissant pour déplacer des données entre des plates-formes de base 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. en raison du fait que les transactions sont traduites et appliquées au format SQL la base de données cible. Bien que GoldenGate offre un délai minimal pour la réplication, À lui seul, GoldenGate ne peut pas garantir 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 des modèles de reprise après sinistre recommandés pour le déploiement des applications et des bases de données.
Chacun des modèles suivants fournit des objectifs RTO et RPO spécifiques:
Les modèles sont mappés à des modèles de déploiement spécifiques qui répondent aux objectifs RPO et RTO en cas d'indisponibilités planifiées et non planifiées. Chaque charge de travail de base de données évalué selon ses exigences de disponibilité et conçu avec une couche du modèle. 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 de 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 même si une base de données de secours est déployée.
Modèle en cuivre
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 sur un stockage situé en dehors de l'extension de région. Ce nécessite une approche en deux étapes, mais il est possible de rédiger un script pour utiliser Google Cloud SDK pour 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. L'ARM ne peut pas accéder directement aux sauvegardes. Elles doivent donc être déplacées vers un l'emplacement de stockage est disponible pour l'ARM avant que la récupération puisse commencer.
| Indisponibilité | Type d'interruption | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable de nœud ou d'instance | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes : corruptions | Dernière sauvegarde d'archive, sauvegarde incrémentielle ou complète qui a été transféré hors de l'environnement d'exécution | 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 complète, incrémentielle ou archivelog transférée hors de la RE | Jours / semaines, en fonction du temps nécessaire pour remettre l'extension de région en ligne | |
| Planifié | Correctifs de base de données, mises à jour de l'OS/du micrologiciel | 0 | Délai 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 de bronze propose deux options de déploiement. Ils utilisent tous deux le stockage cloud natif de Google pour conserver les sauvegardes de la base de données.
Déploiement de niveau bronze 1 : sauvegarde sur un stockage régional
Dans ce déploiement, les sauvegardes sont écrites directement 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 concernant l'utilisation de Cloud Storage FUSE sont disponibles dans "Sauvegardes Oracle". avec NFS et Cloud Storage. Google Cloud Filestore qui présente des partages NFS aux instances de la solution Bare Metal, peut également être utilisé.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type d'interruption | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable de nœud ou d'instance | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes: corruptions | Dernière sauvegarde complète, incrémentielle ou journal d'archivage | 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 complète, incrémentielle ou archivelog | Jours/semaines, selon le temps nécessaire pour remettre la fonctionnalité en ligne | |
| Planifié | Correctifs de base de données, mises à jour de l'OS/du micrologiciel | 0 | Délai 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 la sauvegarde et de la reprise après sinistre
Dans ce déploiement, le service de sauvegarde et de reprise après sinistre est utilisé pour stocker les sauvegardes Google Cloud. La sauvegarde et la reprise après sinistre offrent une approche incrémentielle permanente pour les sauvegardes, qui sont stockées sur des supports hautes performances compatibles avec Cloud Storage pour une 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, puisqu'il peut immédiatement des images des fichiers de base de données disponibles pour l'instance Oracle. La fonctionnalité d'installation et de migration met 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 d'interruption | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable de nœud ou d'instance | 0 | Temps nécessaire au redémarrage de l'instance
Secondes si vous utilisez RAC |
| Catastrophes: corruptions | Dernière sauvegarde d'archive, sauvegarde incrémentielle ou complète | Quelques minutes, voire plusieurs heures, en fonction des exigences de performances, de la taille de la base de données et de la bande passante attribuée à Interconnexion partenaire | |
| Catastrophes : défaillances de l'extension de région | Dernière sauvegarde d'archive, sauvegarde incrémentielle ou complète | Jours / semaines, en fonction du temps nécessaire pour remettre l'extension de région en ligne ou de la capacité du client à changer de région. | |
| Planifié | Correctifs de base de données, mises à jour de l'OS/du micrologiciel | 0 | Délai nécessaire pour mettre à jour et redémarrer l'instance |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures |
Noir et blanc
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 transport et l'application des modifications de la base de données à mesure qu'elles se produisent, la 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 du temps de réponse de l'application.
La fonctionnalité de basculement rapide de Data Guard peut exécuter des opérations de basculement si une base de données principale devient indisponible définie par l'utilisateur. La configuration est surveillée par un agent d'observateur, qui peut s'exécuter.
Le modèle Silver présente l'avantage de s'assurer que la base de données est disponible dans d'une défaillance régionale totale, mais les opérations de basculement et de commutation affecter les performances de l'application en tant que latence réseau entre l'application de serveurs et de bases de données. Il est rarement recommandé d'exécuter des applications et des bases de données associées dans différentes régions. Le RTO de la base de données peut être moins d'une minute, les cas de basculement d'application peuvent prendre de quelques minutes à plusieurs heures sont entièrement fonctionnels. Dans la plupart des cas, l'exécution de plans de basculement 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, des temps d'arrêt ou des intervalles de maintenance peuvent toujours être appliqués lors des activités trimestrielles d'application de correctifs. L'introduction d'Oracle RAC peut réduire les temps d'arrêt en cas de correctif ou de défaillance du serveur.
Le schéma suivant illustre un exemple de configuration.
L'exemple de configuration dans le diagramme montre
des bases de données RAC exécutées dans
us-west2 et us-east4 régions. La réplication est configurée à l'aide d'outils asynchrones
Protection des données. Tout le trafic entre la solution Bare Metal et Google Cloud
transite par interconnexion partenaire et le trafic interrégional transite
sur le réseau backbone du réseau Google. Les serveurs d'applications 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 d'interruption | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable de nœud ou d'instance | 0 | Temps nécessaire pour redémarrer l'instance
Secondes si vous utilisez RAC |
| Catastrophes : corruptions | < 60 s | De quelques minutes à plusieurs heures, en fonction du basculement de l'application. | |
| Catastrophes : échecs de l'extension de région | < 60s | De quelques minutes à plusieurs heures, en fonction du 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.
Secondes en cas d'utilisation de RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
Quelques minutes si vous utilisez |
Modèle Gold
Si vous êtes préoccupé par la perte de données dans le modèle Silver, vous pouvez opter pour le modèle Gold, qui utilise une instance de synchronisation à distance pour fournir une réplication synchrone à une instance exécutée dans Google Cloud Compute Engine.
Une instance de synchronisation éloignée inclut un fichier de contrôle de base de données et un ensemble de rétablissements de l'instance de secours des journaux qui s'exécutent géographiquement à proximité de la base de données principale. Cette instance est configuré pour recevoir des rétablissements de manière synchrone avec une faible latence, permettant les modifications seront enregistrées en dehors de l'extension de région de la base de données principale. L'instance de synchronisation à distance transfère ensuite la nouvelle exécution à la base de données de secours de la région distante pour l'appliquer de manière asynchrone.
Une instance de synchronisation éloignée n'est pas une copie complète de la base de données et ne peut donc pas gérer le trafic des applications. L'instance de synchronisation à distance permet de fournir un emplacement tolérant aux pannes pour que les modifications de la base de données soient écrites de manière synchrone, ce qui permet d'obtenir une solution sans perte de données. Lors de l'exécution d'une réplication synchrone sur la synchronisation distante les transactions ne sont validées sur la base de données principale les modifications ont été reçues et validées sur l'instance de synchronisation éloignée.
Les instances Compute Engine sont généralement sélectionnées pour être hébergées une instance de synchronisation éloignée. Placer l'instance de synchronisation à distance dans une zone Compute Engine à proximité immédiate 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 à distance, qui reçoit une nouvelle exécution de manière synchrone. L'instance de synchronisation éloignée est configurée pour envoyer la répétition de manière asynchrone à un RAC.
base de données 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 des applications en cas de sinistre.
| Indisponibilité | Type d'interruption | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable de nœud ou d'instance | 0 | Temps nécessaire pour redémarrer l'instance
Secondes si vous utilisez RAC |
| Catastrophes: corruptions | 0 | Quelques minutes à quelques heures, en fonction du basculement régional de l'application. | |
| Catastrophes : échecs de l'extension de région | 0 | Quelques minutes à quelques heures, en fonction du 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.
Secondes en cas d'utilisation de RAC |
| Mise à niveau majeure de la base de données | 0 | 1 à 2 heures
Quelques minutes si vous utilisez |
Modèle Platinum
Le modèle Platinum propose deux options de déploiement. Chaque option de déploiement fournit protection à l'aide d'une technologie différente, avec un RTO et un RPO différents caractéristiques.
Déploiement Platinum 1: Protection des données avec basculement à démarrage rapide
Le déploiement Platinum 1 s'appuie sur le déploiement du modèle Gold en ajoutant dans la région locale une deuxième base de données de secours Data Guard qui s'exécute sur un Instance Compute Engine. Cette configuration utilise la réplication synchrone entre la base de données principale et l'instance de secours exécutée dans Compute Engine, en fournissant une garantie de zéro 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 de basculer et de basculer les bases de données sans affecter les applications. Lors des modifications de rôle de base de données, les applications configurées conformément aux considérations client d'Oracle se reconnectent automatiquement à la nouvelle base de données principale sans intervention manuelle. Les applications correctement configurées subissent moins de deux minutes d'indisponibilité 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 s'exécute en tant que base de données principale. Cette instance peut s'exécuter dans une forme plus petite en mode veille et à la hausse lors des événements de basculement, ou s'exécutent à pleine capacité fois. La 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 pendant l'opération de redimensionnement.
Le basculement rapide est configuré sur une instance Compute Engine exécutant le courtier 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 un dans la base de données principale, un basculement vers l'une des instances les bases de données. 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 niveau Gold.
Oracle recommande de placer l'observateur dans une région distincte de principale et de secours. Cette approche offre la meilleure protection contre les défaillances régionales et les événements de partitionnement réseau. Si une troisième région n'est pas possible, l'observateur doit être installé dans la région principale, dans une zone différente de celle de la région de secours proche du site.
Le schéma suivant illustre un exemple de déploiement.
L'exemple de déploiement présenté 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 - Une base de données de secours à proximité d'un site s'exécutant sur une instance Compute Engine dans
Région
us-west2. - Une base de données de secours à distance s'exécutant sur un serveur de solution Bare Metal dans
us-east4dans la même région. - Observateur Data Guard exécuté sur l'instance Compute Engine dans
us-central1dans la même région.
La réplication synchrone est configurée pour la base de données de secours dans la région exécutée 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é avec 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 de transfert). Les instances d'application sont configurées dans la région us-east4 sur
Compute Engine pour gérer le trafic des applications en cas de sinistre.
| Indisponibilité | Type d'interruption | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable de nœud ou d'instance | 0 | Temps nécessaire pour redémarrer l'instance
Secondes si vous utilisez RAC |
| Catastrophes: corruptions | 0 | < 60s | |
| 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.
Secondes en cas d'utilisation de 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 repose sur l'utilisation d'Oracle GoldenGate pour la réplication. Étant donné que GoldenGate ne réplique pas au niveau des blocs. Elle permet à chaque base de données de de lecture et d'écriture des sessions d'application indépendamment. Il réplique les modifications de manière bidirectionnelle, ce qui permet une configuration de base de données active/active.
Les demandes doivent être validées minutieusement. avant de valider une configuration déploiement, et vous devez tenir compte du détection et 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 actifs/actifs nécessitent généralement une conception de schéma et d'application sophistiquée pour tirer parti d'un déploiement de base de données multisite. De nombreuses applications prêtes à l'emploi ne fonctionnent sont 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. Vous pouvez déployer des bases de données de secours locales exécutées dans Compute Engine à l'aide de Data Guard pour obtenir un RPO de zéro avec une réplication synchrone.
Le schéma suivant illustre un exemple de déploiement.
| Indisponibilité | Type d'interruption | RPO | Retour au bureau |
|---|---|---|---|
| Non planifiées | Défaillance récupérable de nœud ou d'instance | 0 | Temps nécessaire pour redémarrer l'instance |
| Catastrophes: corruptions | Secondes en minutes
0 si vous utilisez Data Guard dans chaque emplacement |
0 | |
| Catastrophes: échecs d'extension de région | Secondes en 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.
Secondes en cas d'utilisation de RAC |
| Mise à niveau majeure de la base de données | 0 | 0 |