Implementazioni Multi-AZ per Amazon RDS for Microsoft SQL Server

Le implementazioni Multi-AZ forniscono alle istanze database maggior disponibilità, longevità dei dati e tolleranza ai guasti. In caso di manutenzione pianificata del database o interruzione non pianificata del servizio, Amazon RDS esegue automaticamente il failover sull'istanza DB up-to-date secondaria. Questa funzionalità consente alle operazioni del database di riprendere velocemente senza intervento manuale. Le istanze primarie e di standby usano lo stesso endpoint, il cui indirizzo di rete fisico passa alla replica secondaria come parte del processo di failover. Non è necessario riconfigurare l'applicazione quando si verifica un failover.

Amazon RDS supporta le implementazioni Multi-AZ per Microsoft SQL Server tramite il mirroring del database (DBM) di SQL Server o i gruppi di disponibilità (AG) Always On. Amazon RDS monitora e mantiene lo stato della tua implementazione Multi-AZ. Se si verificano problemi, RDS ripara automaticamente le istanze database non salutari, ristabilisce la sincronizzazione e avvia i failover. Il failover ha luogo solo se le istanze di standby e primarie non sono completamente sincronizzate. Non è necessario gestire nulla.

Quando configuri il Multi-AZ per SQL Server, RDS configura automaticamente tutti i database sull'istanza per utilizzare i gruppi di disponibilità o il mirroring di database. Amazon RDS gestisce l'istanza primaria, l’istanza witness e l'istanza di standby per tuo conto. Poiché la configurazione è automatica, RDS seleziona DBM o Always On AGs in base alla versione di SQL Server distribuita.

Amazon RDS supporta Multi-AZ con Always On AGs per le seguenti versioni ed edizioni di SQL Server:

• SQL Server 2022:

  • Standard Edition

  • Enterprise Edition

• SQL Server 2019:

  • Standard Edition 15.00.4073.23 e successive

  • Enterprise Edition

• SQL Server 2017:

  • Standard Edition 14.00.3401.7 e successive

  • Enterprise Edition 14.00.3049.1 e successive

• SQL Server 2016: Enterprise Edition 13.00.5216.0 e successive

Amazon RDS supporta Multi-AZ con DBM per le seguenti versioni ed edizioni di SQL Server, tranne le versioni di Enterprise Edition annotate in precedenza:

• SQL Server 2019: Standard Edition 15.00.4043.16

• SQL Server 2017: edizioni Standard ed Enterprise

• SQL Server 2016: edizioni Standard ed Enterprise

• SQL Server 2014: edizioni Standard ed Enterprise

Per determinare se l'istanza database di SQL Server è Single-AZ, Multi-AZ con DBM o Multi-AZ con gruppi di disponibilità Always On, puoi utilizzare la seguente query SQL:

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';

L'output è simile a quello riportato di seguito.

high_availability
Multi-AZ (AlwaysOn)

Aggiunta di Multi-AZ a un'istanza database di Microsoft SQL Server

Quando si crea una nuova istanza DB di SQL Server utilizzando AWS Management Console, è possibile aggiungere Multi-AZ con Database Mirroring (DBM) o Always On AGs. A tale scopo, scegli Yes (Mirroring / Always On) (Sì (Mirroring/Always On)) in Multi-AZ deployment (Implementazione Multi-AZ). Per ulteriori informazioni, consulta Creazione di un'istanza database Amazon RDS.

Quando modifichi un'istanza database di SQL Server esistente usando la console, puoi aggiungere Multi-AZ con i gruppi di disponibilità o il mirroring di database selezionando Yes (Mirroring / Always On) (Sì (Mirroring/Always On)) in Multi-AZ deployment (Implementazione Multi-AZ) nella pagina Modify DB instance (Modifica istanza database). Per ulteriori informazioni, consulta Modifica di un'istanza database Amazon RDS.

Nota

