Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Wiederherstellen einer Instance von RDS Custom für SQL Server auf einen bestimmten Zeitpunkt
Sie können eine DB-Instanceeinen DB-Cluster zu einem bestimmten Zeitpunkt wiederherstellen, indem Sie eine neue DB-Instanceeinen neuen DB-Cluster erstellen. Um PITR zu unterstützen, muss für Ihre DB-Instances die Sicherheitsaufbewahrung aktiviert sein.
Die späteste wiederherstellbare Zeit für eine DB-Instance von RDS Custom für SQL Server hängt von mehreren Faktoren ab, liegt jedoch normalerweise innerhalb von 5 Minuten vor dem aktuellen Zeitpunkt. Um die neueste wiederherstellbare Zeit für eine DB-Instance anzuzeigen, verwenden Sie den Befehl AWS CLIdescribe-db-instances und sehen Sie sich den Wert an, der im LatestRestorableTime Feld für die DB-Instance zurückgegeben wird. Um die neueste Wiederherstellungszeit für jede DB-Instance in der Amazon-RDS-Konsole anzuzeigen, wählen Sie Automatische Backups.
Sie können die Backup auf jeden beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums für Backups vornehmen. Um den frühesten wiederherstellbaren Zeitpunkt für jede DB-Instance anzuzeigen, wählen Sie Automatische Backups in der Amazon-RDS-Konsole aus.
Allgemeine Informationen zu PITR finden Sie unter Wiederherstellen einer DB-Instance auf einen bestimmten Zeitpunkt für Amazon RDS.
Themen
Überlegungen zu PITRs für RDS Custom für SQL Server
In RDS Custom für SQL Server unterscheidet sich PITR in folgenden wichtigen Weisen von PITR in Amazon RDS:
-
PITR stellt nur die Datenbanken in der DB-Instance wieder her. Es stellt das Betriebssystem oder die Dateien auf dem Laufwerk C: nicht wieder her.
-
Für eine RDS Custom für SQL Server DB-Instance wird eine Datenbank automatisch gesichert und ist nur unter den folgenden Bedingungen für PITR berechtigt:
-
Die Datenbank ist online.
-
Sein Wiederherstellungsmodell ist auf
FULLgesetzt. -
Es ist beschreibbar.
-
Es hat seine physischen Dateien auf dem Laufwerk D:.
-
Sie ist nicht in der
rds_pitr_blocked_databases-Tabelle aufgeführt. Weitere Informationen finden Sie unter Datenbanken für PITR nicht berechtigt machen.
-
-
Die Datenbanken, die für PITR in Frage kommen, werden durch die Reihenfolge ihrer Datenbank-ID bestimmt. RDS Custom für SQL Server erlaubt bis zu 5 000 Datenbanken pro DB-Instance. Die maximale Anzahl von Datenbanken, die durch einen PITR-Vorgang für eine RDS-Custom-for-SQL-Server-DB-Instance wiederhergestellt werden, hängt vom Instance-Klassentyp ab. Weitere Informationen finden Sie unter Anzahl der Datenbanken, die für PITR in Frage kommen, pro Instance-Klassentyp.
Andere Datenbanken, die nicht Teil von PITR sind, können aus DB-Snapshots wiederhergestellt werden, einschließlich der automatisierten Snapshot-Backups, die für PITR verwendet werden.
-
Das Hinzufügen einer neuen Datenbank, das Umbenennen einer Datenbank oder das Wiederherstellen einer Datenbank, die für PITR berechtigt ist, initiiert einen Snapshot der DB-Instance.
-
Die maximale Anzahl von Datenbanken, die für PITR in Frage kommen, ändert sich je nach Klassentyp der Ziel-Instance, wenn die Datenbank-Instance einen Skalierungsberechnungsvorgang durchläuft. Wenn die Instance hochskaliert wird, sodass mehr Datenbanken auf der Instance für PITR in Frage kommen, wird ein neuer Snapshot erstellt.
-
Wiederhergestellte Datenbanken haben denselben Namen wie in der Quell-DB-Instance. Wenn Sie möchten, können Sie einen anderen Namen eingeben.
-
AWSRDSCustomSQLServerIamRolePolicyerfordert Zugriff auf andere AWS-Dienste. Weitere Informationen finden Sie unter Fügen Sie eine Zugriffsrichtlinie hinzu zu AWSRDSCustom SQLServer InstanceRole. -
Zeitzonenänderungen werden für RDS Custom für SQL Server nicht unterstützt. Wenn Sie die Zeitzone des Betriebssystems oder der DB-Instance ändern, funktioniert PITR (und andere Automatisierung) nicht.
Anzahl der Datenbanken, die für PITR in Frage kommen, pro Instance-Klassentyp
Die folgende Tabelle zeigt die maximale Anzahl von Datenbanken, die für PITR-Anwendungen in Frage kommen, basierend auf dem Instance-Klassentyp.
| Typ der Instance-Klasse | Maximale Anzahl der Datenbanken, die für PITR in Frage kommen |
|---|---|
| db.*.large | 100 |
| db.*.xlarge to db.*.2xlarge | 150 |
| db.*.4xlarge zu db.*.8xlarge | 300 |
| db.*.12xlarge zu db.*.16xlarge | 600 |
| db.*.24xlarge, db.*32xlarge | 1000 |
* stellt die unterschiedlichen Typen von Instance-Klassen dar.
Die maximale Anzahl von Datenbanken, die für PITR in einer DB-Instance in Frage kommen, hängt vom Instance-Klassentyp ab. Die Anzahl reicht von 100 bei den kleinsten Instance-Klassentypen bis zu 1000 bei den größten Instance-Klassentypen, die von RDS Custom für SQL Server unterstützt werden. SQL-Server-Systemdatenbanken (master, model, msdb, tempdb) unterliegen nicht dieser Beschränkung. Wenn eine DB-Instance je nach Typ der Ziel-Instance-Klasse hoch- oder herunterskaliert wird, aktualisiert RDS Custom automatisch die Anzahl der Datenbanken, die für PITR in Frage kommen. RDS Custom für SQL Server will send RDS-EVENT-0352, wenn sich die maximale Anzahl von Datenbanken, die für PITR-Anwendungen in Frage kommen, auf einer -DB-Instance ändert. Weitere Informationen finden Sie unter Benutzerdefinierte Engine-Versionsereignisse.
Anmerkung
Die PITR-Unterstützung für mehr als 100 Datenbanken ist nur für DB-Instances verfügbar, die nach dem 26. August 2023 erstellt wurden. Für Instances, die vor dem 26. August 2023 erstellt wurden, beträgt die maximale Anzahl von Datenbanken, die für PITR in Frage kommen, 100, unabhängig von der Instance-Klasse. Um die PITR-Unterstützung für mehr als 100 Datenbanken auf DB-Instances zu aktivieren, die vor dem 26. August 2023 erstellt wurden, können Sie die folgende Aktion ausführen:
Aktualisieren Sie die DB-Engine-Version auf 15.00.4322.2.v1 oder höher
Während eines PITR-Vorgangs stellt RDS Custom alle Datenbanken wieder her, die zum Zeitpunkt der Wiederherstellung Teil von PITR auf der Quell-DB-Instance waren. Sobald die Ziel-DB-Instance die Wiederherstellungsvorgänge abgeschlossen hat und die Sicherung aktiviert ist, beginnt die DB-Instance mit der Sicherung auf der Grundlage der maximalen Anzahl von Datenbanken, die für PITR auf der Ziel-DB-Instance in Frage kommen.
Wenn Ihre DB-Instance beispielsweise auf einer db.*.xlarge mit 200 Datenbanken läuft:
RDS Custom für SQL Server wählt die ersten 150 Datenbanken, sortiert nach ihrer Datenbank-ID, für die PITR-Sicherung aus.
Sie ändern die Instance so, dass sie auf db.*.4xlarge skaliert wird.
Sobald der Skalierungsrechenvorgang abgeschlossen ist, wählt RDS Custom für SQL Server die ersten 300 Datenbanken, sortiert nach ihrer Datenbank-ID, für die PITR-Sicherung aus. Jede der 200 Datenbanken, die die PITR-Anforderungen erfüllen, kommt nun für PITR in Frage.
Sie ändern jetzt die Instance, sodass sie wieder auf db.*.xlarge herunterskaliert wird.
Sobald der Skalierungsrechenvorgang abgeschlossen ist, wählt RDS Custom für SQL Server erneut die ersten 150 Datenbanken, sortiert nach ihrer Datenbank-ID, für die PITR-Backup aus.
Datenbanken für PITR nicht berechtigt machen
Sie können wählen, ob einzelne Datenbanken von PITR ausgeschlossen werden sollen. Um dies zu tun, legen Sie ihre database_id-Werte in eine rds_pitr_blocked_databases-Tabelle. Verwenden Sie den folgenden -Befehl, um die Tabelle zu erstellen.
So erstellen Sie die Tabelle „rds_pitr_blocked_databases“
-
Führen Sie das folgende Skript aus.
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) );
Eine Liste der berechtigten und nicht berechtigten Datenbanken finden Sie in der RI.End-Datei im RDSCustomForSQLServer/Instances/-Verzeichnis im Amazon S3-Bucket DB_instance_resource_ID/TransactionLogMetadatado-not-delete-rds-custom-. Weitere Informationen zur Datei $ACCOUNT_ID-$REGION-unique_identifierRI.End finden Sie unter Transaktionsprotokolle in Amazon S3.
Sie können die Liste der Datenbanken, die für PITR in Frage kommen, auch mithilfe des folgenden SQL-Skripts ermitteln. Setzen Sie die @limit-Variable auf die maximale Anzahl von Datenbanken, die für PITR in der Instance-Klasse in Frage kommen. Weitere Informationen finden Sie unter Anzahl der Datenbanken, die für PITR in Frage kommen, pro Instance-Klassentyp.
So ermitteln Sie die Liste der für PITR in Frage kommenden Datenbanken in einer DB-Instance-Klasse
-
Führen Sie das folgende Skript aus.
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
Anmerkung
Die Datenbanken, bei denen es sich nur um symbolische Links handelt, sind ebenfalls von Datenbanken ausgeschlossen, die für PITR-Operationen in Frage kommen. Die obige Abfrage filtert nicht nach diesen Kriterien.
Transaktionsprotokolle in Amazon S3
Der Aufbewahrungszeitraum für Backups bestimmt, ob Transaktionsprotokolle für RDS Custom für SQL Server DB-Instances automatisch extrahiert und auf Amazon S3 hochgeladen werden. Ein Wert ungleich Null bedeutet, dass automatische Backups erstellt werden und der RDS Custom Agent die Transaktionsprotokolle alle 5 Minuten auf S3 hochlädt.
Transaktionsprotokolldateien auf S3 werden im Ruhezustand mit dem AWS KMS key die Sie angegeben haben, als Sie Ihre DB-Instance erstellt haben. Weitere Informationen finden Sie unter Schutz von Daten durch serverseitige Verschlüsselung im Amazon Simple Storage Service User Guide.
Die Transaktionsprotokolle für jede Datenbank werden in einen S3-Bucket namens do-not-delete-rds-custom- hochgeladen. Das $ACCOUNT_ID-$REGION-unique_identifierRDSCustomForSQLServer/Instances/-Verzeichnis im S3-Bucket enthält zwei Unterverzeichnisse:DB_instance_resource_ID
-
TransactionLogs— Enthält die Transaktionsprotokolle für jede Datenbank und ihre jeweiligen Metadaten.Der Name der Transaktionslog-Datei folgt dem Muster
, Beispiel:yyyyMMddHHmm.database_id.timestamp202110202230.11.1634769287Derselbe Dateiname mit dem Suffix
_metadataenthält Informationen über das Transaktionslog wie Log-Sequenznummern, Datenbankname undRdsChunkCount.RdsChunkCountbestimmt, wie viele physische Dateien eine einzelne Transaktionslogdatei darstellen. Möglicherweise sehen Sie Dateien mit Suffixen_0001,_0002und so weiter, was die physischen Teile einer Transaktionslogdatei bedeutet. Wenn Sie eine Chunked Transaktionslogdatei verwenden möchten, müssen Sie die Chunks nach dem Herunterladen zusammenführen.Betrachten Sie ein Szenario, in dem Sie folgende Dateien haben:
-
202110202230.11.1634769287 -
202110202230.11.1634769287_0001 -
202110202230.11.1634769287_0002 -
202110202230.11.1634769287_metadata
Das
RdsChunkCountist3. Die Reihenfolge zum Zusammenführen der Dateien ist die folgende:202110202230.11.1634769287,202110202230.11.1634769287_0001,202110202230.11.1634769287_0002. -
-
TransactionLogMetadata— Enthält Metadateninformationen über jede Iteration der Transaktionslog-Extraktion.Die
RI.Endenthält Informationen für alle Datenbanken, deren Transaktionsprotokolle extrahiert wurden, und für alle Datenbanken, die vorhanden sind, aber ihre Transaktionsprotokolle nicht extrahiert wurden. DerRI.End-Dateiname folgt dem Muster, Beispiel:yyyyMMddHHmm.RI.End.timestamp202110202230.RI.End.1634769281
PITR Restore mithilfe der AWS-Managementkonsole, AWS CLI oder RDS-API.
Sie können eine DB-Instance von RDS Custom für SQL Server mit der AWS-Managementkonsole, der AWS CLI oder der RDS-API auf einen bestimmten Zeitpunkt wiederherstellen.
Wiederherstellen einer DB-Instance eines RDS Custom zu einer bestimmten Zeit
Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter https://console.aws.amazon.com/rds/
. -
Wählen Sie im Navigationsbereich Automated backups (Automatisierte Backups) aus.
-
Wählen Sie die RDS Custom DB-Instance aus, die Sie wiederherstellen möchten.
-
Wählen Sie unter Aktionen die Option Restore to point in time (Zu einem bestimmten Zeitpunkt wiederherstellen) aus.
Anschließend wird das Fenster Restore to point in time (Zu einem bestimmten Zeitpunkt wiederherstellen) angezeigt.
-
Wählen Sie Späteste Wiederherstellungszeit, um auf den spätesten möglichen Zeitpunkt wiederherzustellen oder wählen Sie Benutzerdefiniert, um eine Zeit auszuwählen.
Geben Sie bei der Auswahl von Custom das Datum und die Uhrzeit ein, zu der Sie den Instance-Cluster wiederherstellen möchten.
Zeiten werden in Ihrer lokalen Zeitzone angezeigt, die durch einen Offset von Coordinated Universal Time (UTC) angezeigt wird. Beispiel: UTC-5 ist Ost Standardzeit/Zentral Sommerzeit.
-
Geben Sie für DB-Instance-Kennung den Namen der wiederhergestellten RDS Custom DB-Ziel-Instance ein. Der Name muss eindeutig sein.
-
Wählen Sie bei Bedarf andere Optionen aus, z. B. DB-Instance-Class.
-
Wählen Sie Restore to point in time (Zu einem bestimmten Zeitpunkt wiederherstellen) aus.
Sie stellen eine DB-Instance zu einem angegebenen Zeitpunkt wieder her, indem Sie den Befehl restore-db-instance-to-point-in-time AWS CLI verwenden, um eine neue benutzerdefinierte RDS-DB-Instance zu erstellen.
Verwenden Sie eine der folgenden Optionen, um die Sicherung anzugeben, von der wiederhergestellt werden soll:
-
--source-db-instance-identifiermysourcedbinstance -
--source-dbi-resource-iddbinstanceresourceID -
--source-db-instance-automated-backups-arnbackupARN
Die Option custom-iam-instance-profile ist erforderlich.
Der folgende Befehl stellt my-custom-db-instance auf eine neue DB-Instance namens my-restored-custom-db-instance wieder her, und zwar zum angegebenen Zeitpunkt.
Für Linux, macOS oder Unix:
aws rds restore-db-instance-to-point-in-time \ --source-db-instance-identifiermy-custom-db-instance\ --target-db-instance-identifiermy-restored-custom-db-instance\ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance\ --restore-time2022-10-14T23:45:00.000Z
Für Windows:
aws rds restore-db-instance-to-point-in-time ^ --source-db-instance-identifiermy-custom-db-instance^ --target-db-instance-identifiermy-restored-custom-db-instance^ --custom-iam-instance-profileAWSRDSCustomInstanceProfileForRdsCustomInstance^ --restore-time2022-10-14T23:45:00.000Z