Ripristino rapido dopo il failover con Cluster Cache Management per Aurora PostgreSQL - Amazon Aurora

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

Ripristino rapido dopo il failover con Cluster Cache Management per Aurora PostgreSQL

Per il ripristino rapido dell'istanza database di scrittura nei cluster Aurora PostgreSQL in caso di failover, utilizzare la gestione della cache del cluster per Amazon Aurora PostgreSQL. La gestione della cache del cluster garantisce il mantenimento delle prestazioni dell'applicazione in caso di failover.

In una tipica situazione di failover, è possibile che si verifichi un degrado delle prestazioni temporaneo ma di grandi dimensioni dopo il failover. Questo degrado si verifica perché all'avvio dell'istanza database di failover, la cache del buffer è vuota. Una cache vuota è anche nota col nome di cache fredda. Una cache fredda degrada le prestazioni perché l'istanza database deve leggere dal disco a una velocità minore, invece di sfruttare i valori memorizzati nella cache del buffer.

Con la gestione della cache del cluster, si imposta una specifica istanza database di lettura come destinazione del failover. La gestione della cache del cluster garantisce che i dati nella cache dell'istanza di lettura designata siano mantenuti sincronizzati con i dati nella cache dell'istanza database di scrittura. La cache dell'istanza di lettura designata pre-popolata con i valori prende il nome di cache calda. Se si verifica un failover, l'istanza di lettura designata utilizza immediatamente i valori presenti nella sua cache calda nel momento in cui viene promossa al ruolo di nuova istanza database di scrittura. Questo approccio garantisce all'applicazione prestazioni di recupero decisamente migliori.

La gestione della cache del cluster richiede che l'istanza del lettore designata disponga dello stesso tipo di classe di istanza e dimensione (db.r5.2xlarge o db.r5.xlarge, ad esempio) di scrittura. Tieni presente questo aspetto quando crei cluster database Aurora PostgreSQL in modo che il cluster possa essere ripristinato durante un failover. Per un elenco dei tipi e delle dimensioni delle classi di istanza, consulta Specifiche hardware per le classi di istanza database per Aurora.

Nota

La gestione della cache cluster non è supportata per i cluster database Aurora PostgreSQL che fanno parte dei database globali Aurora. Si consiglia di non eseguire alcun carico di lavoro sull'istanza di lettura di livello 0 designata.

Configurazione della gestione della cache del cluster

Per configurare la gestione della cache del cluster, eseguire i processi seguenti in ordine.

Nota

Dopo aver completato queste fasi, attendi almeno 1 minuto affinché la gestione della cache del cluster sia completamente operativa.

Abilitazione della gestione della cache del cluster

Per abilitare la gestione della cache del cluster, attenersi alla procedura descritta di seguito.

Per abilitare la gestione della cache del cluster
  1. Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel riquadro di navigazione scegliere Parameter groups (Gruppi di parametri).

  3. Nell'elenco, selezionare il gruppo di parametri per il cluster di database di Aurora PostgreSQL.

    Il cluster di database deve utilizzare un gruppo di parametri diverso da quello predefinito, poiché non è possibile modificare i valori in un gruppo di parametri predefinito.

  4. Per Parameter group actions (Operazioni del gruppo di parametri), scegliere Edit (Modifica).

  5. Impostare il valore del parametro del cluster apg_ccm_enabled su 1.

  6. Seleziona Save changes (Salva modifiche).

Per abilitare la gestione della cache del cluster per un cluster database di Aurora PostgreSQL, utilizzare il comando AWS CLI della modify-db-cluster-parameter-group con i seguenti parametri obbligatori:

  • --db-cluster-parameter-group-name

  • --parameters

Esempio

Per LinuxmacOS, oUnix:

aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name my-db-cluster-parameter-group \ --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

Per Windows:

aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name my-db-cluster-parameter-group ^ --parameters "ParameterName=apg_ccm_enabled,ParameterValue=1,ApplyMethod=immediate"

