Ripristino di un'istanza RDS Custom for SQL Server in un determinato momento - Amazon Relational Database Service

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ripristino di un'istanza RDS Custom for SQL Server in un determinato momento

È possibile ripristinare un'istanza DB in un momento specifico (PITR), creando una nuova istanza DB. Per essere supportatePITR, le istanze DB devono avere la conservazione dei backup abilitata.

L'ultimo periodo di ripristino per un'istanza DB RDS Custom for SQL Server dipende da diversi fattori, ma in genere è entro 5 minuti dall'ora corrente. Per visualizzare l'ora di ripristino più recente per un'istanza DB, usa il AWS CLI describe-db-instancescomando e guarda il valore restituito nel LatestRestorableTime campo per l'istanza DB. Per visualizzare l'ora di ripristino più recente per ogni istanza DB nella RDS console Amazon, scegli Backup automatizzati.

Puoi eseguire il ripristino point-in-time durante il tempo di conservazione del backup. Per visualizzare la prima data di ripristino per ogni istanza DB, scegli Backup automatici nella console AmazonRDS.

Per informazioni generali su PITR, consulta Ripristino di un'istanza DB a un'ora specificata per Amazon RDS.

PITRconsiderazioni per Custom for Server RDS SQL

In RDS Custom for SQL Server, PITR si differenzia dai seguenti importanti aspetti rispetto PITR ad AmazonRDS:

  • PITRripristina solo i database nell'istanza DB. Non ripristina il sistema operativo o i file sull'unità C:.

  • Per un'istanza DB RDS Custom for SQL Server, il backup di un database viene eseguito automaticamente ed è idoneo PITR solo alle seguenti condizioni:

    • Il database è online.

    • Il suo modello di ripristino è impostato su FULL.

    • È scrivibile.

    • Ha i suoi file fisici sull'unità D:.

    • Non è elencato nella tabella rds_pitr_blocked_databases. Per ulteriori informazioni, consulta Rendere i database non idonei per PITR.

  • I database idonei PITR sono determinati dall'ordine del relativo ID di database. RDSCustom for SQL Server consente fino a 5.000 database per istanza DB. Tuttavia, il numero massimo di database ripristinati da un'PITRoperazione per un'istanza DB RDS Custom for SQL Server dipende dal tipo di classe dell'istanza. Per ulteriori informazioni, consulta Numero di database idonei per il tipo di classe PITR per istanza.

    Altri database di cui non fanno parte PITR possono essere ripristinati dalle istantanee del DB, inclusi i backup automatici delle istantanee utilizzati per. PITR

  • L'aggiunta di un nuovo database, la ridenominazione di un database o il ripristino di un database idoneo PITR avvia uno snapshot dell'istanza DB.

  • Il numero massimo di database idonei per le PITR modifiche quando l'istanza di database viene sottoposta a un'operazione di calcolo su scala, a seconda del tipo di classe dell'istanza di destinazione. Se l'istanza viene ampliata, in modo da consentire l'utilizzo di più database sull'istanzaPITR, viene scattata una nuova istantanea.

  • I database ripristinati hanno lo stesso nome dell’istanza database di origine. Non puoi specificare un nome diverso.

  • AWSRDSCustomSQLServerIamRolePolicyrichiede l'accesso ad altri AWS servizi. Per ulteriori informazioni, consulta Aggiungi una politica di accesso a AWSRDSCustom SQLServer InstanceRole.

  • Le modifiche al fuso orario non sono supportate per RDS Custom for SQL Server. Se si modifica il sistema operativo o il fuso orario dell'istanza DB, PITR (e altre automazioni) non funziona.

Numero di database idonei per il tipo di classe PITR per istanza

La tabella seguente mostra il numero massimo di database idonei in PITR base al tipo di classe di istanza.

Tipo di classe di istanza Numero massimo di database PITR idonei
db.*.large 100
da db.*.xlarge a db.*.2xlarge 150
db.*.4xlarge a db.*.8xlarge 300
db.*.12xlarge a db.*.16xlarge 600
db.*.24xlarge, db.*32xlarge 1000

*Rappresenta diversi tipi di classi di istanze.

