Multi-AZ-Bereitstellungen für Microsoft SQL Server - Amazon Relational Database Service

Multi-AZ-Bereitstellungen für Microsoft SQL Server

Multi-AZ-Bereitstellungen bieten eine erhöhte Verfügbarkeit, eine längere Lebensdauer von Daten sowie eine höhere Fehlertoleranz für DB-Instances. Bei einer geplanten Datenbankwartung oder einer ungeplanten Serviceunterbrechung führt Amazon RDS automatisch einen Failover zur aktuellen sekundären DB-Instance durch. Mit dieser Funktion können Datenbankoperationen schnell ohne manuellen Eingriff fortgesetzt werden. Die Primär- und Standby-Instances verwenden denselben Endpunkt, dessen physische Netzwerkadresse als Teil des Failoverprozesses am sekundären Replica gespiegelt wird. Sie müssen Ihre Anwendung nicht neu konfigurieren, wenn ein Failover auftritt.

Amazon RDS unterstützt Multi-AZ-Bereitstellungen für Microsoft SQL Server mithilfe der SQL Server-Datenbankspiegelung oder -AlwaysOn-Verfügbarkeitsgruppen. Amazon RDS überwacht und verwaltet den Zustand Ihrer Multi-AZ-Bereitstellung. Bei Problemen repariert RDS fehlerhafte DB-Instances automatisch, stellt die Synchronisierung neu her und initiiert Failover. Failover treten nur auf, wenn Standby- und Primär-Instance vollständig synchron sind. Sie müssen nichts verwalten.

Wenn Sie SQL Server-Multi-AZ einrichten, konfiguriert RDS automatisch alle Datenbanken auf der Instance so, dass sie die Datenbankspiegelung oder Verfügbarkeitsgruppen verwenden. Amazon RDS verarbeitet die primäre, die Zeugen- und die sekundäre DB-Instance für Sie. Da die Konfiguration automatisch ist, wählt RDS DBM oder AlwaysOn-Verfügbarkeitsgruppen basierend auf der Version von SQL Server aus, die Sie bereitstellen.

Amazon RDS unterstützt Multi-AZ mit AlwaysOn-Verfügbarkeitsgruppen für die folgenden SQL Server-Versionen und -Editionen:

  • SQL Server 2019: Enterprise Edition 15.00.4043.16 oder höher

  • SQL Server 2017: Enterprise Edition 14.00.3049.1 oder höher

  • SQL Server 2016: Enterprise Edition 13.00.5216.0 oder höher

Amazon RDS unterstützt Multi-AZ mit DBM für die folgenden SQL Server-Versionen und -Editionen mit Ausnahme der zuvor erwähnten Versionen der Enterprise Edition:

  • SQL Server 2017: Standard und Enterprise Editions

  • SQL Server 2016: Standard und Enterprise Editions

  • SQL Server 2014: Standard und Enterprise Editions

  • SQL Server 2012: Standard und Enterprise Editions

Amazon RDS unterstützt Multi-AZ für SQL Server in allen AWS-Regionen mit folgenden Ausnahmen:

  • Asien-Pazifik (Osaka-Lokal): Weder DBM noch Always On AGs werden hier unterstützt.

  • Asien-Pazifik (Sydney): Unterstützt für DB-Instances in VPCs

  • Asien-Pazifik (Tokio): Unterstützt für DB-Instances in VPCs

  • Südamerika (São Paulo): Unterstützt in allen DB-Instand-Klassen außer m1 und m2

Hinzufügen von Multi-AZ zu einer Microsoft SQL Server-DB-Instance

Beim Erstellen einer neuen SQL Server-DB-Instance mit der AWS Management Console können Sie Multi-AZ mit Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen hinzufügen. Dazu wählen Sie Yes (Mirroring / Always On) (Ja (Spiegelung/Always On)) unter Multi-AZ deployment (Multi-AZ-Bereitstellung) aus. Weitere Informationen finden Sie unter Erstellen einer Amazon RDS-DB-Instance.

Beim Bearbeiten einer vorhandenen SQL Server-DB-Instance mithilfe der AWS Management Console können Sie Multi-AZ mit Datenbankspiegelung oder Verfügbarkeitsgruppen hinzufügen, indem Sie Yes (Mirroring / Always On) (Ja (Spiegelung/Always On)) aus der Liste Multi-AZ-Bereitstellung auf der Seite Modify DB Instance (DB-Instance ändern) auswählen. Weitere Informationen finden Sie unter Ändern einer Amazon RDS-DB-Instance.

Anmerkung

Wenn Ihre DB-Instance eine Datenbankspiegelung – keine Always On-Verfügbarkeitsgruppen – ausführt, müssen Sie möglicherweise die In-Memory-Optimierung deaktivieren, bevor Sie Multi-AZ hinzufügen. Deaktivieren Sie die In-Memory-Optimierung mit DBM, bevor Sie Multi-AZ hinzufügen, wenn Ihre DB-Instance SQL Server 2014, 2016 oder 2017 Enterprise Edition ausführt und die In-Memory-Optimierung aktiviert ist.

