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

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

Das Stoppen einer RDS for SQL Server-DB-Instance 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 Always-On-Verfügbarkeitsgruppen (AGs) unterstützt die speicherinterne Optimierung.

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

Sie können eine Datenbank auf einer SQL Server-DB-Instance, die sich in einer SQL Server-Multi-AZ-Bereitstellung befindet, nicht umbenennen. 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-Jobs.

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.

Sie können keine Offline-Datenbank auf einer SQL Server-DB-Instance einrichten, die sich in einer SQL Server-Multi-AZ-Bereitstellung befindet.

Amazon RDS macht den Listener-Endpunkt der AGs Always-On-Verfügbarkeitsgruppe verfügbar. Der Endpunkt ist in der Konsole sichtbar und wird von der DescribeDBInstances API Operation als Eintrag im Feld Endpoints zurückgegeben.

Amazon RDS unterstützt Failover mit mehreren Subnetzen für Verfügbarkeitsgruppen.

Um SQL Server Multi-AZ mit einer SQL Server-DB-Instance in einer Virtual Private Cloud (VPC) zu verwenden, erstellen Sie zunächst eine DB-Subnetzgruppe mit Subnetzen in mindestens zwei verschiedenen Availability Zones. Weisen Sie dann die DB-Subnetzgruppe dem primären Replikat der Server-DB-Instance zu. SQL

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 die Standby-Instanz und erstellt eine Sicherungskopie 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. Wenn bei einer Datenbank auf dem primären Host ein Failover erfolgt, fallen alle Ihre SQL Serverdatenbanken als eine atomare Einheit auf Ihren Standby-Host aus. Amazon RDS stellt einen neuen fehlerfreien Host bereit und ersetzt den fehlerhaften Host.

Multi-AZ mit DBM oder AGs 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 nur in DB-Instances repliziert, die Always On AGs für Multi-AZ-Bereitstellungen verwenden.

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

RDSfor SQL Server erstellt einen SQL Serveranmeldenamen, um den Zugriff auf Read Replicas zu ermöglichen. RDSerstellt einen Anmeldenamen mit dem folgenden Muster,db_<readreplica_dbiResourceId>_node_login.

In Multi-AZ-Bereitstellungen werden SQL Server-Agent-Jobs vom primären Server auf den sekundären Host repliziert, wenn die Funktion zur Auftragsreplikation aktiviert ist. Weitere Informationen finden Sie unter Die SQL Server-Agent-Auftragsreplikation wird aktiviert.

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.

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

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 Hosts AZs in der jeweiligen AWS Region verteilen.

Um eine optimale Leistung zu erzielen, sollten Sie die Option Datenbankspiegelung oder Always On nicht aktivierenAGs, wenn große Datenmengen geladen werden. 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 auf die SQL Serverdatenbanken zugreifen, sollten über eine Ausnahmebehandlung verfügen, die Verbindungsfehler abfängt. 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]