Arbeiten mit Read Replicas für Microsoft SQL Server in Amazon RDS

Sie verwenden Lesereplikate üblicherweise, um die Replikation zwischen Amazon RDS-DB-Instances zu konfigurieren. Allgemeine Informationen zu Lesereplikaten finden Sie unter Arbeiten mit DB-Instance-Lesereplikaten.

In diesem Abschnitt finden Sie spezifische Informationen zum Arbeiten mit Lesereplikaten unter Amazon RDS for SQL Server.

Konfigurieren von Read Replicas für SQL Server

Bevor eine DB-Instance als Quell-Instance für die Replikation eingesetzt werden kann, müssen Sie automatische Sicherungen auf der Quell-DB-Instance aktivieren. Hierzu legen Sie für den Aufbewahrungszeitraum für Sicherungen einen anderen Wert als 0 fest. Die Quell-DB-Instance muss eine Multi-AZ-Bereitstellung mit Always On-Verfügbarkeitsgruppen sein. Durch das Festlegen dieses Bereitstellungstyps wird außerdem erzwungen, dass automatische Sicherungen aktiviert sind.

Das Erstellen eines SQL Server-Lesereplikats erfordert keinen Wartungsausfall für die primäre DB-Instance. Amazon RDS legt die erforderlichen Parameter und Berechtigungen für die Quelldatenbank-Instance und das Lesereplikat ohne Serviceunterbrechung fest. Ein Snapshot von der Quell-DB-Instance wird gemacht und dieser Snapshot wird zum Lesereplikat. Es findet kein Nutzungsausfall statt, wenn Sie ein Lesereplikat löschen.

Sie können bis zu 15 Lesereplikate aus einer Quell-DB-Instance erstellen. Damit die Replikation effektiv durchgeführt werden kann, empfehlen wir Ihnen, jedes Lesereplikat mit derselben Menge an Rechen- und Speicherressourcen wie die Quell-DB-Instance zu konfigurieren. Wenn Sie die Quell-DB-Instance skalieren, skalieren Sie auch die Lesereplikate.

Die SQL-Server-DB-Engine-Version der Quell-DB-Instance und alle Lese-Replikate müssen identisch sein. Amazon RDS aktualisiert die primäre Instance unmittelbar nach dem Upgrade der Lesereplikate, unabhängig vom Wartungsfenster. Weitere Informationen zum Aktualisieren der DB-Engine-Version finden Sie unter Upgrades der Microsoft SQL Server-DB-Engine.

Damit ein Lesereplikat Änderungen von der Quelle empfängt und anwendet, sollte es über ausreichende Rechen- und Speicherressourcen verfügen. Wenn ein Lesereplikat die Kapazität von Rechen-, Netzwerk- und Speicherressourcen erreicht hat, stellt das Lesereplikat den Empfang und die Anwendung von Änderungen aus seiner Quelle ein. Sie können die Speicher- und CPU-Ressourcen eines Lesereplikats unabhängig von seiner Quelle und anderen Lesereplikaten ändern.

Read-Replica-Einschränkungen mit SQL Server

Die folgenden Einschränkungen gelten für SQL Server-Lesereplikate in Amazon RDS:

• Lesereplikate sind nur auf der SQL Server Enterprise Edition (EE)-Engine verfügbar.

• Read Replicas sind für die SQL Server-Versionen 2016—2022 verfügbar.

• Die zu replizierende Quell-DB-Instance muss eine Multi-AZ-Bereitstellung mit Always On-Verfügbarkeitsgruppen sein.

• Sie können bis zu 15 Lesereplikate aus einer Quell-DB-Instance erstellen. Die Replikation kann verzögert werden, wenn Ihre Quell-DB-Instance über mehr als 5 Read Replicas verfügt.

• Lesereplikate sind nur für DB-Instances verfügbar, die auf DB-Instance-Klassen mit vier oder mehr vCPUs ausgeführt werden.

• Folgendes wird in Amazon RDS for SQL Server nicht unterstützt:

  • Backup-Aufbewahrung von Lesereplikaten

  • oint-in-time PC-Wiederherstellung von Read Replicas

  • Manuelle Snapshots von Lesereplikaten

  • Multi-AZ-Lesereplikate

  • Erstellen von Lesereplikaten aus Lesereplikaten

  • Synchronisierung von Benutzeranmeldungen bei Lesereplikaten

• Amazon RDS for SQL Server greift nicht ein, um eine hohe Replikationsverzögerung zwischen einer Quell-DB-Instance und ihren Lesereplikaten zu minimieren. Stellen Sie sicher, dass die Quell-DB-Instance und ihre Lesereplikate in Bezug auf Rechen- und Speicherkapazität die für ihre Betriebslast angemessene Größe aufweisen.

