Riavvio di un cluster Aurora con disponibilità di lettura

Con la funzionalità di disponibilità di lettura, puoi riavviare l'istanza writer del tuo cluster Aurora senza riavviare le istanze di lettura nel cluster DB 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, in un cluster di produzione è possibile riavviare le istanze del lettore una alla volta, iniziando solo al termine 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à di disponibilità in lettura per i cluster DB primari è disponibile in Aurora SQL My versione 2.10 e successive. La disponibilità di lettura per i cluster DB secondari è disponibile in Aurora SQL My versione 3.06 e successive.

Per Aurora Postgre SQL questa funzionalità è disponibile di default nelle 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à di disponibilità di lettura in Aurora SQL Postgre, vedere. Miglioramento della disponibilità di lettura delle repliche Aurora

Prima di questa funzionalità, il riavvio dell'istanza principale provocava il riavvio di ogni istanza del lettore contemporaneamente. 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 al comportamento di riavvio nei cluster Aurora DB con disponibilità di lettura è diversa per i database globali Aurora nelle versioni di Aurora My precedenti alla SQL 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à di lettura migliorata è supportata dai database globali di Aurora per le SQL versioni 12.16, 13.12, 14.9, 15.4 e successive di Aurora Postgre.

Si riavvia spesso il cluster dopo aver apportato modifiche ai gruppi di parametri del cluster. È possibile apportare modifiche ai parametri seguendo le procedure in . 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 SQL cluster Aurora My, è possibile aggiornare i parametri del cluster come binlog_format e innodb_purge_threads sull'istanza writer prima delle istanze reader. 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 SQL le istruzioni o l'output delle query, potrebbe essere necessario riavviare immediatamente le istanze del lettore. 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 SQL cluster Aurora My, vedere. Parametri a livello di cluster

Per un elenco di tutti i parametri del SQL cluster Aurora Postgre, vedere. Parametri a livello di cluster Aurora PostgreSQL

Suggerimento

Aurora My SQL potrebbe comunque riavviare alcune istanze del lettore insieme all'istanza writer 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 My riavvia SQL l'istanza Writer DB e la destinazione di failover solo 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.