Limitazioni, note e consigli sulla Multi-AZ distribuzione di Microsoft SQL Server

Cross-Region Multi-AZ non è supportato.

L'arresto di un'istanza database RDS per SQL Server in un'implementazione multi-AZ non è supportato.

Non è possibile configurare l'istanza database secondaria per accettare attività di lettura del database.

Multi-AZ con Always On Availability Groups (AG) supporta l'ottimizzazione in memoria.

Multi-AZ con Always On Availability Groups (AGs) non supporta l'autenticazione Kerberos per il listener del gruppo di disponibilità. Questo perché il listener non dispone di un Service Principal Name (SPN).

Multi-AZ con replica a livello di blocco è attualmente supportata solo per le istanze di SQL Server Web Edition.

Non è possibile rinominare un database su un'istanza DB di SQL Server che si trova in una distribuzione di SQL Server. Multi-AZ Se è necessario rinominare un database su tale istanza, disattivalo prima Multi-AZ per l'istanza DB, quindi rinomina il database. Infine, Multi-AZ riattiva l'istanza DB.

È possibile ripristinare solo le istanze Multi-AZ DB di cui è stato eseguito il backup utilizzando il modello di ripristino completo.

Multi-AZ le distribuzioni hanno un limite di 10.000 lavori di SQL Server Agent.

Se hai bisogno di un limite più alto, richiedi un aumento contattando. Supporto Aprire la pagina del Centro di supporto Supporto AWS effettuando l'accesso se necessario, quindi selezionare Crea caso. Selezionare Service limit increase (Aumento limiti del servizio). Compilare e inviare il modulo.

Non è possibile avere un database offline su un'istanza DB di SQL Server che si trova in una Multi-AZ distribuzione di SQL Server.

Le metriche del volume non sono disponibili per l'host secondario dell'istanza che utilizza la replica a livello di blocco.

Amazon RDS mostra l'endpoint listener del gruppo di disponibilità Always On AGs. L'endpoint è visibile nella console e viene restituito dall'operazione API DescribeDBInstances come una voce nel campo endpoint.

Amazon RDS supporta i failover di sottoreti multiple del gruppo di disponibilità.

Per utilizzare SQL Server Multi-AZ con un'istanza DB di SQL Server in un cloud privato virtuale (VPC), crea innanzitutto un gruppo di sottoreti DB con sottoreti in almeno due zone di disponibilità distinte. Quindi assegnare il gruppo di sottoreti DB alla replica primaria dell'istanza database di SQL Server.

Quando un'istanza DB viene modificata per essere una Multi-AZ distribuzione, durante la modifica ha lo stato di modifica. Amazon RDS crea l’istanza standby ed esegue un backup dell'istanza database principale. Dopo aver completato il processo, lo stato dell'istanza database primaria diventa available (disponibile).

Multi-AZ le distribuzioni mantengono tutti i database sullo stesso nodo. Se un database nell'host primario esegue il failover, tutti i database di SQL Server eseguono il failover come un'unica unità atomica nell'host di standby. Amazon RDS effettua il provisioning di un nuovo host integro e sostituisce l'host non integro.

Multi-AZ con DBM, AGs o la replica a livello di blocco supporta una singola replica in standby.

Nelle Multi-AZ distribuzioni, RDS per SQL Server crea accessi a SQL Server per consentire Always On AGs o Database Mirroring. RDS crea gli accessi con lo schema seguente, db_<dbiResourceId>_node1_login, db_<dbiResourceId>_node2_login e db_<dbiResourceId>_witness_login.

RDS per SQL Server crea un accesso SQL Server per consentire l’accesso alle repliche di lettura. RDS crea un accesso con lo schema seguente, db_<readreplica_dbiResourceId>_node_login.

In un'implementazione standard dell'istanza database in una zona di disponibilità singola, è possibile osservare un aumento della latenza a causa dalle replica sincrona dei dati.

I tempi di failover sono influenzati dal tempo necessario per completare il processo di recupero. Le transazioni di grandi dimensioni aumentano il tempo di failover.

Nelle Multi-AZ distribuzioni di SQL Server, il riavvio con failover riavvia solo l'istanza database principale. Dopo aver eseguito il failover, l'istanza database primaria diventa la nuova istanza database secondaria. I parametri potrebbero non essere aggiornati per le istanze. Multi-AZ Per il riavvio senza failover, le istanze database primarie e secondarie vengono riavviate e i parametri vengono aggiornati dopo il riavvio. Se l'istanza database non risponde, si consiglia di riavviare senza failover.

Per database utilizzati in produzione o in preproduzione, raccomandiamo quanto segue:

Non è possibile selezionare la zona di disponibilità per l'istanza secondaria, quindi tieni questo a mente quando distribuisci gli host delle applicazioni. Il tuo database potrebbe non riuscire su un'altra zona di disponibilità e gli host delle applicazioni potrebbero non essere nella stessa zona di disponibilità del database. Per questo motivo, consigliamo di bilanciare gli host delle applicazioni tra tutte le AZ di una determinata regione. AWS

Per prestazioni ottimali, non abilitate il mirroring del database, l'Always On AG o la replica a livello di blocco durante un'operazione di caricamento di dati di grandi dimensioni. Se desideri che il caricamento dei dati sia il più veloce possibile, completa il caricamento dei dati prima di convertire l'istanza DB in una distribuzione. Multi-AZ

Le applicazioni che accedono ai database SQL Server devono avere una gestione delle eccezioni che rileva gli errori di connessione. Il seguente esempio di codice mostra un try/catch blocco che rileva un errore di comunicazione. In questo esempio, l'istruzione break esce dal ciclo while se la connessione ha esito positivo, ma ritenta fino a 10 volte se viene generata un'eccezione.

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);
}

Non utilizzate il Set Partner Off comando quando lavorate con Multi-AZ istanze che utilizzano DBM o AG. Questo comando non è supportato nelle istanze che utilizzano la replica a livello di blocco. Ad esempio, non effettuare le seguenti operazioni.

--Don't do this
ALTER DATABASE db1 SET PARTNER off   

Non impostare la modalità di ripristino su simple. Ad esempio, non effettuare le seguenti operazioni.

--Don't do this
ALTER DATABASE db1 SET RECOVERY simple   

Non utilizzare il DEFAULT_DATABASE parametro per creare nuovi accessi su istanze Multi-AZ DB a meno che non si utilizzi la replica a livello di blocco per l'elevata disponibilità, poiché queste impostazioni non possono essere applicate al mirror di standby. Ad esempio, non effettuare le seguenti operazioni.

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

Inoltre, non fare quanto segue.

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