Il numero massimo di database idonei per PITR un'istanza DB dipende dal tipo di classe di istanza. Il numero varia da 100 per i tipi di classe di istanza più piccoli a 1000 per i tipi di classi di istanza più grandi supportati da RDS Custom for SQL Server. SQLi database dei (master, model, msdb, tempdb) sistemi server non sono inclusi in questo limite. Quando un'istanza DB viene ridimensionata verso l'alto o verso il basso, a seconda del tipo di classe dell'istanza di destinazione, RDS Custom aggiornerà automaticamente il numero di database PITR idonei. RDSCustom for SQL Server verrà inviato RDS-EVENT-0352 quando il numero massimo di database idonei per la PITR modifica in un'istanza DB. Per ulteriori informazioni, consulta Eventi di versioni personalizzate del motore.

Nota

PITRil supporto per più di 100 database è disponibile solo sulle istanze DB create dopo il 26 agosto 2023. Per le istanze create prima del 26 agosto 2023, il numero massimo di database idonei PITR è 100, indipendentemente dalla classe di istanza. Per abilitare PITR il supporto per più di 100 database su istanze DB create prima del 26 agosto 2023, puoi eseguire la seguente azione:

  • Aggiorna la versione del motore DB alla versione 15.00.4322.2.v1 o successiva

Durante un'PITRoperazione, RDS Custom ripristinerà tutti i database che facevano parte dell'istanza DB di origine PITR al momento del ripristino. Una volta che l'istanza DB di destinazione ha completato le operazioni di ripristino, se la conservazione dei backup è abilitata, il backup dell'istanza DB inizierà in base al numero massimo di database idonei per PITR l'istanza DB di destinazione.

Ad esempio, se l'istanza DB viene eseguita su un'db.*.xlargeistanza con 200 database:

  1. RDSCustom for SQL Server sceglierà i primi 150 database, ordinati in base all'ID del database, per il PITR backup.

  2. L'istanza viene modificata per scalarla fino a db.*.4xlarge.

  3. Una volta completata l'operazione di calcolo della scalabilità, RDS Custom for SQL Server sceglierà i primi 300 database, ordinati in base all'ID del database, per il backup. PITR Ciascuno dei 200 database che soddisfano i PITR requisiti richiesti sarà ora PITR idoneo.

  4. Ora modifichi l'istanza per ridurla a db.*.xlarge.

  5. Una volta completata l'operazione di calcolo della scalabilità, RDS Custom for SQL Server selezionerà nuovamente i primi 150 database, ordinati in base all'ID del database, per il backup. PITR

Rendere i database non idonei per PITR

Puoi scegliere di escludere singoli database daPITR. Per fare questo, metti i loro valori database_id in una tabella rds_pitr_blocked_databases. Usa lo SQL script seguente per creare la tabella.

Per creare la tabella rds_pitr_blocked_databases
  • Esegui lo SQL script seguente.

    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) );

Per l'elenco dei database idonei e non idonei, consulta il file RI.End nella directory RDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadata nel bucket Amazon S3 do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier. Per ulteriori informazioni sul file RI.End, consulta Log sulle transazioni in Amazon S3.

È inoltre possibile determinare l'elenco dei database idonei per l'PITRutilizzo del seguente SQL script. Imposta la @limit variabile sul numero massimo di database idonei PITR per la classe di istanza. Per ulteriori informazioni, consulta Numero di database idonei per il tipo di classe PITR per istanza.

Per determinare l'elenco dei database idonei per PITR una classe di istanza DB
  • Esegui lo SQL script seguente.

    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
Nota

I database che sono solo collegamenti simbolici sono inoltre esclusi dai database idonei PITR alle operazioni. La query precedente non filtra in base a questi criteri.

Log sulle transazioni in Amazon S3

Il periodo di conservazione dei backup determina se i log delle transazioni per le istanze DB RDS Custom for SQL Server vengono estratti e caricati automaticamente su Amazon S3. Un valore diverso da zero significa che vengono creati backup automatici e che l'agente RDS Custom carica i log delle transazioni su S3 ogni 5 minuti.

I file di log delle transazioni su S3 sono crittografati mentre sono inattivi tramite AWS KMS key che hai fornito quando hai creato l'istanza database. Per ulteriori informazioni, consulta Protezione dei dati con la crittografia lato server nella Guida per l'utente di Amazon Simple Storage Service.