Impostazione della priorità del livello di promozione per l'istanza database di scrittura

Per la gestione della cache del cluster, assicurarsi che la priorità della promozione sia tier-0 per l'istanza database di scrittura del cluster di database di Aurora PostgreSQL. Il livello della priorità di promozione è un valore che specifica l'ordine in cui un'istanza di lettura di Aurora viene promossa al ruolo di istanza database di scrittura dopo un errore. I valori validi sono 0–15, dove 0 è la priorità massima e 15 è la priorità minima. Per ulteriori informazioni sul livello di promozione, consultare Tolleranza ai guasti di un cluster DB Aurora.

Per impostare la priorità di promozione per l'istanza database di scrittura su tier-0
  1. Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel riquadro di navigazione, scegliere Databases (Database).

  3. Scegliere l'istanza database Writer (di scrittura) del cluster di database di Aurora PostgreSQL.

  4. Scegliere Modify (Modifica). Viene visualizzata la pagina Modify DB Instance (Modifica istanza database).

  5. Nel pannello Additional configuration (Configurazione aggiuntiva) scegliere tier-0 (livello 0) per la Failover priority (Priorità failover).

  6. Scegliere Continue (Continua) e controllare il riepilogo delle modifiche.

  7. Per applicare immediatamente le modifiche dopo il salvataggio, scegliere Apply immediately (Applica immediatamente).

  8. Scegliere Modify DB Instance (Modifica istanza database) per salvare le modifiche.

Per impostare la priorità del livello di promozione su 0 per l'istanza Writer DB che utilizza ilAWS CLI, chiamate il modify-db-instancecomando con i seguenti parametri obbligatori:

  • --db-instance-identifier

  • --promotion-tier

  • --apply-immediately

Esempio

Per LinuxmacOS, oUnix:

aws rds modify-db-instance \ --db-instance-identifier writer-db-instance \ --promotion-tier 0 \ --apply-immediately

Per Windows:

aws rds modify-db-instance ^ --db-instance-identifier writer-db-instance ^ ---promotion-tier 0 ^ --apply-immediately

Impostazione della priorità del livello di promozione per un'istanza database di lettura

È necessario impostare solo un'istanza Reader DB per la gestione della cache del cluster. Per farlo, scegli un lettore dal ​​cluster Aurora PostgreSQL che sia la stessa classe di istanza e che abbia le stesse dimensioni dell'istanza database di scrittura. Ad esempio, se lo scrittore utilizza db.r5.xlarge, scegliere un lettore che utilizzi lo stesso tipo di classe di istanza e la stessa dimensione. Quindi impostare il livello della priorità di promozione su 0.

Il livello della priorità di promozione è un valore che specifica l'ordine in cui un'istanza di lettura di Aurora viene promossa al ruolo di istanza database di scrittura dopo un errore. I valori validi sono compresi nell'intervallo tra 0 e 15, dove 0 è la priorità massima e 15 è la priorità minima.

Per impostare la priorità di promozione per l'istanza database di lettura su tier-0
  1. Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

  2. Nel riquadro di navigazione, scegliere Databases (Database).

  3. Scegliere l'istanza database Reader (Di lettura) del cluster di database di Aurora PostgreSQL che sia della stessa classe di istanza dell'istanza database di scrittura.

  4. Scegliere Modify (Modifica). Viene visualizzata la pagina Modify DB Instance (Modifica istanza database).

  5. Nel pannello Additional configuration (Configurazione aggiuntiva) scegliere tier-0 (livello 0) per la Failover priority (Priorità failover).

  6. Scegliere Continue (Continua) e controllare il riepilogo delle modifiche.

  7. Per applicare immediatamente le modifiche dopo il salvataggio, scegliere Apply immediately (Applica immediatamente).

  8. Scegliere Modify DB Instance (Modifica istanza database) per salvare le modifiche.

