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 SQL Server à un moment donné
Vous pouvez restaurer une instance de base de données à un moment précis (PITR), en créant une nouvelle instance de base de données. Pour être prises en chargePITR, la rétention des sauvegardes doit être activée sur vos instances de base de données.
L'heure de restauration la plus récente pour une instance de base de données RDS Custom for SQL Server dépend de plusieurs facteurs, mais elle se situe généralement à moins de 5 minutes de l'heure actuelle. Pour connaître l'heure de restauration la plus récente pour une instance de base de données, utilisez la AWS CLI describe-db-instancescommande et examinez la valeur renvoyée dans le LatestRestorableTime
champ correspondant à l'instance de base de données. Pour connaître l'heure de restauration la plus récente pour chaque instance de base de données dans la RDS console Amazon, choisissez 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 connaître l'heure de restauration la plus proche pour chaque instance de base de données, choisissez Sauvegardes automatisées dans la RDS console Amazon.
Pour obtenir des informations générales sur PITR, veuillez consulter Restauration d'une instance de base de données à une heure spécifiée pour Amazon RDS.
Rubriques
PITRconsidérations relatives à RDS Custom for SQL Server
Dans RDS Custom for SQL Server, PITR les différences importantes suivantes sont les suivantes par rapport PITR à Amazon RDS :
-
PITRrestaure uniquement les bases de données dans l'instance de base de données. Il ne restaure pas le système d'exploitation ou les fichiers du lecteur C:.
-
Pour une instance de base de données RDS personnalisée pour SQL serveur, une base de données est sauvegardée automatiquement et PITR n'est éligible que dans les conditions suivantes :
-
La base de données est en ligne.
-
Son modèle de récupération est défini sur
FULL
. -
Elle est inscriptible.
-
Ses fichiers physiques sont sur le lecteur D:.
-
Elle n'est pas répertoriée dans le tableau
rds_pitr_blocked_databases
. Pour de plus amples informations, veuillez consulter Rendre les bases de données inéligibles à PITR.
-
-
Les bases de données éligibles PITR sont déterminées par l'ordre de leur identifiant de base de données. RDSCustom for SQL Server autorise jusqu'à 5 000 bases de données par instance de base de données. Toutefois, le nombre maximum de bases de données restaurées par une PITR opération pour une instance de base de données RDS Custom for SQL Server dépend du type de classe d'instance. Pour de plus amples informations, veuillez consulter Nombre de bases de données éligibles PITR par type de classe d'instance.
Les autres bases de données qui n'en font pas partie PITR peuvent être restaurées à partir de snapshots de base de données, y compris les sauvegardes automatiques de snapshots utilisées pourPITR.
-
L'ajout d'une nouvelle base de données, le changement de nom d'une base de données ou la restauration d'une base de données éligible à PITR initie un instantané de l'instance de base de données.
-
Le nombre maximum de bases de données susceptibles d'être PITR modifiées lorsque l'instance de base de données est soumise à une opération de calcul à l'échelle, en fonction du type de classe d'instance cible. Si l'instance est agrandie, ce qui permet à un plus grand nombre de bases de données de l'instance d'être éligiblesPITR, un nouvel instantané est pris.
-
Les bases de données restaurées portent le même nom que dans l'instance de base de données source. Vous ne pouvez pas spécifier un autre nom.
-
AWSRDSCustomSQLServerIamRolePolicy
nécessite l'accès à d'autres AWS services. Pour de plus amples informations, veuillez consulter Ajoutez une politique d'accès à AWSRDSCustomSQLServerInstanceRole. -
Les modifications de fuseau horaire ne sont pas prises en charge pour RDS Custom for SQL Server. Si vous modifiez le système d'exploitation ou le fuseau horaire de l'instance de base de données PITR (et toute autre automatisation), cela ne fonctionne pas.
Nombre de bases de données éligibles PITR par type de classe d'instance
Le tableau suivant indique le nombre maximum de bases de données éligibles en PITR fonction du type de classe d'instance.
Type de classe d'instance | Nombre maximum de bases de données PITR éligibles |
---|---|
db.*.large | 100 |
db.*.xlarge vers db.*.2xlarge | 150 |
db.*.4xlarge vers db.*.8xlarge | 300 |
db.*.12xlarge vers db.*.16xlarge | 600 |
db.*.24xlarge, db.*32xlarge | 1 000 |
*
Représente différents types de classes d'instance.
Le nombre maximum de bases de données éligibles PITR sur une instance de base de données dépend du type de classe d'instance. Ce nombre est compris entre 100 pour les plus petits et 1 000 pour les plus grands types de classes d'instance pris en charge par RDS Custom for SQL Server. SQLles bases de données (master, model, msdb, tempdb)
du système serveur ne sont pas incluses dans cette limite. Lorsqu'une instance de base de données est redimensionnée à la hausse ou à la baisse, selon le type de classe d'instance cible, RDS Custom met automatiquement à jour le nombre de bases de données éligiblesPITR. RDSCustom for SQL Server sera envoyé RDS-EVENT-0352
lorsque le nombre maximum de bases de données éligibles à des PITR modifications sur une instance de base de données est modifié. Pour de plus amples informations, veuillez consulter Événements de version du moteur personnalisés.
Note
PITRla prise en charge de plus de 100 bases de données n'est disponible que sur les instances de base de données créées après le 26 août 2023. Pour les instances créées avant le 26 août 2023, le nombre maximum de bases de données éligibles PITR est de 100, quelle que soit la classe d'instance. Pour activer la PITR prise en charge de plus de 100 bases de données sur des instances de base de données créées avant le 26 août 2023, vous pouvez effectuer l'action suivante :
Mettez à niveau la version du moteur de base de données vers la version 15.00.4322.2.v1 ou supérieure
Au cours d'une PITR opération, RDS Custom restaure toutes les bases de données qui faisaient partie de l'instance de PITR base de données source au moment de la restauration. Une fois que l'instance de base de données cible a terminé les opérations de restauration, si la conservation des sauvegardes est activée, l'instance de base de données commence à sauvegarder en fonction du nombre maximum de bases de données éligibles PITR sur l'instance de base de données cible.
Par exemple, si votre instance de base de données s'exécute sur une instance db.*.xlarge
contenant 200 bases de données :
RDSCustom for SQL Server choisira les 150 premières bases de données, classées par leur ID de base de données, à PITR sauvegarder.
Vous modifiez l'instance pour la mettre à l'échelle jusqu'à db.*.4xlarge.
Une fois l'opération de calcul de l'échelle terminée, RDS Custom for SQL Server choisira les 300 premières bases de données, classées par leur ID de base de données, à PITR sauvegarder. Chacune des 200 bases de données répondant aux conditions PITR requises sera désormais éligiblePITR.
Vous modifiez maintenant l'instance pour la réduire à db.*.xlarge.
Une fois l'opération de calcul de l'échelle terminée, RDS Custom for SQL Server sélectionnera à nouveau les 150 premières bases de données, classées par leur ID de base de données, à PITR sauvegarder.
Rendre les bases de données inéligibles à PITR
Vous pouvez choisir d'exclure des bases de données individuelles dePITR. Pour ce faire, mettez leurs valeurs database_id
dans un tableau rds_pitr_blocked_databases
. Utilisez le SQL script suivant pour créer la table.
Pour créer la table rds_pitr_blocked_databases
-
Exécutez le SQL script suivant.
create table msdb..rds_pitr_blocked_databases ( database_id INT NOT NULL, database_name SYSNAME NOT NULL, db_entry_updated_date datetime NOT NULL DEFAULT GETDATE(), db_entry_updated_by SYSNAME NOT NULL DEFAULT CURRENT_USER, PRIMARY KEY (database_id) );
Pour obtenir la liste des bases de données éligibles et non éligibles, consultez le fichier RI.End
dans le répertoire RDSCustomForSQLServer/Instances/
du compartiment Amazon S3 DB_instance_resource_ID
/TransactionLogMetadatado-not-delete-rds-custom-
. Pour plus d'informations sur le fichier $ACCOUNT_ID
-$REGION
-unique_identifier
RI.End
, consultez Journaux de transactions dans Amazon S3.
Vous pouvez également déterminer la liste des bases de données éligibles à PITR l'utilisation du SQL script suivant. Définissez la @limit
variable sur le nombre maximum de bases de données éligibles PITR pour la classe d'instance. Pour de plus amples informations, veuillez consulter Nombre de bases de données éligibles PITR par type de classe d'instance.
Pour déterminer la liste des bases de données éligibles pour une classe PITR d'instance de base de données
-
Exécutez le SQL script suivant.
DECLARE @Limit INT; SET @Limit = (insert-database-instance-limit-here); USE msdb; IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'dbo' AND TABLE_NAME = 'rds_pitr_blocked_databases')) WITH TABLE0 AS ( SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable FROM sys.dm_hadr_database_replica_states hdrs INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY') ), TABLE1 as ( SELECT dbs.database_id as DatabaseId, sysdbs.name as DatabaseName, 'OPTOUT' as Reason, CASE WHEN dbs.database_name = sysdbs.name THEN NULL ELSE dbs.database_name END AS DatabaseNameOnPitrTable FROM msdb.dbo.rds_pitr_blocked_databases dbs INNER JOIN sys.databases sysdbs ON dbs.database_id = sysdbs.database_id WHERE sysdbs.database_id > 4 ), TABLE2 as ( SELECT db.name AS DatabaseName, db.create_date AS CreateDate, db.state_desc AS DatabaseState, db.database_id AS DatabaseId, rs.database_guid AS DatabaseGuid, rs.last_log_backup_lsn AS LastLogBackupLSN, rs.recovery_fork_guid RecoveryForkGuid, rs.first_recovery_fork_guid AS FirstRecoveryForkGuid, db.recovery_model_desc AS RecoveryModel, db.is_auto_close_on AS IsAutoClose, db.is_read_only as IsReadOnly, NEWID() as FileName, CASE WHEN(db.state_desc = 'ONLINE' AND db.recovery_model_desc != 'SIMPLE' AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) AND db.is_read_only != 1 AND db.user_access = 0 AND db.source_database_id IS NULL AND db.is_in_standby != 1 THEN 1 ELSE 0 END AS IsPartOfSnapshot, CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot FROM sys.databases db INNER JOIN sys.database_recovery_status rs ON db.database_id = rs.database_id WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE1) AND db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0) ), TABLE3 as( Select @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE2 where TABLE2.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb') ) SELECT TOP(SELECT TotalNumberOfDatabases from TABLE3) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE2 where TABLE2.IsPartOfSnapshot=1 ORDER BY TABLE2.DatabaseID ASC ELSE WITH TABLE0 AS ( SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable FROM sys.dm_hadr_database_replica_states hdrs INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY') ), TABLE1 as ( SELECT db.name AS DatabaseName, db.create_date AS CreateDate, db.state_desc AS DatabaseState, db.database_id AS DatabaseId, rs.database_guid AS DatabaseGuid, rs.last_log_backup_lsn AS LastLogBackupLSN, rs.recovery_fork_guid RecoveryForkGuid, rs.first_recovery_fork_guid AS FirstRecoveryForkGuid, db.recovery_model_desc AS RecoveryModel, db.is_auto_close_on AS IsAutoClose, db.is_read_only as IsReadOnly, NEWID() as FileName, CASE WHEN(db.state_desc = 'ONLINE' AND db.recovery_model_desc != 'SIMPLE' AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) AND db.is_read_only != 1 AND db.user_access = 0 AND db.source_database_id IS NULL AND db.is_in_standby != 1 THEN 1 ELSE 0 END AS IsPartOfSnapshot, CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot FROM sys.databases db INNER JOIN sys.database_recovery_status rs ON db.database_id = rs.database_id WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0) ), TABLE2 as( SELECT @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE1 where TABLE1.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb') ) select top(select TotalNumberOfDatabases from TABLE2) DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE1 where TABLE1.IsPartOfSnapshot=1 ORDER BY TABLE1.DatabaseID ASC
Note
Les bases de données qui ne sont que des liens symboliques sont également exclues des bases de données éligibles aux PITR opérations. La requête ci-dessus ne filtre pas en fonction de ces critères.
Journaux de transactions dans Amazon S3
La période de conservation des sauvegardes détermine si les journaux de transactions des instances de base de données RDS Custom for SQL Server sont automatiquement extraits et chargés sur Amazon S3. Une valeur différente de zéro signifie que des sauvegardes automatiques sont créées et que l'agent RDS personnalisé télécharge les journaux de transactions sur S3 toutes les 5 minutes.
Les journaux des transactions sur S3 sont chiffrés au repos à l'aide de la AWS KMS key que vous avez fournie lors de la création de votre instance de base de données. Pour plus d'informations, consultez la section Protection des données à l'aide du chiffrement côté serveur dans le Guide de l'utilisateur Amazon Simple Storage Service.
Les journaux de transactions de chaque base de données sont chargés dans un compartiment S3 nommé do-not-delete-rds-custom-
. Le répertoire $ACCOUNT_ID
-$REGION
-unique_identifier
RDSCustomForSQLServer/Instances/
dans le compartiment S3 contient deux sous-répertoires :DB_instance_resource_ID
-
TransactionLogs
– Contient les journaux de transactions de chaque base de données et leurs métadonnées respectives.Le nom du fichier journal des transactions suit le modèle
, par exemple :yyyyMMddHHmm
.database_id
.timestamp
202110202230.11.1634769287
Le même nom de fichier avec le suffixe
_metadata
contient des informations sur le journal des transactions telles que les numéros de séquence de journaux, le nom de la base de données etRdsChunkCount
.RdsChunkCount
détermine le nombre de fichiers physiques qui représentent un fichier journal de transactions unique. Vous pouvez voir des fichiers contenant des suffixes_0001
,_0002
, et ainsi de suite, ce qui correspond aux morceaux physiques d'un fichier journal de transactions. Si vous souhaitez utiliser un fichier journal de transactions en morceaux, veillez à fusionner les morceaux après les avoir téléchargés.Imaginons un scénario dans lequel vous disposez des fichiers suivants :
-
202110202230.11.1634769287
-
202110202230.11.1634769287_0001
-
202110202230.11.1634769287_0002
-
202110202230.11.1634769287_metadata
Le
RdsChunkCount
est3
. L'ordre de fusion des fichiers est le suivant :202110202230.11.1634769287
,202110202230.11.1634769287_0001
,202110202230.11.1634769287_0002
. -
-
TransactionLogMetadata
– Contient des informations de métadonnées sur chaque itération de l'extraction du journal de transactions.Le fichier
RI.End
contient des informations sur toutes les bases de données dont les journaux de transactions ont été extraits, et toutes les bases de données existantes mais dont les journaux de transactions n'ont pas été extraits. Le nom de fichierRI.End
suit le modèle
, par exemple :yyyyMMddHHmm
.RI.End.timestamp
202110202230.RI.End.1634769281
PITRRestaurez à l'aide du AWS Management ConsoleAWS CLI, du ou du RDSAPI.
Vous pouvez restaurer une instance de base de données RDS personnalisée pour SQL serveur à un moment donné en utilisant le AWS Management Console AWS CLI, le ou le RDSAPI.
Pour restaurer une instance de base de données RDS personnalisée à une heure spécifiée
Connectez-vous à la RDS console Amazon AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/
. -
Dans le panneau de navigation, choisissez Automated backups (Sauvegardes automatisées).
-
Choisissez l'instance de base de données RDS personnalisée que vous souhaitez restaurer.
-
Sous Actions, sélectionnez Restaurer à un moment donné.
La fenêtre Restaurer à un instant dans le passé s'affiche.
-
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 affichées dans votre fuseau horaire local, qui est indiqué par un décalage par rapport au temps universel coordonné (UTC). Par exemple, UTC -5 correspond à l'heure normale de l'Est/heure avancée du centre.
-
Pour l'identifiant de l'instance de base de données, entrez le nom de l'instance de base de données RDS personnalisée restaurée cible. Le nom doit être unique.
-
Choisissez d'autres options selon vos besoins, comme la classe d'instance de base de données.
-
Choisissez Restaurer à un instant dans le passé.
Vous restaurez une instance de base de données à une heure spécifiée en utilisant la point-in-time AWS CLI commande restore-db-instance-to- pour créer une nouvelle instance de base de données RDS personnalisée.
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é.
Dans Linux, macOS, ou Unix:
aws rds restore-db-instance-to-point-in-time \ --source-db-instance-identifier
my-custom-db-instance
\ --target-db-instance-identifiermy-restored-custom-db-instance
\ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance
\ --restore-time2022-10-14T23:45:00.000Z
Dans Windows:
aws rds restore-db-instance-to-point-in-time ^ --source-db-instance-identifier
my-custom-db-instance
^ --target-db-instance-identifiermy-restored-custom-db-instance
^ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance
^ --restore-time2022-10-14T23:45:00.000Z