Limitazioni, note e suggerimenti per l'implementazione di Multi-AZ di Microsoft SQL Server

Multi-AZ tra regioni non è supportata.

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 (AGs) 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).

Non è possibile rinominare un database su un'istanza database di SQL Server presente in un'implementazione Multi-AZ di SQL Server. Se è necessario rinominare un database su tale istanza, disattiva prima Multi-AZ per l'istanza database, quindi rinomina il database. Infine, attiva di nuovo Multi-AZ per l'istanza database.

Si possono ripristinare solo le istanze database Multi-AZ di cui è stato eseguito il backup con il modello di recupero Full.

Le implementazioni multi-AZ hanno un limite di 10.000 processi 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 distribuzione di SQL Server Multi-AZ.

RDS per SQL Server non replica le autorizzazioni del database MSDB nell'istanza secondaria. Se sono necessarie queste autorizzazioni sull'istanza secondaria, è necessario ricrearle manualmente.

Amazon RDS espone l'endpoint listener del gruppo di AGs disponibilità Always On. 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 la funzionalità Multi-AZ di SQL Server con un'istanza database SQL Server in un cloud privato virtuale (VPC), crea innanzitutto un gruppo di sottoreti DB con sottoreti in almeno due distinte zone di disponibilità. Quindi assegnare il gruppo di sottoreti DB alla replica primaria dell'istanza database di SQL Server.

Quando un'istanza database viene modificata e impostata come implementazione Multi-AZ, durante la modifica il relativo stato è Modifica in corso. 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).

Le implementazioni Multi-AZ gestiscono 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 o AGs supporta una singola replica in standby.

Utenti, accessi e autorizzazioni vengono automaticamente replicati sulla versione secondaria. Non è necessario ricrearli. I ruoli server definiti dall'utente vengono replicati solo nelle istanze DB che utilizzano Always On per implementazioni Multi-AZ. AGs

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

RDS per SQL Server crea un accesso a SQL Server per consentire l'accesso alla lettura delle repliche. RDS crea un accesso con lo schema seguente,. db_<readreplica_dbiResourceId>_node_login

Nelle distribuzioni Multi-AZ, i processi di SQL Server Agent vengono replicati dall'host principale all'host secondario quando la funzionalità di replica del processo è attivata. Per ulteriori informazioni, consulta Attivazione della replica di processo SQL Server Agent.

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 distribuzioni di SQL Server Multi-AZ, riavviare con failover, riavvia solo l'istanza database primaria. Dopo aver eseguito il failover, l'istanza database primaria diventa la nuova istanza database secondaria. I parametri potrebbero non essere aggiornati per 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 AZs in tutta la AWS regione specificata.

Per prestazioni ottimali, non attivate il mirroring del database o Always On AGs durante un'operazione di caricamento di dati di grandi dimensioni. Se vuoi caricare i dati il più rapidamente possibile, termina il caricamento dei dati prima di convertire l'istanza database in un'implementazione 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 utilizzare il comando Set Partner Off quando lavori con le istanze Multi-AZ. 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 parametro DEFAULT_DATABASE quando crei nuovi accessi sulle istanze database Multi-AZ poiché queste impostazioni non possono essere applicate al mirroring 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]