Conditions requises pour le passage à Oracle Data Guard

Avant de lancer le basculement d'Oracle Data Guard, assurez-vous que votre environnement de réplication répond aux exigences suivantes :

• La base de données secondaire d'origine est montée ou ouverte en lecture seule.

• Les sauvegardes automatiques sont activées sur la base de données secondaire d'origine.

• La base de données principale d'origine et la base de données de secours d'origine sont dans available cet état.

• La base de données principale d'origine et la base de données de secours d'origine n'ont aucune action de maintenance en attente dans les états suivants : requirednext window, ouin progress. Les actions dans ces états bloquent le passage au numérique. Pour savoir comment vérifier l'état des mises à jour de maintenance en attente, consultezAfficher les mises à jour de maintenance en attente.

  Les actions de maintenance en attente dans l'availableÉtat ne bloquent pas le passage au numérique. RDS for Oracle publie fréquemment des mises à jour du système d'exploitation (OS) dans l'availableÉtat. Ces mises à jour du système d'exploitation en attente ne bloqueront pas un changement, sauf si vous les planifiez pour la fenêtre de maintenance suivante, ce qui les place dans cet état. next window

  Note

  Si vous souhaitez différer une action de maintenance planifiée afin de pouvoir exécuter un changement, choisissez Actions, puis Différer la mise à niveau dans la console RDS. Vous pouvez également empêcher le blocage d'une commutation en appliquant une action de maintenance en attente ou en déplaçant la fenêtre de maintenance sur un intervalle avant votre transition. Pour plus d'informations, consultez l'article Re:post Comment supprimer les éléments RDS en attente de maintenance.

• La base de données secondaire d'origine est en état de réplication.

• Vous n'essayez pas de lancer un basculement lorsque la base de données principale ou la base de données secondaire est actuellement dans un cycle de vie de basculement. Si une base de données de réplica est en train de se reconfigurer après un basculement, Amazon RDS vous empêche de lancer un nouveau basculement.

  Note

  Un réplica de secours est un réplica dans la configuration Oracle Data Guard qui n'est pas la cible du basculement. Les réplicas de secours peuvent se trouver dans n'importe quel état pendant le basculement.

• La configuration de la base de données secondaire d'origine est aussi proche que possible de celle de la base de données principale d'origine. Prenons un scénario dans lequel les bases de données principale et secondaire d'origine ont des options différentes. Une fois le basculement terminé, Amazon RDS ne reconfigure pas automatiquement la nouvelle base de données principale pour qu'elle dispose des mêmes options que la base de données principale d'origine.

• Vous configurez le déploiement multi-AZ que vous souhaitez avant de lancer un basculement. Amazon RDS ne gère pas le déploiement multi-AZ dans le cadre du basculement. Le déploiement multi-AZ reste tel quel.

  Supposons que db_maz soit la base de données principale dans un déploiement multi-AZ et que db_saz soit un réplica mono-AZ. Vous lancez un basculement de db_maz vers db_saz. Par la suite, db_maz est une base de données de réplica multi-AZ et db_saz est une base de données principale mono-AZ. La nouvelle base de données principale n'est désormais pas protégée par un déploiement multi-AZ.

• En prévision d'un basculement entre régions, la base de données principale n'utilise pas le même groupe d'options qu'une instance de base de données en dehors de la configuration de réplication. Pour qu'un basculement entre régions réussisse, la base de données principale actuelle et ses réplicas en lecture doivent être les seules instances de base de données à utiliser le groupe d'options de la base de données principale actuelle. Dans le cas contraire, Amazon RDS empêche le basculement.