I log delle transazioni per ciascun database vengono caricati in un bucket S3 denominato do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier. La directory RDSCustomForSQLServer/Instances/DB_instance_resource_ID nel bucket S3 contiene due sottodirectory:

  • TransactionLogs – Contiene i log delle transazioni per ciascun database e i rispettivi metadati.

    Il nome del file di log delle transazioni segue il pattern yyyyMMddHHmm.database_id.timestamp, ad esempio:

    202110202230.11.1634769287

    Lo stesso nome del file con il suffisso _metadata contiene informazioni sul log delle transazioni come numeri di sequenza di log, nome del database e RdsChunkCount. RdsChunkCount determina quanti file fisici rappresentano un singolo file di log delle transazioni. Potresti vedere file con suffissi _0001, _0002 e così via, il che significa i pezzi fisici di un file di log delle transazioni. Se si desidera utilizzare un file di log delle transazioni a blocchi, assicurarsi di unire i blocchi dopo averli scaricati.

    Considera uno scenario in cui hai i seguenti file:

    • 202110202230.11.1634769287

    • 202110202230.11.1634769287_0001

    • 202110202230.11.1634769287_0002

    • 202110202230.11.1634769287_metadata

    Il valore del campo RdsChunkCount è 3. L'ordine di unione dei file è il seguente: 202110202230.11.1634769287, 202110202230.11.1634769287_0001, 202110202230.11.1634769287_0002.

  • TransactionLogMetadata – Contiene informazioni sui metadati su ogni iterazione dell'estrazione del log delle transazioni.

    Il file RI.End contiene informazioni per tutti i database a cui sono stati estratti i log delle transazioni e per tutti i database esistenti ma che non hanno i log delle transazioni estratti. Il nome del file RI.End segue il pattern yyyyMMddHHmm.RI.End.timestamp, ad esempio:

    202110202230.RI.End.1634769281

PITREseguire il ripristino utilizzando il AWS Management Console, il o. AWS CLI RDS API

È possibile ripristinare un'istanza DB RDS Custom for SQL Server in un determinato momento utilizzando il AWS Management Console, il AWS CLI, o il RDSAPI.

Per ripristinare un'istanza DB RDS personalizzata a un'ora specificata
  1. Accedi a AWS Management Console e apri la RDS console Amazon all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel riquadro di navigazione, selezionare Automated backups (Backup automatici).

  3. Scegli l'istanza DB RDS personalizzata che desideri ripristinare.

  4. In Actions (Operazioni), scegli Restore to point in time (Ripristina a un istante temporale).

    Viene visualizzata la finestra Restore to point in time (Ripristina a un istante temporale).

  5. Scegliere Latest restorable time (Ultimo orario di ripristino) per eseguire il ripristino in base al momento più recente oppure scegliere Custom (Personalizzato) per scegliere una data e un'ora.

    Se scegli Personalizzato, specifica la data e l'ora in cui desideri ripristinare l'istanza.

    Gli orari vengono visualizzati nel fuso orario locale, indicato da un offset rispetto al Coordinated Universal Time (UTC). Ad esempio, UTC -5 è l'ora solare orientale/ora legale centrale.

  6. Per l'identificatore dell'istanza DB, inserisci il nome dell'istanza DB RDS personalizzata di destinazione ripristinata. Il nome deve essere univoco.

  7. Scegli altre opzioni in base alle esigenze, ad esempio la classe di istanza database.

  8. Scegli Restore to point in time (Ripristina per punto nel tempo).

È possibile ripristinare un'istanza DB a un'ora specificata utilizzando il point-in-time AWS CLI comando restore-db-instance-to- per creare una nuova istanza DB RDS personalizzata.

Utilizzare una delle opzioni seguenti per specificare il backup da cui effettuare il ripristino:

  • --source-db-instance-identifier mysourcedbinstance

  • --source-dbi-resource-id dbinstanceresourceID

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

L'opzione custom-iam-instance-profile è obbligatoria.

Il seguente esempio ripristina my-custom-db-instance a una nuova istanza database denominata my-restored-custom-db-instance, a partire dal tempo specificato.

In Linux, macOS, oppure 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

In 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