Restauration d'une instance RDS Custom for Oracle à un instant dans le passé - Amazon Relational Database Service
Considérations PITR pour RDS Custom for Oracle

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Restauration d'une instance RDS Custom for Oracle à un instant dans le passé

Vous pouvez restaurer une instance de base de données à un point donné dans le temps (PITR), et créer ainsi une nouvelle instance de base de données. Pour prendre en charge le PITR, la rétention des sauvegardes de vos instances de base de données doit être définie sur une valeur différente de zéro.

La dernière date de restauration d'une instance de base de données RDS Custom for Oracle dépend de plusieurs facteurs, mais se situe généralement dans les cinq minutes qui précèdent l'heure actuelle. Pour afficher l’heure de restauration la plus récente pour une instance de base de données, utilisez la commande describe-db-instances de la AWS CLI et examinez la valeur retournée dans le champ LatestRestorableTime de l’instance de base de données. Pour afficher l'heure de restauration la plus récente pour chaque instance de base de données dans la console Amazon RDS, choisissez Automated backups (Sauvegardes automatisées).

Vous pouvez procéder à une restauration à n'importe quel moment dans le passé au cours de la période de rétention des sauvegardes. Pour afficher l’heure de restauration la plus ancienne pour chaque instance de base de données, choisissez Automated backups (Sauvegardes automatisées) dans la console Amazon RDS.

Pour obtenir des informations générales sur le PITR, consultez Restauration d’une instance de base de données à un instant précis pour Amazon RDS.

Considérations PITR pour RDS Custom for Oracle

Dans RDS Custom for Oracle, le PITR diffère des manières importantes suivantes du PITR dans Amazon RDS :

  • La base de données restaurée porte le même nom que dans l'instance de base de données source. Vous ne pouvez pas spécifier un autre nom. La valeur par défaut est ORCL.

  • AWSRDSCustomIamRolePolicy nécessite de nouvelles autorisations. Pour plus d’informations, consultez Étape 2 : ajouter une politique d'accès à AWSRDSCustom InstanceRoleForRdsCustomInstance.

  • Toutes les instances de base de données RDS Custom for Oracle doivent avoir une rétention de sauvegarde définie sur une valeur différente de zéro.

  • Si vous modifiez le fuseau horaire du système d'exploitation ou de l'instance de base de données, le PITR peut ne pas fonctionner. Pour plus d'informations sur les changements de fuseaux horaires, consultez Fuseau horaire Oracle.

  • Si vous définissez l’automatisation sur ALL_PAUSED, RDS Custom interrompt le chargement des journaux de reprise archivés, y compris les journaux créés avant la dernière heure de restauration (LRT). Nous vous recommandons de mettre l'automatisation en pause pendant une courte période.

    Pour illustrer, supposons que votre LRT date d'il y a 10 minutes. Vous mettez l'automatisation en pause. Pendant la pause, RDS Custom ne charge pas les journaux de reprise archivés. Si votre instance de base de données tombe en panne, vous ne pouvez effectuer une restauration qu'à un moment avant le LRT qui existait lorsque vous avez mis en pause. Lorsque vous reprenez l'automatisation, RDS Custom reprend le chargement des journaux. Le LRT progresse. Les règles normales du PITR s'appliquent.

  • Dans RDS Custom, vous pouvez spécifier manuellement un nombre arbitraire d'heures pour conserver les journaux de reprise archivés avant que RDS Custom ne les supprime après le chargement. Spécifiez le nombre d'heures comme suit :

    1. Créez un fichier texte nommé /opt/aws/rdscustomagent/config/redo_logs_custom_configuration.json.

    2. Ajoutez un objet JSON au format suivant : {"archivedLogRetentionHours" : "num_of_hours"}. Le nombre doit être un nombre entier compris entre 1 et 840.

  • Supposons que vous connectiez une base de données non-CDB à une base de données de conteneur (CDB) en tant que PDB, puis que vous tentiez une restauration PITR. L'opération réussit seulement si vous avez précédemment sauvegardé la PDB. Après avoir créé ou modifié une PDB, nous vous recommandons de toujours la sauvegarder.

  • Nous vous recommandons de ne pas personnaliser les paramètres d'initialisation de base de données. Par exemple, la modification des paramètres suivants affecte le PITR :

    • CONTROL_FILE_RECORD_KEEP_TIME affecte les règles de chargement et de suppression des journaux.

    • LOG_ARCHIVE_DEST_n ne prend pas en charge plusieurs destinations.

    • ARCHIVE_LAG_TARGET affecte la dernière date de restauration. ARCHIVE_LAG_TARGET est défini sur 300 parce que l’objectif de point de reprise (RPO) est de 5 minutes. Pour atteindre cet objectif, RDS change le journal de reprise en ligne toutes les 5 minutes et le stocke dans un compartiment Amazon S3. Si la fréquence du changement de journal entraîne un problème de performance pour votre base de données RDS Custom for Oracle, vous pouvez mettre à l’échelle votre instance de base de données et votre stockage afin d’obtenir une instance offrant des IOPS et un débit plus élevés. Si cela est nécessaire pour votre plan de reprise, vous pouvez régler le paramètre d’initialisation ARCHIVE_LAG_TARGET sur une valeur comprise entre 60 et 7200.

  • Si vous personnalisez les paramètres d’initialisation de la base de données, nous vous recommandons fortement de personnaliser uniquement les éléments suivants :

    • COMPATIBLE

    • MAX_STRING_SIZE

    • DB_FILES

    • UNDO_TABLESPACE

    • ENABLE_PLUGGABLE_DATABASE

    • CONTROL_FILES

    • AUDIT_TRAIL

    • AUDIT_TRAIL_DEST

    Pour tous les autres paramètres d'initialisation, RDS Custom restaure les valeurs par défaut. Si vous modifiez un paramètre qui ne figure pas dans la liste précédente, cela peut avoir un effet négatif sur le PITR et entraîner des résultats imprévisibles. Par exemple, CONTROL_FILE_RECORD_KEEP_TIME affecte les règles de chargement et de suppression des journaux.