Überlegungen zu Optionen für Replikate von RDS für SQL Server

Bevor Sie ein Replikat von RDS für SQL Server erstellen, sollten Sie die folgenden Anforderungen, Einschränkungen und Empfehlungen berücksichtigen:

• Wenn sich Ihr SQL-Server-Replikat in derselben Region befindet wie die Quell-DB-Instance, stellen Sie sicher, dass es zur gleichen Optionsgruppe gehört wie die Quell-DB-Instance. Änderungen an der Quell-Optionsgruppe oder der Quell-Optionsgruppenmitgliedschaft werden von den Replikaten übernommen. Diese Änderungen werden unmittelbar, nachdem sie auf die Quell-DB-Instance angewandt wurden, auf die Replikate angewandt, ungeachtet des Wartungsfensters des Replikats.

  Weitere Informationen über Optionsgruppen finden Sie unter Arbeiten mit Optionsgruppen.

• Wenn Sie ein regionsübergreifendes SQL-Server-Replikat erstellen, erstellt Amazon RDS dafür eine dedizierte Optionsgruppe.

  Ein regionsübergreifendes SQL-Server-Replikat kann nicht aus seiner dedizierten Optionsgruppe entfernt werden. Die dedizierte Optionsgruppe eines regionsübergreifenden SQL-Server-Replikats kann nicht von anderen DB-Instances verwendet werden.

  Bei den folgenden Optionen handelt es sich um replizierte Optionen. Wenn Sie einem regionsübergreifenden SQL-Server-Replikat replizierte Optionen hinzufügen möchten, fügen Sie es der Optionsgruppe der Quell-DB-Instance hinzu. Die Option wird auch auf allen Replikaten der Quell-DB-Instance installiert.

  • TDE

  Bei den folgenden Optionen handelt es sich nicht um replizierte Optionen. Sie können nicht replizierte Optionen einer dedizierten Optionsgruppe hinzufügen oder daraus entfernen.

  • MSDTC

  • SQLSERVER_AUDIT

  • Wenn Sie die SQLSERVER_AUDIT-Option für ein regionsübergreifendes Replikat aktivieren möchten, fügen Sie die SQLSERVER_AUDIT-Option der dedizierten Optionsgruppe für das regionsübergreifende Lesereplikat und die Optionsgruppe der Quell-Instance hinzu. Indem Sie die SQLSERVER_AUDIT-Option für die Quell-Instance des regionsübergreifenden Lesereplikats von SQL Server hinzufügen, können Sie für jedes der regionsübergreifenden Lesereplikate der Quell-Instance ein Prüfobjekt auf Serverebene und Prüfspezifikationen auf Serverebene erstellen. Wenn Sie den regionsübergreifenden Lesereplikaten Zugriffberechtigungen für das Hochladen der abgeschlossenen Prüfprotokolle in einen Amazon-S3-Bucket gewähren möchten, fügen Sie der dedizierten Optionsgruppe die SQLSERVER_AUDIT-Option hinzu und konfigurieren Sie die Optionseinstellungen. Der als Ziel für die Überwachungsdateien verwendete Amazon-S3-Bucket muss sich in derselben Region befinden wie das regionsübergreifende Lesereplikat. Sie können die Optionseinstellung der SQLSERVER_AUDIT-Option für jedes regionsübergreifende Lesereplikat unabhängig ändern, sodass jedes Replikat in seiner jeweiligen Region auf einen Amazon-S3-Bucket zugreifen kann.

  Die folgenden Optionen werden für regionsübergreifende Lesereplikate nicht unterstützt.

  • SSRS

  • SSAS

  • SSIS

  Die folgenden Optionen werden für regionsübergreifende Lesereplikate teilweise unterstützt.

  • SQLSERVER_BACKUP_RESTORE

  • Die Quell-DB-Instance eines regionsübergreifenden SQL-Server-Replikats kann über die SQLSERVER_BACKUP_RESTORE-Option verfügen, Sie können jedoch erst systemeigene Wiederherstellungen für die Quell-DB-Instance durchführen, wenn Sie alle ihre regionsübergreifenden Replikate gelöscht haben. Alle vorhandenen systemeigenen Wiederherstellungsaufgaben werden bei der Erstellung eines regionsübergreifenden Replikats abgebrochen. Sie können die SQLSERVER_BACKUP_RESTORE-Option nicht einer dedizierten Optionsgruppe hinzufügen.

    Weitere Informationen zu systemeigenen Backups und Wiederherstellungen finden Sie unter Importieren und Exportieren von SQL-Server-Datenbanken mithilfe nativer Sicherung und Wiederherstellung.

  Wenn Sie ein regionsübergreifendes SQL-Server-Lesereplikat hochstufen, verhält sich das hochgestufte Lesereplikat genau so wie andere DB-Instances von SQL Server, einschließlich der Verwaltung seiner Optionen. Weitere Informationen über Optionsgruppen finden Sie unter Arbeiten mit Optionsgruppen.