Per impostare la priorità del livello di promozione su 0 per l'istanza Reader DB utilizzando ilAWS CLI, chiamate il modify-db-instancecomando con i seguenti parametri obbligatori:

  • --db-instance-identifier

  • --promotion-tier

  • --apply-immediately

Esempio

Per LinuxmacOS, oUnix:

aws rds modify-db-instance \ --db-instance-identifier reader-db-instance \ --promotion-tier 0 \ --apply-immediately

Per Windows:

aws rds modify-db-instance ^ --db-instance-identifier reader-db-instance ^ ---promotion-tier 0 ^ --apply-immediately

Monitoraggio della cache

Dopo aver configurato la gestione della cache del cluster, è possibile monitorare lo stato di sincronizzazione tra la cache del buffer dell'istanza database di scrittura e la cache del buffer calda di scrittura designata. Per esaminare il contenuto della cache del buffer sia sull'istanza database di scrittura sia sull'istanza database di lettura designata, utilizza il modulo PostgreSQL pg_buffercache. Per ulteriori informazioni, consulta la documentazione di PostgreSQL pg_buffercache.

Utilizzo della funzione aurora_ccm_status

La gestione della cache del cluster mette a disposizione anche la funzione aurora_ccm_status. Utilizza la funzione aurora_ccm_status sull'istanza database di scrittura per ottenere le seguenti informazioni sull'avanzamento del popolamento della cache sull'istanza database di lettura designata:

  • buffers_sent_last_minute – Quanti buffer sono stati inviati all'istanza database di lettura designata nell'ultimo minuto.

  • buffers_found_last_minute: il numero di buffer con accesso frequente identificati durante l'ultimo minuto.

  • buffers_sent_last_scan – Quanti buffer sono stati inviati all'istanza database di lettura designata durante l'ultima scansione completa della cache.

  • buffers_found_last_scan – Quanti buffer sono stati identificati come soggetti ad accesso frequente ed è stato necessario inviare durante l'ultima scansione completa della cache. I buffer già memorizzati sull'istanza database di lettura designata non vengono inviati.

  • buffers_sent_current_scan – Quanti buffer sono stati inviati finora durante la scansione corrente.

  • buffers_found_current_scan – Quanti buffer sono stati identificati come soggetti ad accesso frequente nella scansione corrente.

  • current_scan_progress – Quanti buffer sono stati analizzati finora durante la scansione corrente.

L'esempio seguente mostra come utilizzare la funzione aurora_ccm_status per convertire parte del suo output in velocità e percentuale di popolamento della cache calda.

SELECT buffers_sent_last_minute*8/60 AS warm_rate_kbps, 100*(1.0-buffers_sent_last_scan::float/buffers_found_last_scan) AS warm_percent FROM aurora_ccm_status();

Risoluzione dei problemi relativi alla configurazione CCM

Quando si abilita il parametro apg_ccm_enabled cluster, la gestione della cache del cluster viene attivata automaticamente a livello di istanza sull'istanza DB writer e su un'istanza DB reader sul cluster Aurora PostgreSQL DB. L'istanza writer e reader devono utilizzare lo stesso tipo e dimensione della classe di istanza. La priorità del loro livello di promozione è impostata su0. Le altre istanze di lettura nel cluster DB devono avere un livello di promozione diverso da zero e la gestione della cache del cluster è disabilitata per tali istanze.

I seguenti motivi possono causare problemi nella configurazione e disabilitare la gestione della cache del cluster:

  • Quando non esiste un'istanza DB a lettore singolo impostata sul livello di promozione 0.

  • Quando l'istanza DB Writer non è impostata sul livello di promozione 0.

  • Quando più di un'istanza DB Reader sono impostate sul livello di promozione 0.

  • Quando le istanze DB di Writer e One Reader con livello di promozione 0 non hanno le stesse dimensioni.