Vous pouvez restaurer une instance de base de données RDS Custom à un instant dans le passé à l'aide de la AWS Management Console, de la AWS CLI, ou de l'API RDS.

Pour restaurer une instance de base de données RDS personnalisée à un moment spécifié

  1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Automated backups (Sauvegardes automatisées).

  3. Choisissez l'instance de base de données RDS Custom que vous souhaitez restaurer.

  4. Sous Actions, sélectionnez Restaurer à un moment donné.

    La fenêtre Restaurer à un instant dans le passé s'affiche.

  5. Choisissez Dernière heure de restauration possible pour restaurer à la dernière heure possible, ou choisissez Personnalisé pour choisir une heure.

    Si vous choisissez Custom (Personnalisé), saisissez la date et l'heure auxquelles vous souhaitez restaurer l'instance.

    Les heures sont exprimées dans votre fuseau horaire local, qui est indiqué par son décalage par rapport à l’heure UTC. Par exemple, UTC-5 est l’heure normale de l’Est/heure avancée du Centre.

  6. Pour DB instance identifier (Identifiant d'instance de base de données), saisissez le nom de l'instance de base de données RDS Custom restaurée. Le nom doit être unique.

  7. Choisissez d'autres options selon vos besoins, comme la classe d'instance de base de données.

  8. Choisissez Restaurer à un instant dans le passé.

Vous restaurez une instance de base de données à un moment spécifié à l'aide de la commande AWS CLI restore-db-instance-to-point-in-time pour créer une instance de base de données RDS Custom.

Utilisez l'une des options suivantes pour spécifier la sauvegarde à partir de laquelle effectuer la restauration :

  • --source-db-instance-identifier mysourcedbinstance

  • --source-dbi-resource-id dbinstanceresourceID

  • --source-db-instance-automated-backups-arn backupARN

L’option custom-iam-instance-profile est obligatoire.

L'exemple suivant restaure my-custom-db-instance vers une nouvelle instance de base de données nommée my-restored-custom-db-instance au moment spécifié.

Pour Linux, macOS ou Unix :

aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier my-custom-db-instance\
    --target-db-instance-identifier my-restored-custom-db-instance \
    --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
    --restore-time 2022-10-14T23:45:00.000Z

Pour Windows :

aws rds restore-db-instance-to-point-in-time ^
    --source-db-instance-identifier my-custom-db-instance ^
    --target-db-instance-identifier my-restored-custom-db-instance ^
    --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
    --restore-time 2022-10-14T23:45:00.000Z