Multi-AZ-Bereitstellungen für Amazon RDS 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. Im Falle einer geplanten Datenbankwartung oder einer ungeplanten Serviceunterbrechung führt Amazon RDS automatisch einen Failover zur up-to-date 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 mit SQL Server-Datenbankspiegelung oder AlwaysOn-Verfügbarkeitsgruppen ausführen. Amazon RDS überwacht und pflegt die Integrität 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 wickelt die Primär-Instance, den Zeugen und die sekundäre DB-Instance für Sie ab. 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 2022:

  • Standard Edition

  • Enterprise Edition

• SQL Server 2019:

  • Standard Edition 15.00.4073.23 und höher

  • Enterprise Edition

• SQL Server 2017:

  • Standard Edition 14.00.3401.7 und höher

  • Enterprise Edition 14.00.3049.1 und höher

• SQL Server 2016: Enterprise Edition 13.00.5216.0 und 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:

• SQL Server 2019: Standard Edition 15.00.4043.16

• SQL Server 2017: Standard und Enterprise Editions

• SQL Server 2016: Standard und Enterprise Editions

• SQL Server 2014: Standard und Enterprise Editions

Sie können die folgende SQL-Abfrage verwenden, um zu bestimmen, ob Ihre SQL Server-DB-Instance Single-AZ, Multi-AZ mit DBM oder Multi-AZ mit Always On AGs ist.

SELECT CASE WHEN dm.mirroring_state_desc IS NOT NULL THEN 'Multi-AZ (Mirroring)'
    WHEN dhdrs.group_database_id IS NOT NULL THEN 'Multi-AZ (AlwaysOn)'
    ELSE 'Single-AZ'
    END 'high_availability'
FROM sys.databases sd
LEFT JOIN sys.database_mirroring dm ON sd.database_id = dm.database_id
LEFT JOIN sys.dm_hadr_database_replica_states dhdrs ON sd.database_id = dhdrs.database_id AND dhdrs.is_local = 1
WHERE DB_NAME(sd.database_id) = 'rdsadmin';

Die Ausgabe sieht in etwa folgendermaßen aus:

high_availability
Multi-AZ (AlwaysOn)

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

Wenn Sie mit dem eine neue SQL Server-DB-Instance erstellen AWS Management Console, können Sie Multi-AZ with Database Mirroring (DBM) oder Always On AGs 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 Konsole können Sie Multi-AZ mit Datenbankspiegelung oder Verfügbarkeitsgruppen hinzufügen, indem Sie Yes (Mirroring / Always On) (Ja (Spiegelung/Always On)) aus 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.

Entfernen von Multi-AZ aus einer Microsoft SQL Server-DB-Instance

Wenn Sie eine vorhandene SQL Server-DB-Instance mithilfe von ändern AWS Management Console, können Sie Multi-AZ mit DBM oder AGs entfernen. Sie können dies tun, indem Sie Nein (Spiegelung/Always On) von Multi-AZ deployment (Multi-AZ-Bereitstellung) auf der DB-Instance ändern-Seite auswählen. Weitere Informationen finden Sie unter Ändern einer Amazon RDS-DB-Instance.

Einschränkungen, Hinweise und Empfehlungen für Microsoft SQL Server Multi-AZ-Bereitstellung

Im Folgenden sind einige Einschränkungen beim Arbeiten mit Multi-AZ-Bereitstellungen auf RDS für SQL Server-DB-Instances aufgeführt:

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

• Das Beenden einer DB-Instance von RDS für SQL Server in einer Multi-AZ-Bereitstellung 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.

• Multi-AZ-Bereitstellungen haben ein Limit von 10.000 SQL-Server-Agent-Aufträgen.

  Wenn Sie ein höheres Limit benötigen, fordern Sie eine Erhöhung an, indem Sie sich an uns wenden. AWS SupportÖffnen Sie die Seite des AWS Support -Centers, melden Sie sich an und wählen Sie Fall erstellen aus. Wählen Sie Service Limit increase (Erhöhung des Servicelimits). Füllen Sie das Formular aus und senden Sie es ab.

Hinweise zur Arbeit mit Multi-AZ-Bereitstellungen auf RDS für 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 vom DescribeDBInstances-API-Vorgang 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 Virtual Private Cloud (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-Instance in eine Multi-AZ-Bereitstellung geändert wird, hat sie während der Änderung den Status Modifying (Wird geändert …). Amazon RDS erstellt den Standby und erstellt ein Backup 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 neuen fehlerfreien Host bereit und ersetzt den fehlerhaften 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 werden in DB-Instances, die Always-On-Bereitstellungsgruppen verwenden, nur repliziert.

• In Multi-AZ-Bereitstellungen erstellt RDS for SQL Server SQL Server-Logins, um Always-On-AGs oder Datenbankspiegelung zu ermöglichen. RDS erstellt Anmeldungen mit dem folgenden Muster:, und. db_<dbiResourceId>_node1_login db_<dbiResourceId>_node2_login db_<dbiResourceId>_witness_login

• RDS for SQL Server erstellt eine SQL Server-Anmeldung, um den Zugriff auf Read Replicas zu ermöglichen. RDS erstellt eine Anmeldung mit dem folgenden Muster,db_<readreplica_dbiResourceId>_node_login.

• In Multi-AZ-Bereitstellungen werden Aufträge von SQL Server Agent vom primären Host auf den sekundären Host repliziert, wenn die Auftragsreplikationsfunktion aktiviert ist. Weitere Informationen finden Sie unter Aktivieren der Auftragsreplikation von SQL Server Agent.

• 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.

• In SQL Server-Multi-AZ-Bereitstellungen wird bei einem Neustart mit Failover nur die primäre DB-Instance neu gestartet. Nach dem Failover wird die primäre DB-Instance zur neuen sekundären DB-Instance. Die Parameter werden für Multi-AZ-Instances möglicherweise nicht aktualisiert. Für einen Neustart ohne Failover starten sowohl die primäre als auch die sekundäre DB-Instance neu. Die Parameter werden nach dem Neustart aktualisiert. Wenn die DB-Instance nicht reagiert, empfehlen wir einen Neustart ohne Failover.

Empfehlungen für die Arbeit mit Multi-AZ-Bereitstellungen auf RDS 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. Aus diesem Grund empfehlen wir, dass Sie Ihre Anwendungshosts auf alle AZs in der jeweiligen AWS Region 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. In diesem Beispiel beendet die Anweisung break die while-Schleife, wenn die Verbindung erfolgreich ist, versucht es jedoch bis zu zehnmal neu, wenn eine Ausnahme ausgelöst wird.

  int RetryMaxAttempts = 10;
  int RetryIntervalPeriodInSeconds = 1;
  int iRetryCount = 0;
  while (iRetryCount < RetryMaxAttempts)
  {
     using (SqlConnection connection = new SqlConnection(DatabaseConnString))
     {
        using (SqlCommand command = connection.CreateCommand())
        {
           command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');";
           try
           {
              connection.Open();
              command.ExecuteNonQuery();
              break;
           }
           catch (Exception ex) 
           {
              Logger(ex.Message);
              iRetryCount++;
           }
           finally {
              connection.Close();
           }
        }
     }
     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 festlege AWS Management Console. Sie müssen den Standort der sekundären Instance kennen, wenn Sie Ihre primäre DB-Instance in einer VPC einrichten.

Sie können die Availability Zone der Sekundärstation auch mithilfe des AWS CLI Befehls describe-db-instances oder der RDS-API-Operation anzeigenDescribeDBInstances. 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 Always-On-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.