Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Riavvio di un cluster Aurora con disponibilità di lettura
Se si utilizza la funzionalità della disponibilità di lettura, è possibile riavviare l’istanza di scrittura del cluster Aurora senza riavviare le istanze di lettura nel cluster di database primario o secondario. In questo modo si contribuisce a mantenere alta la disponibilità del cluster per le operazioni di lettura durante il riavvio dell'istanza di scrittura. È possibile riavviare le istanze di lettura in un secondo momento, secondo una pianificazione adatta a te. Ad esempio, per un cluster di produzione, è possibile riavviare le istanze di lettura una alla volta, iniziando solo dopo il completamento del riavvio dell’istanza primaria. Per ogni istanza DB che si riavvia, attenersi alla procedura in Riavvio di un'istanza database in un cluster Aurora.
La funzionalità della disponibilità di lettura per i cluster di database primari è disponibile in Aurora MySQL 2.10 e versioni successive. La disponibilità di lettura per i cluster di database secondari è disponibile in Aurora MySQL 3.06 e versioni successive.
Per Aurora PostgreSQL, questa funzione è disponibile per impostazione predefinita per le seguenti versioni:
15.2 o versioni successive alla 15
14.7 o versioni successive alla 14
13.10 o versioni successive alla 13
12.14 e versioni successive alla 12
Per ulteriori informazioni sulla funzionalità della disponibilità di lettura in Aurora PostgreSQL, consulta Miglioramento della disponibilità di lettura delle repliche Aurora.
Prima di questa funzionalità, il riavvio dell’istanza primaria causava contemporaneamente un riavvio per ogni istanza di lettura. Se il cluster Aurora sta eseguendo una versione precedente, utilizzare invece la procedura di riavvio in Riavvio di un cluster Aurora senza disponibilità di lettura.
Nota
La modifica del comportamento di riavvio nei cluster di database Aurora con la funzionalità della disponibilità di lettura è diversa per i database Aurora MySQL precedenti alla versione 3.06 Se si riavvia l'istanza di scrittura per il cluster principale in un database globale Aurora, le istanze di lettura nel cluster primario rimangono disponibili. Tuttavia, le istanze database in qualsiasi cluster secondario si riavviano contemporaneamente.
Una versione limitata della funzionalità di disponibilità in lettura migliorata è supportata dai database globali Aurora PostgreSQL versioni 12.16, 13.12, 14.9, 15.4 e versioni successive.
Si riavvia spesso il cluster dopo aver apportato modifiche ai gruppi di parametri del cluster. È possibile apportare modifiche ai parametri seguendo le procedure in Gruppi di parametri per Amazon Aurora. Si supponga di riavviare l'istanza database di scrittura in un cluster Aurora per applicare le modifiche ai parametri del cluster. Alcune o tutte le istanze database di lettura potrebbero continuare a utilizzare le vecchie impostazioni dei parametri. Tuttavia, le diverse impostazioni dei parametri non influiscono sull'integrità dei dati del cluster. Tutti i parametri del cluster che influiscono sull'organizzazione dei file di dati vengono utilizzati solo dall'istanza database di scrittura.
Ad esempio, in un cluster Aurora MySQL è possibile aggiornare i parametri del cluster come binlog_format e innodb_purge_threads sull'istanza di scrittura prima delle istanze di lettura. Solo l'istanza di scrittura sta scrivendo registri binari e eliminando i record di annullamento. Per i parametri che modificano il modo in cui le query interpretano le istruzioni SQL o l'output della query, potrebbe essere necessario fare attenzione nel riavviare immediatamente le istanze di lettura. Lo si fa per evitare comportamenti imprevisti dell'applicazione durante le query. Ad esempio, supponiamo di modificare il parametro lower_case_table_names e di riavviare l'istanza di scrittura. In questo caso, le istanze di lettura potrebbero non essere in grado di accedere a una tabella appena creata finché non vengono tutte riavviate.
Per un elenco di tutti i parametri del cluster Aurora MySQL, consulta Parametri a livello di cluster.
Per un elenco di tutti i parametri per cluster Aurora MySQL, consulta Parametri a livello di cluster Aurora PostgreSQL.
Suggerimento
Aurora MySQL potrebbe comunque riavviare alcune istanze di lettura insieme all'istanza di scrittura se il cluster sta elaborando un carico di lavoro con un throughput elevato.
La riduzione del numero di riavvii si applica anche durante le operazioni di failover. Aurora MySQL riavvia solo l'istanza database di scrittura e la destinazione del failover durante un failover. Altre istanze DB di lettura nel cluster rimangono disponibili per continuare a elaborare le query tramite connessioni all'endpoint di lettura. Pertanto, è possibile migliorare la disponibilità durante un failover se è presente più di un'istanza database di lettura in un cluster.