Wenn Ihre DB-Instance Verfügbarkeitsgruppen ausführt, ist dieser Schritt nicht erforderlich.

Hinweise und Empfehlungen zur Microsoft SQL Server-Multi-AZ-Bereitstellung

Einschränkungen bei der Arbeit mit Multi-AZ-Bereitstellungen für Microsoft SQL Server-DB-Instances:

  • Regionsübergreifende Multi-AZ wird nicht unterstützt.

  • Sie können die sekundäre DB-Instance nicht so konfigurieren, dass sie die Datenbankleseaktivität akzeptiert.

  • Multi-AZ mit AlwaysOn-Verfügbarkeitsgruppen unterstützt die In-Memory-Optimierung.

  • Multi-AZ mit Always On-Verfügbarkeitsgruppen unterstützt keine Kerberos-Authentifizierung für den Verfügbarkeitsgruppen-Listener. Dies liegt daran, dass der Listener keinen Dienstprinzipalnamen (SPN, Service Principal Name) hat.

  • Sie können eine Datenbank in einer SQL Server-DB-Instance nicht umbenennen, die sich in einer SQL Server-Multi-AZ-Bereitstellung befindet. Falls Sie eine Datenbank in einer derartigen Instance umbenennen müssen, deaktivieren Sie erst Multi-AZ für die DB-Instance und benennen dann die Datenbank um. Aktivieren Sie letztendlich Multi-AZ wieder für die DB-Instance.

  • Sie können nur Multi-AZ-DB-Instances wiederherstellen, die mithilfe des vollständigen Wiederherstellungsmodells gesichert wurden.

Hinweise zur Arbeit mit Multi-AZ-Bereitstellungen für Microsoft SQL Server-DB-Instances:

  • Amazon RDS stellt den Verfügbarkeitsgruppen-Listener-Endpunkt für Always On-Verfügbarkeitsgruppen bereit. Der Endpunkt ist in der Konsole sichtbar und wird von der DescribeDBInstances-API als Eintrag im Feld mit den Endpunkten zurückgegeben.

  • Amazon RDS unterstützt Failover bei mehreren Subnetzen in Verfügbarkeitsgruppen.

  • Zur Verwendung von SQL Server-Multi-AZ mit einer SQL Server-DB-Instance in einer VPC erstellen Sie zuerst eine DB-Subnetzgruppe, die Subnetze in mindestens zwei verschiedenen Availability Zones aufweist. Sie weisen anschließend die DB-Subnetzgruppe dem primären Replica der SQL Server-DB-Instance zu.

  • Wenn eine DB-Instanz in eine Multi-AZ-Bereitstellung geändert wird, hat sie während der Änderung den Status Modifying (Wird geändert …). Amazon RDS erstellt die Standby-Spiegelung sowie eine Sicherung der primären DB-Instance. Wenn der Prozess abgeschlossen ist, ändert sich der Status der primären DB-Instance zu Available (Verfügbar).

  • Multi-AZ-Bereitstellungen verwalten alle Datenbanken auf demselben Knoten. Bei einem Failover einer Datenbank auf dem primären Host erfolgt ein Failover für alle Ihre SQL Server-Datenbanken als Einheit auf Ihren Standby-Host. Amazon RDS stellt einen fehlerfreien Host bereit und ersetzt den nicht fehlerfreien Host.

  • Multi-AZ mit Datenbankspiegelung oder Verfügbarkeitsgruppen unterstützt ein einzelnes Standby-Replikat.

  • Benutzer, Logins und Berechtigungen werden auf der sekundären Instance automatisch für Sie repliziert. Sie müssen sie nicht erneut erstellen. Benutzerdefinierte Serverrollen (eine SQL Server 2012-Funktion) werden in Multi-AZ-Instances nur für Verfügbarkeitsgruppen-Instances repliziert.

  • Falls Sie SQL Server Agent-Aufträge besitzen, erstellen Sie sie auf der sekundären Instance neu. Dies ist erforderlich, da diese Aufträge in der msdb-Datenbank gespeichert sind, und Sie diese Datenbank nicht mit der Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen replizieren können. Erstellen Sie die Aufträge zuerst in der ursprünglichen primären Instance, führen Sie ein Failover durch und erstellen Sie dann dieselben Aufträge in der neuen primären Instance.

  • Aufgrund der synchronen Datenreplikation kann es zu erhöhten Latenzen im Vergleich zur standardmäßigen Bereitstellung einer DB-Instance in einer einzigen Availability Zone kommen.

  • Die Failover-Zeiten sind von der Zeit abhängig, die für den Wiederherstellungsprozess benötigt wird. Große Transaktionen erhöhen die Failover-Zeit.