Synchronisieren von Datenbankbenutzern und -objekten mit einem Lesereplikat von SQL Server

Es wird erwartet, dass alle Anmeldungen, benutzerdefinierten Serverrollen, SQL-Agent-Jobs oder andere Objekte auf Serverebene, die zum Zeitpunkt der Erstellung eines Lesereplikats in der primären DB-Instance existieren, im neu erstellten Lesereplikat vorhanden sind. Objekte auf Serverebene, die nach der Erstellung des Lesereplikats in der primären DB-Instance erstellt wurden, werden jedoch nicht automatisch repliziert. Sie müssen sie manuell im Lesereplikat erstellen.

Die Datenbankbenutzer werden automatisch von der primären DB-Instance in das Lesereplikat repliziert. Da sich die Lesereplikat-Datenbank im schreibgeschützten Modus befindet, kann die Sicherheits-ID (SID) des Datenbankbenutzers in der Datenbank nicht aktualisiert werden. Daher muss beim Erstellen von SQL-Anmeldungen im Lesereplikat unbedingt sichergestellt werden, dass die SID dieser Anmeldung mit der SID der entsprechenden SQL-Anmeldung in der primären DB-Instance übereinstimmt. Wenn Sie die SIDs der SQL-Anmeldungen nicht synchronisieren, können diese nicht auf die Datenbank im Lesereplikat zugreifen. Bei authentifizierten Windows Active Directory (AD)-Anmeldungen tritt dieses Problem nicht auf, da der SQL Server die SID von Active Directory bezieht.

So synchronisieren Sie eine SQL-Anmeldung der primären DB-Instance mit dem Lesereplikat

1. Stellen Sie eine Verbindung mit der primären DB-Instance her.

2. Erstellen Sie in der primären DB-Instance eine neue SQL-Anmeldung.

   USE [master]
   GO
   CREATE LOGIN TestLogin1
   WITH PASSWORD = 'REPLACE WITH PASSWORD';
   

   Anmerkung

   Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.

3. Erstellen Sie einen neuen Datenbankbenutzer für die SQL-Anmeldung in der Datenbank.

   USE [REPLACE WITH YOUR DB NAME]
   GO
   CREATE USER TestLogin1 FOR LOGIN TestLogin1;
   GO
   

4. Überprüfen Sie die SID der neu erstellten SQL-Anmeldung in der primären DB-Instance.

   SELECT name, sid FROM sys.server_principals WHERE name =  TestLogin1;
   

5. Stellen Sie eine Verbindung mit dem Lesereplikat her. Erstellen Sie die neue SQL-Anmeldung.

   CREATE LOGIN TestLogin1 WITH PASSWORD = 'REPLACE WITH PASSWORD', SID=[REPLACE WITH sid FROM STEP #4];
   

Wenn Sie Zugriff auf die Lesereplikat-Datenbank haben, können Sie den verwaisten Benutzer alternativ wie folgt korrigieren:

1. Stellen Sie eine Verbindung mit dem Lesereplikat her.

2. Identifizieren Sie die verwaisten Benutzer in der Datenbank.

   USE [REPLACE WITH YOUR DB NAME]
   GO
   EXEC sp_change_users_login 'Report';
   GO
   

3. Erstellen Sie eine neue SQL-Anmeldung für den verwaisten Datenbankbenutzer.

   CREATE LOGIN TestLogin1 WITH PASSWORD = 'REPLACE WITH PASSWORD', SID=[REPLACE WITH sid FROM STEP #2];
   

   Beispiel:

   CREATE LOGIN TestLogin1 WITH PASSWORD = 'TestPa$$word#1', SID=[0x1A2B3C4D5E6F7G8H9I0J1K2L3M4N5O6P];
   

   Anmerkung

   Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.

Fehlerbehebung für ein Problem mit einem SQL Server-Read Replica

Sie können die Replikationsverzögerung in Amazon überwachen, CloudWatch indem Sie sich die Amazon ReplicaLag RDS-Metrik ansehen. Weitere Informationen zur zeitlichen Verzögerung bei der Replikation finden Sie unter Überwachen der Lesereplikation.

Wenn Replikationsverzögerung zu groß ist, können Sie die folgende Abfrage verwenden, um Informationen über die Verzögerung abzurufen.

SELECT AR.replica_server_name
     , DB_NAME (ARS.database_id) 'database_name'
     , AR.availability_mode_desc
     , ARS.synchronization_health_desc
     , ARS.last_hardened_lsn
     , ARS.last_redone_lsn
     , ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;