Se l'istanza database esegue il mirroring del database, non gruppi di disponibilità Always On (AG), potrebbe essere necessario disabilitare l'ottimizzazione in memoria prima di aggiungere Multi-AZ. Disabilitare l'ottimizzazione in memoria con DBM prima di aggiungere Multi-AZ se l'istanza database esegue SQL Server 2014, 2016 o 2017 Enterprise Edition e l'ottimizzazione in memoria è abilitata.

Se l'istanza database esegue AGS, non richiede questa fase.

Rimozione di Multi-AZ da un'istanza database Microsoft SQL Server

Quando si modifica un'istanza DB di SQL Server esistente utilizzando AWS Management Console, è possibile rimuovere Multi-AZ con DBM o AGs. A tale scopo, scegli No (Mirroring / Always On) No (mirroring/Always on) in Multi-AZ deployment (Implementazione Multi-AZ) nella pagina Modify DB Instance (Modifica istanza database). Per ulteriori informazioni, consulta Modifica di un'istanza database Amazon RDS.

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

Di seguito sono riportate alcune limitazioni quando si utilizzano le implementazioni Multi-AZ su istanze database RDS per 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 i gruppi di disponibilità Always On supporta l'ottimizzazione in memoria.

• Multi-AZ con gruppi di disponibilità (AG) Always On 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. AWS Support Aprire la pagina del Centro di supporto AWS Support effettuando l'accesso se necessario, quindi selezionare Crea caso. Selezionare Service limit increase (Aumento limiti del servizio). Compilare e inviare il modulo.

Di seguito sono riportate alcune note quando si utilizzano le implementazioni Multi-AZ su istanze database RDS per SQL Server:

• 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 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 AG supporta una replica di standby singola.

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

• Nelle implementazioni Multi-AZ, RDS per SQL Server crea accessi a SQL Server per consentire Always On AGS o il mirroring del database. 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.

Di seguito sono riportate alcune raccomandazioni quando si utilizzano le implementazioni Multi-AZ su RDS per le istanze database di Microsoft SQL Server:

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

  • Implementazioni Multi-AZ per l'alta disponibilità

  • "Provisioned IOPS" per prestazioni veloci e coerenti

  • "Memoria ottimizzata" anziché "Uso generale"

• 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 della regione specificata AWS .

• Per prestazioni ottimali, non abilitare i gruppi di disponibilità Always On o il mirroring di database 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 blocco try/catch 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] SET DEFAULT_DATABASE=[db3]   
  

Determinazione della posizione della versione secondaria

Puoi determinare la posizione della replica secondaria usando la AWS Management Console. È necessario conoscere la posizione della versione secondaria se imposti l'istanza database primaria in un VPC.

È inoltre possibile visualizzare la zona di disponibilità del secondario utilizzando il AWS CLI comando describe-db-instances o l'operazione API RDS. DescribeDBInstances L'output mostra la zona di disponibilità secondaria in cui si trova il mirroring di standby.

Migrazione di mirroring di database a gruppi di disponibilità Always On

Nella versione 14.00.3049.1 di Microsoft SQL Server Enterprise Edition, i gruppi di disponibilità Always On sono abilitati per impostazione predefinita.

Per migrare il mirroring di database a gruppi di disponibilità Always On, verifica innanzitutto la versione di cui disponi. Se utilizzi un'istanza database con una versione precedente a Enterprise Edition 13.00.5216.0, modifica l'istanza per applicarla alla patch 13.00.5216.0 o successive. Se utilizzi un'istanza database con una versione precedente a Enterprise Edition 14.00.3049.1, modifica l'istanza per applicarla alla patch 14.00.3049.1 o successive.

Se desideri aggiornare un'istanza database sottoposta a mirroring per utilizzare i gruppi di disponibilità, esegui prima l'aggiornamento, modifica l'istanza per rimuovere Multi-AZ e quindi modificala nuovamente per aggiungere Multi-AZ. Ciò converte la tua istanza per usare i gruppi di disponibilità Always On.