Empfehlungen für die Arbeit mit Multi-AZ-Bereitstellungen für Microsoft SQL Server-DB-Instances:

  • Für Datenbanken, die in der Produktion oder Vorproduktion verwendet werden, empfehlen wir die folgenden Optionen:

    • Multi-AZ-Bereitstellungen für Hochverfügbarkeit

    • Provisioned IOPS für schnelle, konsistente Leistung

    • „Speicheroptimiert“ statt „Universell“

  • Sie können die Availability Zone (AZ) für die sekundäre Instance nicht auswählen. Berücksichtigen Sie dies daher bei der Bereitstellung von Anwendungshosts. Für Ihre Datenbank konnte kein Failover auf eine andere AZ durchgeführt werden, und die Anwendungshosts befinden sich möglicherweise nicht in derselben AZ wie die Datenbank. Daher empfiehlt es sich, Ihre Anwendungshosts gleichmäßig über alle AZs in der angegebenen AWS-Region zu verteilen.

  • Aktivieren Sie während eines umfangreichen Datenladevorgangs keine Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen, um eine optimale Leistung zu ermöglichen. Falls der Datenladevorgang so schnell wie möglich ablaufen soll, schließen Sie den Datenladevorgang ab, bevor Sie Ihre DB-Instance in eine Multi-AZ-Bereitstellung konvertieren.

  • Anwendungen, die SQL Server-Datenbanken aufrufen, sollten über eine Ausnahmebehandlung verfügen, die Verbindungsfehler erfasst. Das folgende Codebeispiel zeigt einen try/catch-Block, der einen Kommunikationsfehler erfasst.

    for (int iRetryCount = 0; (iRetryCount < RetryMaxAttempts && keepInserting); iRetryCount++) { using (SqlConnection connection = new SqlConnection(DatabaseConnString)) { using (SqlCommand command = connection.CreateCommand()) { command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');"; try { connection.Open(); while (keepInserting) { command.ExecuteNonQuery(); intervalCount++; } connection.Close(); } catch (Exception ex) { Logger(ex.Message); } } } if (iRetryCount < RetryMaxAttempts && keepInserting) { Thread.Sleep(RetryIntervalPeriodInSeconds * 1000); } }
  • Verwenden Sie den Set Partner Off-Befehl nicht, wenn Sie mit Multi-AZ-Instances arbeiten. Unterlassen Sie beispielsweise Folgendes:

    --Don't do this ALTER DATABASE db1 SET PARTNER off
  • Setzen Sie den Wiederherstellungsmodus nicht auf simple. Unterlassen Sie beispielsweise Folgendes:

    --Don't do this ALTER DATABASE db1 SET RECOVERY simple
  • Verwenden Sie den DEFAULT_DATABASE-Parameter nicht, wenn Sie neue Logins für Multi-AZ-DB-Instances erstellen, da diese Einstellungen nicht in die Standby-Spiegelung übernommen werden können. Unterlassen Sie beispielsweise Folgendes:

    --Don't do this CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]

    Unterlassen Sie zudem Folgendes:

    --Don't do this ALTER LOGIN [test_dba] SET DEFAULT_DATABASE=[db3]

Festlegen des Standorts der sekundären Instance

Sie können den Standort des sekundären Replica mithilfe der AWS Management Console festlegen. Sie müssen den Standort der sekundären Instance kennen, wenn Sie Ihre primäre DB-Instance in einer VPC einrichten.


				Sekundäre AZ

Außerdem zeigen Sie mit dem AWS CLI-Befehl describe-db-instances oder der RDS-API-Operation DescribeDBInstances die Availability Zone der sekundären Instance an. Die Ausgabe zeigt die sekundäre AZ-Instance, in der sich der Standby-Spiegel befindet.

Migrieren von der Datenbankspiegelung zu AlwaysOn-Verfügbarkeitsgruppen

In Version 14.00.3049.1 der Microsoft SQL Server Enterprise Edition sind AlwaysOn-Verfügbarkeitsgruppen standardmäßig aktiviert.

Prüfen Sie erst Ihre Version, ehe Sie von der Datenbankspiegelung zu Verfügbarkeitsgruppen migrieren. Wenn Sie eine DB-Instance mit einer Version vor Enterprise Edition 13.00.5216.0 verwenden, patchen Sie die Instance zu Version 13.00.5216.0 oder höher. Wenn Sie eine DB-Instance mit einer Version vor Enterprise Edition 14.00.3049.1 verwenden, patchen Sie die Instance zu Version 14.00.3049.1 oder höher.

Wenn Sie ein Upgrade für eine gespiegelte DB-Instance vornehmen möchten, damit diese Verfügbarkeitsgruppen verwendet, führen Sie zunächst das Upgrade aus, ändern Sie dann die Instance, sodass Multi-AZ entfernt wird und ändern Sie sie dann erneut, um Multi-AZ hinzuzufügen. Dadurch wird Ihre Instance umgewandelt und verwendet AlwaysOn-Verfügbarkeitsgruppen.