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

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

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 disporre di un database offline su un’istanza database SQL Server presente in un’implementazione Multi-AZ SQL Server.

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

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

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 replica a livello di blocco AGs supporta una singola replica in standby.

Utenti, accessi e autorizzazioni vengono automaticamente replicati sulla versione secondaria. Non è necessario ricrearli. I ruoli del server definiti dall'utente vengono replicati in istanze DB che utilizzano la replica Always On AGs o a livello di blocco per le implementazioni Multi-AZ.

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

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, si consiglia di bilanciare gli host delle applicazioni in tutta la regione specificata. AZs AWS

Per ottenere prestazioni ottimali, non attivate il mirroring del database, l'opzione Always On AGs o la replica a livello di blocco 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 utilizzate il Set Partner Off comando quando lavorate con istanze Multi-AZ che utilizzano DBM o. AGs Questo comando non è supportato sulle 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 DB Multi-AZ 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]