Dimensionamento a zero ACU con pausa e ripresa automatiche per Aurora Serverless v2 - Amazon Aurora
Panoramica della pausa automatica Prerequisiti e limitazioni Attivazione e disattivazione della pausa automatica Come funziona la pausa automatica Pausa automatica e configurazioni dei cluster Aurora Monitoraggio della pausa automatica Risoluzione dei problemi relativi alla pausa automatica Progettazione delle applicazioni per la pausa automatica

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

Dimensionamento a zero ACU con pausa e ripresa automatiche per Aurora Serverless v2

È possibile specificare che le istanze database Aurora Serverless v2 vengano ridotte verticalmente fino a zero ACU e entrino in pausa automaticamente, se non vengono avviate connessioni dalle attività dell’utente entro un periodo di tempo specificato. A tale scopo, è necessario specificare un valore ACU minimo pari a zero per il cluster di database. Quando un’istanza è in stato di pausa, non viene addebitato alcun costo per la sua capacità. L’abilitazione della funzionalità di pausa e ripresa automatiche (pausa automatica) per i cluster Aurora poco utilizzati o con lunghi periodi di inattività permette di contenere i costi del parco di database.

Nota

La funzionalità di pausa automatica è disponibile per Aurora Serverless v2 con Aurora PostgreSQL e Aurora MySQL. Potrebbe essere necessario aggiornare la versione del motore di database Aurora per sfruttare questa funzionalità. Per le versioni del motore in cui è disponibile una capacità minima di 0 ACU, consulta Capacità di Aurora Serverless v2.

Panoramica della funzionalità di pausa automatica Aurora Serverless v2

Le istanze database Aurora Serverless v2 possono entrare automaticamente in pausa in assenza di connessioni utente per un determinato periodo di tempo e riprendere automaticamente all’arrivo di una richiesta di connessione. La funzionalità di pausa e ripresa automatiche Aurora Serverless v2 aiuta a contenere i costi dei sistemi che non hanno un obiettivo del livello di servizio (SLO) rigido. Ad esempio, è possibile abilitare questa funzionalità per i cluster utilizzati per lo sviluppo e il test o per le applicazioni interne in cui è accettabile una breve pausa mentre il database riprende l’attività. Se il carico di lavoro presenta periodi di inattività e può tollerare lievi ritardi nella connessione mentre l’istanza riprende, valutare la possibilità di utilizzare la pausa automatica con le istanze Aurora Serverless v2 per ridurre i costi.

Per controllare questo comportamento, occorre specificare se le istanze database Aurora Serverless v2 in un cluster possono o meno entrare in pausa automaticamente e quanto deve durare lo stato di inattività di ciascuna istanza prima della messa in pausa. Per abilitare il comportamento di pausa automatica per tutte le istanze database Aurora Serverless v2 in un cluster Aurora, impostare il valore di capacità minima per il cluster su zero ACU.

Se in passato è stata utilizzata la funzionalità Aurora Serverless v1 che impostava il valore a zero ACU dopo uno specifico periodo di inattività, è possibile passare alla funzionalità di pausa automatica Aurora Serverless v2corrispondente.

I vantaggi in termini di riduzione dei costi della funzionalità di pausa automatica sono analoghi a quelli della funzionalità di arresto/avvio del cluster. La pausa automatica per Aurora Serverless v2 offre vantaggi aggiuntivi, come la ripresa più rapida rispetto all’avvio di un cluster arrestato e la determinazione automatica del momento in cui mettere in pausa e riprendere ciascuna istanza database.

La funzionalità di pausa automatica fornisce inoltre una maggiore granularità nel controllo dei costi per le risorse di elaborazione all’interno del cluster. È possibile abilitare la pausa di alcune istanze di lettura anche lasciando sempre attivi l’istanza di scrittura e le altre istanze di lettura del cluster. Per farlo, assegnare alle istanze di lettura che possono entrare in pausa indipendentemente dalle altre istanze una priorità di failover compresa tra 2 e 15.

Le istanza di scrittura e tutte le istanze di lettura con priorità di failover 0 e 1 vengono sempre messe in pausa e riprese contemporaneamente. Pertanto, le istanze di questo gruppo entrano in pausa solo dopo il verificarsi di una specifica condizione: nessuna istanza deve avere connessioni attive per l’intervallo di tempo specificato.

I cluster Aurora database possono contenere una combinazione di istanze database di scrittura e di lettura e di istanze database Aurora Serverless v2 e con provisioning. Pertanto, per utilizzare questa funzionalità in modo efficace, è utile comprendere i seguenti aspetti del meccanismo di pausa automatica:

  • Le circostanze in cui un’istanza database potrebbe mettersi in pausa automaticamente.

  • Quando può essere impedita la messa in pausa di un’istanza database. Ad esempio, l’abilitazione di alcune funzionalità di Aurora o l’esecuzione di determinati tipi di operazioni sul cluster potrebbe impedire la messa in pausa delle istanze, anche se non è presente alcuna connessione a tali istanze.

  • Le conseguenze della messa in pausa di un’istanza per il monitoraggio e la fatturazione.

  • Quali azioni comportano la ripresa dell’elaborazione di un’istanza database.

  • Come cambia la capacità di un’istanza database quando si verificano gli eventi di pausa e ripresa.

  • Come controllare l’intervallo di inattività prima della pausa di un’istanza database.

  • Come codificare la logica dell’applicazione per gestire il periodo di tempo durante il quale un’istanza database riprende l’elaborazione.

Prerequisiti e limitazioni per la funzionalità di pausa automatica Aurora Serverless v2

Prima di utilizzare la funzionalità di pausa automatica, controllare quali versioni del motore utilizzare. Inoltre, verificare se la pausa automatica funziona in combinazione con le altre funzionalità di Aurora che si intende utilizzare. Non è possibile attivare la pausa automatica se si utilizza una versione del motore che non la supporta. Per le funzionalità incompatibili, non viene generato alcun errore in caso di utilizzo in combinazione con la pausa automatica. Se il cluster utilizza funzionalità o impostazioni incompatibili, le istanze Aurora Serverless v2 non entreranno in pausa automaticamente.

Alcune condizioni o impostazioni impediscono la messa in pausa automatica delle istanze Aurora Serverless v2. Per ulteriori informazioni, consulta Situazioni in cui Aurora Serverless v2 non viene messo in pausa automaticamente.

Attivazione e disattivazione della funzionalità di pausa automatica

È possibile attivare e disattivare la funzionalità di pausa automatica a livello di cluster. Per farlo, seguire le stesse procedure utilizzate per regolare la capacità minima e massima del cluster. La funzionalità di pausa automatica corrisponde a una capacità minima di 0 ACU.

Attivazione della pausa automatica per le istanze Aurora Serverless v2 in un cluster

Segui la procedura riportata in Impostazione dell'intervallo di capacità di Aurora Serverless v2 per un cluster. Per la capacità minima, scegliere 0 ACU. Quando si sceglie una capacità minima di 0 ACU, è possibile anche specificare il periodo di inattività dell’istanza prima che venga messa automaticamente in pausa.

L’esempio dell’interfaccia della riga di comando seguente mostra come creare un cluster Aurora con la funzionalità di pausa automatica abilitata e l’intervallo di pausa automatica impostato su dieci minuti (600 secondi). 

aws rds create-db-cluster \
    --db-cluster-identifier my-serverless-v2-cluster \
    --region eu-central-1 \
    --engine aurora-mysql \
    --engine-version 8.0 \
    --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 \
    --master-username myuser \
    --manage-master-user-password

L’esempio dell’interfaccia della riga di comando seguente mostra come attivare la funzionalità di pausa automatica per un cluster Aurora esistente. Questo esempio imposta l’intervallo di pausa automatica su un’ora (3.600 secondi). 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=0,MaxCapacity=80,SecondsUntilAutoPause=3600

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 0,
    "MaxCapacity": 80.0,
    "SecondsUntilAutoPause": 3600
}

Intervallo di timeout della pausa automatica Aurora Serverless v2 configurabile

L’intervallo di timeout è mostrato nell’attributo ServerlessV2ScalingConfiguration del cluster Aurora. È possibile specificare questo intervallo nella AWS Management Console durante la creazione o la modifica di un cluster Aurora, se la capacità minima è impostata su zero ACU. Per specificarlo nell’AWS CLI, utilizzare il parametro --serverless-v2-scaling-configuration durante la creazione o la modifica di un cluster Aurora. Per specificarlo nell’API RDS, utilizzare il parametro ServerlessV2ScalingConfiguration durante la creazione o la modifica di un cluster Aurora.

L’intervallo minimo che è possibile impostare è 300 secondi (cinque minuti). Questa è l’impostazione predefinita se non si specifica un intervallo. L’intervallo massimo che è possibile impostare è 86.400 secondi (un giorno).

Si supponga di disattivare la funzionalità di pausa automatica per un cluster impostando la capacità minima del cluster su un valore diverso da zero. In tal caso, la proprietà interval viene rimossa dall’attributo ServerlessV2ScalingConfiguration. L’assenza di tale proprietà fornisce un’ulteriore conferma che la funzionalità di pausa automatica è disattivata per quel cluster. Se successivamente si riattiva la pausa automatica, si può specificare di nuovo un qualsiasi intervallo personalizzato.

Ripresa di un’istanza Aurora Serverless v2 in pausa automatica

  • Quando ci si connette a un’istanza Aurora Serverless v2 in pausa, questa si riattiva e accetta automaticamente la connessione.

  • Un tentativo di connessione senza credenziali valide comporta comunque la ripresa dell’istanza database.

  • Se ci si connette tramite l’endpoint di scrittura, Aurora riprende l’istanza database di scrittura se è in pausa automatica. Allo stesso tempo, Aurora riattiva tutte le istanze di lettura in pausa automatica con priorità di failover 0 o 1, il che significa che la loro capacità è legata alla capacità dell’istanza di scrittura.

  • Se ci si connette tramite l’endpoint di lettura, Aurora sceglie un’istanza di lettura in modo casuale. Se l’istanza di lettura è in pausa, Aurora la riattiva. Inoltre, Aurora riattiva per prima l’istanza di scrittura, che deve essere sempre attiva se ci sono istanze di lettura attive. Quando Aurora riattiva l’istanza di scrittura, vengono riprese anche tutte le istanze di lettura nei livelli di promozione del failover zero e uno.

  • Se si invia una richiesta al cluster tramite l’API dati RDS, Aurora riattiva l’istanza di scrittura se è in pausa. A questo punto, Aurora elabora la richiesta API dati.

  • Quando si modifica il valore di un parametro di configurazione in un gruppo di parametri del cluster di database, Aurora riattiva automaticamente tutte le istanze Aurora Serverless v2 in pausa in tutti i cluster che utilizzano quel gruppo di parametri del cluster. Analogamente, quando si modifica il valore di un parametro in un gruppo di parametri database, Aurora riattiva automaticamente tutte le istanze Aurora Serverless v2 in pausa che utilizzano quel gruppo di parametri database. Lo stesso comportamento di ripresa automatica si applica quando si modifica un cluster per assegnare un gruppo di parametri del cluster diverso o quando si modifica un’istanza per assegnare un gruppo di parametri database diverso.

  • L’esecuzione di una richiesta di backtrack riattiva automaticamente l’istanza di scrittura Aurora Serverless v2 se è in pausa. Aurora elabora la richiesta di backtrack dopo la ripresa dell’istanza di scrittura. È possibile tornare indietro al momento in cui un’istanza Aurora Serverless v2 è entrata in pausa.

  • L’acquisizione di uno snapshot del cluster o l’eliminazione di uno snapshot non comporta la ripresa di alcuna istanza Aurora Serverless v2.

  • La creazione di un clone di Aurora comporta la ripresa dell’istanza di scrittura del cluster che viene clonato.

  • Se un’istanza in pausa riceve un alto numero di richieste di connessione prima che finisca di riattivarsi, alcune sessioni potrebbero non riuscire a connettersi. Consigliamo di implementare la logica di ripetizione per le connessioni ai cluster Aurora che hanno istanze Aurora Serverless v2 con la pausa automatica abilitata. Ad esempio, in caso di mancata connessione, hai a disposizione tre tentativi per riprovare a eseguirla.

  • Aurora può eseguire alcuni tipi di manutenzione spicciola interna senza riattivare un’istanza. Tuttavia, alcuni tipi di manutenzione che avvengono durante la finestra di manutenzione del cluster richiedono che Aurora riattivi l’istanza. Al termine della manutenzione, l’istanza viene nuovamente messa in pausa automaticamente se non viene rilevata alcuna attività dopo l’intervallo specificato.

    Nota

    Aurora non riprende automaticamente un’istanza in pausa per processi pianificati specifici del motore, come quelli dell’estensione pg_cron PostgreSQL o del pianificatore di eventi MySQL. Per garantire l’esecuzione di tali processi, avviare manualmente una connessione all’istanza prima dell’orario pianificato. Aurora non mette in coda alcun processo la cui l’ora pianificata corrisponde al periodo di pausa dell’istanza database. Tali processi vengono saltati quando l’istanza viene successivamente riavviata.

  • Se si verifica un failover del cluster Aurora mentre un’istanza Aurora Serverless v2 è in pausa automatica, Aurora potrebbe riprendere un’istanza e promuoverla a istanza di scrittura. Lo stesso potrebbe accadere se una o più istanze database vengono rimosse dal cluster mentre un’istanza è in pausa. In questo caso, l’istanza diventa immediatamente un’istanza di scrittura quando viene riattivata.

  • Le operazioni che modificano le proprietà del cluster causano anche la ripresa di tutte le istanze Aurora Serverless v2 in pausa automatica. Ad esempio, un’istanza in pausa automatica si riattiva per operazioni come le seguenti:

    • Modifica dell’intervallo di dimensionamento del cluster.

    • Aggiornamento della versione del motore del cluster.

    • Descrizione o download dei file di log da un’istanza in pausa. È possibile esaminare i dati di log storici delle istanze in pausa abilitando il caricamento dei log su CloudWatch e analizzandoli tramite CloudWatch.

Disattivazione della pausa automatica per le istanze Aurora Serverless v2 in un cluster

Segui la procedura riportata in Impostazione dell'intervallo di capacità di Aurora Serverless v2 per un cluster. Per la capacità minima, scegliere un valore pari o superiore a 0,5. Quando si disattiva la funzionalità di pausa automatica, l’intervallo di inattività dell’istanza viene reimpostato. Se si riattiva la pausa automatica, specificare un nuovo intervallo di timeout.

L’esempio dell’interfaccia della riga di comando seguente mostra come disattivare la funzionalità di pausa automatica per un cluster Aurora esistente. L’output describe-db-clusters mostra che l’attributo SecondsUntilAutoPause viene rimosso quando la capacità minima è impostata su un valore diverso da zero. 

aws rds modify-db-cluster --db-cluster-identifier serverless-v2-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=80

aws rds describe-db-clusters --db-cluster-identifier serverless-v2-cluster \
  --query 'DBClusters[*].ServerlessV2ScalingConfiguration|[0]'
{
    "MinCapacity": 2,
    "MaxCapacity": 80.0
}

Come funziona la funzionalità di pausa automatica Aurora Serverless v2

È possibile utilizzare le seguenti informazioni per pianificare l’utilizzo della funzionalità di pausa automatica. Comprendere in quali casi le istanze entrano in pausa, vengono riprese o rimangono attive può aiutare a trovare un equilibrio tra disponibilità, reattività e riduzione dei costi.

Che cosa succede quando le istanze Aurora Serverless v2 entrano in pausa

Quando un’istanza database Aurora Serverless v2 entra in pausa allo scadere di un intervallo di tempo durante il quale non si registrano connessioni:

  • Aurora inizia a mettere in pausa l’istanza allo scadere dell’intervallo di tempo durante il quale non si registrano connessioni all’istanza, indipendentemente dal numero di ACU dell’istanza in quel momento.

  • Il meccanismo di pausa non è immediato. Un’istanza Aurora Serverless v2 in procinto di entrare in pausa automaticamente potrebbe attendere brevemente per recuperare il ritardo nell’applicazione di tutte le modifiche all’archiviazione Aurora.

  • I costi relativi all’istanza vengono sospesi. La metrica ServerlessV2Usage ha un valore pari a 0 quando l’istanza è in pausa.

  • Il valore dello stato dell’istanza non cambia. Lo stato viene comunque visualizzato come “disponibile”.

  • L’istanza interrompe la scrittura nei file di log del database. Smette di inviare metriche a CloudWatch e registra zero percento per CPUUtilization e ACUUtilization e zero per ServerlessDatabaseCapacity.

  • Aurora emette eventi quando un’istanza database Aurora Serverless v2 inizia la pausa, termina la pausa e se il meccanismo di pausa viene interrotto o non funziona. Per dettagli su questi eventi, consultare Eventi di istanza database.

Cosa succede quando le istanze Aurora Serverless v2 in pausa automatica riprendono

Quando un’istanza database Aurora Serverless v2 riprende dopo essere entrata in pausa automaticamente, si applicano le seguenti condizioni:

  • Tutte le modifiche ai parametri incluse nelle modifiche di pending-reboot vengono applicate quando l’istanza riprende.

  • Aurora emette eventi a livello di istanza quando ogni istanza database Aurora Serverless v2 inizia e termina la ripresa e se l’istanza non riesce a riattivarsi per qualche motivo. Per dettagli su questi eventi, consultare Eventi di istanza database.

  • Tutte le connessioni richieste vengono stabilite al termine della ripresa dell’istanza database. Poiché il tempo di ripresa tipico in genere è di circa 15 secondi, si consiglia di regolare le impostazioni del timeout del client su un valore superiore ai 15 secondi. Ad esempio, nelle impostazioni del driver JDBC, è possibile regolare i valori per le impostazioni connectTimeout e sslResponseTimeout in modo che superino i 15 secondi.

Nota

Se un’istanza Aurora Serverless v2 rimane in pausa per più di 24 ore, Aurora può mettere l’istanza in uno stato di sospensione più profondo, che richiede più tempo per riattivarsi. In questo caso, il tempo di ripresa può essere di 30 o più secondi, all’incirca equivalente al tempo di riavvio dell’istanza. Se il database presenta periodi di inattività che durano più di un giorno, si consiglia di impostare i timeout di connessione su un valore di almeno 30 secondi.

Come funziona la fatturazione delle istanze per i cluster Aurora Serverless v2 con pausa automatica

Durante la pausa automatica, i costi di un’istanza Aurora Serverless v2 sono pari a zero. La metrica ServerlessV2Usage è zero durante questo periodo. AWS addebita comunque i costi per l’archiviazione Aurora e altri aspetti del cluster non legati alla specifica istanza database.

Situazioni in cui Aurora Serverless v2 non viene messo in pausa automaticamente

  • Se il valore di capacità minima per il cluster di database è superiore a zero ACU, le istanze Aurora Serverless v2 nel cluster non vengono messe automaticamente in pausa. Se sono presenti cluster con istanze Aurora Serverless v2 precedenti alla disponibilità della funzionalità di pausa automatica, l’impostazione della capacità minima più bassa era pari a 0,5 ACU. Per utilizzare la funzionalità di pausa automatica con tali cluster, modificare l’impostazione della capacità minima su zero ACU.

  • Se sono aperte connessioni avviate dall’utente in un’istanza Aurora Serverless v2, questa non entrerà in pausa. Inoltre, l’istanza non entrerà in pausa mentre sono in corso attività come l’applicazione di patch e gli aggiornamenti. Le connessioni amministrative utilizzate da Aurora per i controlli dell’integrità non vengono considerate attività e non impediscono la messa in pausa dell’istanza.

  • In un cluster Aurora PostgreSQL con replica logica abilitata o in un cluster Aurora MySQL con replica binlog abilitata, l’istanza di scrittura e tutte le istanze di lettura nei livelli di promozione del failover zero e uno non entrano in pausa automaticamente. Aurora esegue una quantità minima costante di controlli sull’integrità della connessione di replica.

    Per i cluster con replica abilitata, è possibile comunque avere istanze di lettura Aurora nel cluster di origine con pausa automatica. Per attivare la funzionalità, impostare la priorità di failover delle istanze su un valore diverso da zero o uno. In questo modo, possono entrare in pausa indipendentemente dall’istanza di scrittura.

  • Se al cluster Aurora è associato Server proxy per RDS, il proxy mantiene una connessione aperta a ciascuna istanza database del cluster. Pertanto, tutte le istanze Aurora Serverless v2 in un cluster di questo tipo non entreranno in pausa automaticamente.

  • Se il cluster è il cluster primario di un Database globale Aurora, Aurora non mette automaticamente in pausa l’istanza di scrittura Aurora Serverless v2. Questo perché è necessario un livello costante di attività sull’istanza di scrittura per gestire gli altri cluster nel database globale. Poiché l’istanza di scrittura rimane attiva, anche le altre istanze di lettura Aurora Serverless v2 con priorità di failover zero o uno non entrano in pausa automaticamente.

  • Le istanze Aurora Serverless v2 nei cluster secondari di un Database globale Aurora non entrano in pausa automaticamente. Se un cluster di database viene promosso a cluster autonomo, la funzionalità di pausa automatica diventa effettiva se vengono soddisfatte tutte le altre condizioni.

  • In un cluster con un’integrazione Zero-ETL associata a Redshift, l’istanza di scrittura e tutte le istanze di lettura nei livelli di promozione del failover zero e uno non entrano in pausa automaticamente.

  • Oltre all’attività sulla porta del database principale dell’istanza, se un’istanza Aurora PostgreSQL ha la funzionalità Babelfish abilitata, qualsiasi connessione e attività sulla porta T-SQL impedisce la messa in pausa automatica dell’istanza.

Come funziona la pausa automatica con la funzionalità di arresto/avvio del cluster

È possibile arrestare e avviare un cluster Aurora quando la funzionalità di pausa automatica è abilitata. Non importa se alcune istanze sono in pausa. Quando si riavvia il cluster, tutte le istanze Aurora Serverless v2 in pausa vengono riattivate automaticamente.

Durante l’arresto di un cluster Aurora, le istanze Aurora Serverless v2 in pausa non vengono riattivate automaticamente in base ai tentativi di connessione. Una volta riavviato il cluster, si applicano i consueti meccanismi di messa in pausa e ripresa delle istanze Aurora Serverless v2.

Come funzionano la manutenzione e gli aggiornamenti per i cluster Aurora Serverless v2 con pausa automatica

  • Durante la pausa automatica di un’istanza Aurora Serverless v2, se si tenta di aggiornare il cluster Aurora, Aurora riprende l’istanza e la aggiorna.

  • Aurora riprende periodicamente eventuali istanze Aurora Serverless v2 in pausa automatica per eseguire operazioni di manutenzione come, ad esempio, aggiornamenti a versioni secondarie e modifiche a proprietà come i gruppi di parametri.

  • Dopo che un’istanza Aurora Serverless v2 viene riattivata per un’operazione amministrativa come un aggiornamento o interventi di manutenzione, Aurora attende almeno 20 minuti prima di mettere nuovamente in pausa l’istanza. Questo consente di completare tutte le eventuali operazioni in background. Il periodo di 20 minuti evita inoltre di sospendere e riprendere l’istanza più volte, nel caso in cui venga sottoposta a più operazioni amministrative consecutive.

Differenze nel comportamento della pausa automatica tra Aurora Serverless v2 e Aurora Serverless v1

  • Rispetto a Aurora Serverless v1, il tempo di ripresa di Aurora Serverless v2 è migliore. Il tempo di ripresa è in genere di circa 15 secondi se l’istanza è in pausa da meno di 24 ore. Se la pausa supera le 24 ore, invece, il tempo di ripresa potrebbe essere più lungo.

  • Il modo in cui Aurora Serverless v2 applica questa funzionalità ai cluster Multi-AZ fa sì che nel cluster siano presenti istanze database sia in pausa sia attive. L’istanza di scrittura riprende ogni volta che è in esecuzione un’istanza di lettura, poiché un’istanza di scrittura è necessario per coordinare determinate attività all’interno del cluster. Poiché Aurora Serverless v1 non utilizza istanze di lettura, l’intero cluster sarebbe sempre in pausa o attivo.

  • Quando l’endpoint di lettura sceglie casualmente un’istanza di lettura a cui connettersi, quell’istanza di lettura potrebbe essere già attiva o in pausa automatica. Pertanto, il tempo necessario per accedere all’istanza di lettura potrebbe variare ed essere più difficile da prevedere. I cluster Multi-AZ che utilizzano Aurora Serverless v2 e la pausa automatica potrebbero quindi trarre vantaggio dalla configurazione di endpoint personalizzati per casi d’uso specifici di sola lettura, invece di indirizzare tutte le sessioni di sola lettura all’endpoint di lettura.

  • Le istanze Aurora Serverless v2 vengono sottoposte a operazioni di manutenzione con la stessa frequenza delle istanze con provisioning. Poiché Aurora riattiva automaticamente le istanze quando necessitano di manutenzione, è possibile che le istanze Aurora Serverless v2 vengano riattivate più spesso rispetto ai cluster Aurora Serverless v1.

Come funziona la pausa automatica Aurora Serverless v2 per i diversi tipi di cluster Aurora

Le considerazioni relative alla funzionalità di pausa automatica dipendono dal numero di istanze presenti nel cluster Aurora, dai livelli di promozione del failover delle istanze di lettura e dal fatto che tutte le istanze siano Aurora Serverless v2 o siano una combinazione di istanze Aurora Serverless v2 e con provisioning.

Quando la funzionalità di pausa automatica è abilitata, è possibile organizzare il cluster Aurora per ottenere il giusto equilibrio tra disponibilità elevata, risposta rapida e scalabilità in base al caso d’uso specifico. Per farlo, scegliere la combinazione di istanze Aurora Serverless v2, istanze con provisioning e livelli di promozione del failover per le istanze database nel cluster.

I seguenti tipi di configurazioni mostrano le varie combinazioni possibili di disponibilità elevata e ottimizzazione dei costi per il cluster:

  • Per un sistema di sviluppo e test, è possibile configurare un cluster di database Single-AZ con un’istanza database Aurora Serverless v2. L’istanza singola serve tutte le richieste di lettura e scrittura. Quando il cluster non viene utilizzato per intervalli di tempo significativi, l’istanza database entra in pausa. A quel punto, anche i costi di elaborazione database per il cluster vengono sospesi.

  • Se un sistema esegue un’applicazione per cui la disponibilità elevata è una priorità, ma il cluster presenta ancora periodi in cui è completamente inattivo, è possibile configurare un cluster Multi-AZ che includa istanze database di scrittura e di lettura Aurora Serverless v2. Impostare l’istanza di lettura sulla priorità di failover zero o uno, in modo che l’istanza di scrittura e l’istanza di lettura vengano messe in pausa e riprendano contemporaneamente. In questo modo si ottiene il vantaggio di un failover rapido mentre il cluster è attivo. Quando il cluster rimane inattivo per un periodo superiore alla soglia di pausa automatica, i costi dell’istanza database per entrambe le istanze vengono sospesi. Quando il cluster riprende l’elaborazione, la prima sessione del database impiega un po’ di tempo per connettersi.

  • Supponiamo che il cluster sia costantemente attivo con una quantità minima di attività e richieda una risposta rapida per qualsiasi connessione. In tal caso, è possibile creare un cluster con più di un’istanza di lettura Aurora Serverless v2, quindi disaccoppiare le capacità di alcune istanze di lettura dall’istanza di scrittura. Specificare una priorità di failover zero o uno per l’istanza di scrittura e uno per l’istanza di lettura. Specificare una priorità maggiore di uno per le altre istanze di lettura. In questo modo, le istanze di lettura con livelli di priorità più elevati possono entrare in pausa automaticamente, anche quando l’istanza di scrittura e una delle istanze di lettura rimangono attive.

    In questo caso, è possibile utilizzare altre tecniche per garantire che il cluster rimanga sempre disponibile, pur garantendo una riduzione verticale della capacità durante i periodi di inattività:

    • È possibile utilizzare le istanze con provisioning per l’istanza di scrittura e per l’istanza di lettura con priorità 0 o 1. In questo modo, due istanze database non entrano mai in pausa automaticamente e sono sempre disponibili per gestire il traffico del database ed eseguire il failover.

    • È possibile configurare un endpoint personalizzato che includa le istanze Aurora Serverless v2 nei livelli di priorità più elevati, ma escluda l’istanza di scrittura o le istanze di lettura con livello di promozione 0 o 1. In questo modo, è possibile indirizzare le sessioni di sola lettura non sensibili alla latenza alle istanze di lettura che possono essere messi in pausa automaticamente. Per queste richieste si può evitare l’utilizzo dell’endpoint di lettura, perché Aurora può indirizzare le connessioni dell’endpoint di lettura all’istanza di lettura sempre attiva o a una delle istanze in pausa automatica. L’utilizzo dell’endpoint personalizzato consente di indirizzare le connessioni a diversi gruppi di istanze in base alle proprie preferenze in termini di risposta rapida o di dimensionamento aggiuntivo.

Come funziona la pausa automatica Aurora Serverless v2 per l’istanza di scrittura in un cluster di database

Quando un cluster Aurora database contiene una sola istanza database, il meccanismo per metterla in pausa e riattivarla automaticamente è semplice e dipende solo dall’attività sull’istanza di scrittura. Una configurazione di questo tipo potrebbe essere utile per i cluster utilizzati per attività di sviluppo e test o per l’esecuzione di applicazioni che non richiedono una disponibilità elevata. È importante ricordare che, in un cluster a istanza singola, Aurora indirizza le connessioni all’istanza database di scrittura attraverso l’endpoint di lettura. Pertanto, per un cluster di database a istanza singola, il tentativo di connessione all’endpoint di lettura causa la ripresa dell’istanza database di scrittura messa in pausa automaticamente.

I fattori aggiuntivi riportati di seguito si applicano ai cluster Aurora con più istanze database:

  • In genere, all’interno di un cluster di database Aurora si accede spesso all’istanza database di scrittura. Pertanto, è possibile che l’istanza database di scrittura rimanga attiva anche quando una o più istanze database di lettura entrano in pausa automaticamente.

  • Alcune attività sulle istanze database di lettura richiedono che l’istanza database di scrittura sia disponibile. Pertanto, le istanze database di scrittura non possono entrare in pausa finché non vengono sospese anche tutte le istanze di lettura. La ripresa di qualsiasi istanza di lettura riattiva automaticamente l’istanza di scrittura, anche se l’applicazione non accede direttamente a quest’ultima.

  • Le istanze di lettura Aurora Serverless v2 nei livelli di promozione del failover zero e uno vengono scalate per sincronizzare la loro capacità con l’istanza di scrittura. Pertanto, quando un’istanza di scrittura Aurora Serverless v2 si riattiva, riprendono anche tutte le istanze di lettura Aurora Serverless v2 incluse nei livelli di promozione del failover zero e uno.

Come funziona la pausa automatica Aurora Serverless v2 per i cluster Multi-AZ

All’interno di un cluster di database Aurora che contiene sia un’istanza di scrittura che una o più istanze database di lettura, potrebbero essere presenti istanze database Aurora Serverless v2 sia in pausa sia attive. L’istanza di scrittura e tutte le istanze di lettura con priorità di failover 0 e 1 vengono sempre messe in pausa e riattivate contemporaneamente. Le istanze di lettura con priorità diversa da 0 o 1 possono entrare in pausa e riattivate indipendentemente dalle altre istanze.

Quando si utilizza questa funzionalità in cluster con più istanze di lettura, è possibile contenere i costi senza sacrificare la disponibilità elevata. L’istanza di scrittura e una o due altre istanze di lettura possono rimanere sempre attive, mentre le istanze di lettura aggiuntive possono entrare in pausa quando non sono necessarie per gestire volumi di traffico di lettura elevati.

Un’istanza di lettura può entrare in pausa automaticamente se la sua capacità può essere scalata in modo indipendente; se invece è legata alla capacità dell’istanza database di scrittura, non è possibile applicare la funzionalità di pausa. Questa proprietà di dimensionamento dipende dalla priorità di failover dell’istanza database di lettura. Quando la priorità dell’istanza di lettura è zero o uno, la capacità dell’istanza di lettura monitora la capacità dell’istanza database di scrittura. Quindi, per consentire la messa in pausa automatica delle istanze database di lettura nella gamma di situazioni più ampia, impostarne la priorità su un valore superiore a uno.

Il tempo necessario per riprendere un’istanza di lettura potrebbe essere leggermente più lungo rispetto a un’istanza di scrittura. Per sapere il più rapidamente possibile se le istanze possono entrare in pausa, connettersi all’endpoint del cluster.

Come funziona la pausa automatica Aurora Serverless v2 per i cluster con istanze con provisioning

Tutte le istanze database con provisioning nel cluster di database Aurora non entrano in pausa automaticamente. Solo le istanze database Aurora Serverless v2, con la classe di istanza db.serverless, possono utilizzare la funzionalità di pausa automatica.

Quando il cluster Aurora contiene istanze database con provisioning, nessuna istanza di scrittura Aurora Serverless v2 entra in pausa automaticamente. Questo dipende dal requisito che prevede che l’istanza di scrittura sia sempre disponibile quando sono attive istanze di lettura. Il fatto che l’istanza di scrittura Aurora Serverless v2 resta attiva significa anche che tutte le istanze di lettura Aurora Serverless v2 con priorità di failover 0 e 1 non entreranno in pausa automaticamente in un cluster ibrido che contiene istanze con provisioning.

Monitoraggio dei cluster Aurora che utilizzano la pausa automatica

Per monitorare Aurora, è necessario conoscere già le procedure di monitoraggio in Monitoraggio dei parametri di Amazon Aurora con Amazon CloudWatch e le metriche CloudWatch elencate in Riferimento per i parametri per Amazon Aurora. È importante tenere presente alcune considerazioni specifiche quando si monitorano i cluster Aurora che utilizzano la funzionalità di pausa automatica:

  • Durante alcuni intervalli di tempo, le istanze Aurora Serverless v2 non registrano i dati di log e gran parte delle metriche perché sono in pausa. Le uniche metriche inviate a CloudWatch mentre un’istanza è in pausa sono zero percento per CPUUtilization e ACUUtilization e zero per ServerlessDatabaseCapacity.

  • È possibile verificare se le istanze Aurora Serverless v2 entrano in pausa più o meno spesso del previsto. A tale scopo, controllare la frequenza con cui la metrica ServerlessDatabaseCapacity passa da un valore diverso da zero a zero e per quanto tempo rimane zero. Se le istanze non restano in pausa per il tempo previsto, il risparmio sui costi effettivo sarà inferiore rispetto a quello potenziale. Se le istanze entrano in pausa e vengono riattivate più spesso del previsto, il cluster potrebbe presentare una latenza non necessaria nella risposta alle richieste di connessione. Per informazioni sui fattori che influiscono sulla possibilità e sulla frequenza con cui le istanze Aurora Serverless v2 possono entrare in pausa, consulta Prerequisiti e limitazioni per la funzionalità di pausa automatica Aurora Serverless v2, Situazioni in cui Aurora Serverless v2 non viene messo in pausa automaticamente e Risoluzione dei problemi relativi alla pausa automatica Aurora Serverless v2.

  • È anche possibile esaminare un file di log che registra le operazioni di pausa e ripresa automatiche per un’istanza Aurora Serverless v2. Se un’istanza non è stata sospesa alla scadenza dell’intervallo di timeout, nel file di log verrà riportato anche il motivo della mancata attivazione della pausa. Per ulteriori informazioni, consulta Monitoraggio delle attività di pausa e ripresa Aurora Serverless v2.

Verifica dello stato di pausa di un’istanza Aurora Serverless v2

Per determinare se un’istanza Aurora Serverless v2 è in stato di pausa, è possibile osservare la metrica ACUUtilization relativa all’istanza. Quando l’istanza è in pausa, il valore della metrica è zero.

Quando un’istanza Aurora Serverless v2 è in pausa, lo stato visualizzato sarà comunque Disponibile. Lo stesso vale per un’istanza Aurora Serverless v2 in pausa in fase di ripresa. Il motivo è che è comunque possibile connettersi correttamente a tale istanza, anche se la connessione subisce un leggero ritardo.

In qualsiasi metrica relativa alla disponibilità delle istanze Aurora, il periodo di pausa dell’istanza viene considerato un periodo di disponibilità.

Eventi per le operazioni di pausa e ripresa automatiche

Aurora emette eventi per le istanze Aurora Serverless v2 quando le operazioni di pausa e ripresa automatiche iniziano, terminano o vengono annullate. Gli eventi relativi alla funzionalità di pausa automatica da RDS-EVENT-0370 a RDS-EVENT-0374. Per dettagli su questi eventi, consultare Eventi di istanza database.

Come funziona la pausa automatica con Approfondimenti sulle prestazioni e Monitoraggio avanzato

Mentre un’istanza Aurora Serverless v2 è in pausa, Aurora non raccoglie informazioni di monitoraggio per quell’istanza tramite Approfondimenti sulle prestazioni o Monitoraggio avanzato. Quando l’istanza viene riattivata, potrebbe verificarsi un breve ritardo prima che Aurora riprenda a raccogliere le informazioni di monitoraggio.

In che modo la funzionalità di pausa automatica Aurora Serverless v2 interagisce con le metriche Aurora

Quando è in pausa, un’istanza Aurora Serverless v2 non emette gran parte delle metriche CloudWatch né scrive alcuna informazione nei log del database. Le uniche metriche inviate a CloudWatch mentre un’istanza è in pausa sono zero percento per CPUUtilization e ACUUtilization e zero per ServerlessDatabaseCapacity.

Quando CloudWatch elabora statistiche relative alla disponibilità e al tempo di attività dell’istanza o del cluster, le istanze Aurora Serverless v2 in pausa vengono considerate disponibili.

Quando si avvia un’azione dell’AWS CLI o dell’API RDS per descrivere o scaricare i log di un’istanza Aurora Serverless v2 in pausa, l’istanza riprende automaticamente per rendere disponibili le informazioni di log.

Esempio di metriche CloudWatch

Gli esempi seguenti relativi all’AWS CLI mostrano come osservare la modifica della capacità di un’istanza nel tempo. Durante l’intervallo di tempo, l’istanza viene messa in pausa e ripresa automaticamente. Mentre è in pausa, la metrica ServerlessDatabaseCapacity riporta un valore pari a zero. Per determinare se l’istanza è entrata in pausa in qualsiasi momento durante l’intervallo specificato, si può controllare se la capacità minima durante quel periodo di tempo era pari a zero.

Il seguente esempio di Linux rappresenta un’istanza Aurora Serverless v2 messa automaticamente in pausa per un certo periodo di tempo. Raccogliamo i valori ServerlessDatabaseCapacity ogni minuto, in un arco di tre minuti. Il valore ACU minimo di 0,0 conferma che l’istanza è entrata in pausa in un dato momento durante ogni minuto. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '3 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:11:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:12:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None

Successivamente, tentiamo di stabilire una connessione all’istanza Aurora Serverless v2 in pausa. In questo esempio, utilizziamo intenzionalmente una password errata in modo che il tentativo di connessione non abbia successo. Nonostante l’errore, il tentativo di connessione fa sì che Aurora riattivi l’istanza in pausa. 


$ mysql -h my_cluster_endpoint.rds.amazonaws.com -u admin -pwrong-password

ERROR 1045 (28000): Access denied for user 'admin'@'ip_address' (using password: YES)

Nel seguente esempio di Linux, l’istanza in pausa è stata riattivata, è rimasta inattiva per circa cinque minuti e poi è tornata allo stato di pausa. L’istanza si è riattivata con una capacità di 2,0 ACU. Quindi, ha mostrato un leggero aumento verticale, ad esempio per eseguire alcune operazioni di pulizia interna. Poiché non si è verificato alcun tentativo di connessione utente prima della scadenza del periodo di timeout di cinque minuti, l’istanza è passata direttamente da 4,0 ACU allo stato di pausa. 


$ aws cloudwatch get-metric-statistics \
  --metric-name "ServerlessDatabaseCapacity" \
  --start-time "$(date -d '8 minutes ago')" --end-time "$(date -d 'now')" --period 60 \
  --statistics Minimum \
  --namespace "AWS/RDS" --dimensions Name=DBInstanceIdentifier,Value=my-autopause-instance \
  --output text | sort -k 3

ServerlessDatabaseCapacity
DATAPOINTS	0.0	2024-08-02T22:13:00+00:00	None
DATAPOINTS	2.0	2024-08-02T22:14:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:15:00+00:00	None
DATAPOINTS	3.0	2024-08-02T22:16:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:17:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:18:00+00:00	None
DATAPOINTS	4.0	2024-08-02T22:19:00+00:00	None
DATAPOINTS	0.0	2024-08-02T22:20:00+00:00	None

Se lo scopo del report fosse di mostrare la velocità con cui l’istanza è aumenta verticalmente per gestire il carico di lavoro, potremmo specificare Maximum come statistica, invece di Minimum. Per la pianificazione della capacità e la stima dei costi, potremmo specificare un periodo di tempo più lungo e utilizzare la statistica Average. In questo modo, potremmo determinare i valori di capacità tipici durante i periodi di alta attività, bassa attività e stato di pausa. Per esaminare il comportamento nei momenti specifici della messa in pausa e della ripresa, potremmo specificare un periodo pari a un secondo ed esaminare un intervallo di tempo più breve. I valori del timestamp nell’output, ad esempio 2024-08-02T22:13:00+00:00, mostrano il formato con cui specificare parametri precisi per le opzioni --start-time e --end-time.

Risoluzione dei problemi relativi alla pausa automatica Aurora Serverless v2

Se le istanze Aurora Serverless v2 non entrano in pausa quando previsto, verificare le seguenti possibili cause:

  • Verificare che la versione di Aurora in uso supporti una capacità minima di zero ACU. Per gli intervalli di capacità delle diverse versioni di Aurora, consulta Capacità di Aurora Serverless v2.

  • Verificare che il valore di capacità minima per il cluster sia impostato su zero ACU.

  • Verificare che l’istanza in questione stia effettivamente utilizzando la classe di istanza Aurora Serverless v2 db.serverless, non una delle classi di istanza con provisioning.

  • Verificare che il cluster non stia utilizzando funzionalità o impostazioni incompatibili di Prerequisiti e limitazioni per la funzionalità di pausa automatica Aurora Serverless v2.

  • Esaminare il file di log per controllare quando sono state messe in pausa o riprese le istanze Aurora Serverless v2 o quando Aurora non è stata in grado di mettere in pausa o riprendere un’istanza per qualche motivo. Per ulteriori informazioni, consulta Monitoraggio delle attività di pausa e ripresa Aurora Serverless v2.

  • Controllare se alcuni client o applicazioni mantengono le connessioni aperte per lunghi periodi di tempo. Controllare anche se le applicazioni che utilizzano l’API dati RDS o le funzioni Lambda inviano richieste frequenti che non consentono all’istanza di restare inattiva abbastanza a lungo da entrare in pausa. È possibile esaminare le metriche CloudWatch, ad esempio ConnectionAttempts e DatabaseConnections. Per ulteriori informazioni, consulta Parametri a livello di istanza per Amazon Aurora.

  • Se un’istanza di lettura non entra mai in pausa o se accade raramente, verificare la sua priorità di failover. Se l’istanza di lettura viene utilizzata per il dimensionamento della lettura e non come istanza di lettura in standby in caso di failover, impostarla su una priorità compresa tra 2 e 15.

  • Se l’istanza di scrittura non entra mai in pausa o se accade raramente, verificare come vengono utilizzate le istanze di lettura. L’istanza di scrittura può essere messa in pausa solo se l’intero cluster è inattivo, perché una connessione a qualsiasi istanza di lettura ne causa la ripresa.

  • Se l’applicazione riceve dei timeout durante le richieste di connessione quando le istanze Aurora Serverless v2 sono in fase di ripresa, valutare la possibilità di allungare l’intervallo di timeout utilizzato dal codice dell’applicazione o dal framework di database sottostante. Timeout di connessione più lunghi riducono la possibilità di errori di connessione durante la ripresa delle istanze Aurora Serverless v2. Tuttavia, i timeout più lunghi possono anche rallentare il rilevamento dei problemi di disponibilità nel cluster da parte dell’applicazione.

    In alternativa, valutare la possibilità di allungare l’intervallo della pausa automatica in modo che le applicazioni non incontrino spesso istanze in pausa.

    Se il comportamento della pausa automatica e la reattività del cluster per l’applicazione non sembrano avere una coerenza logica, il cluster potrebbe non essere un candidato adatto per l’utilizzo della funzionalità di pausa automatica.

  • Quando si prova a stimare per quanto tempo le istanze Aurora Serverless v2 restano in pausa, è importante tenere presente che esistono fattori che rendono difficile formulare previsioni precise.

    • Le istanze potrebbero riattivarsi regolarmente per eseguire operazioni di manutenzione, aggiornamenti a versioni secondarie o modifiche ai gruppi di parametri.

    • Nei cluster Multi-AZ, a volte la ripresa di un’istanza causa anche la riattivazione di altre istanze. La ripresa di un’istanza di lettura riattiva sempre anche l’istanza di scrittura. La ripresa dell’istanza di scrittura comporta sempre la ripresa di tutte le istanze di lettura con priorità di failover 0 e 1.

    Consigliamo di misurare il tempo di pausa effettivo in un periodo di diversi giorni, con un carico di lavoro realistico. Queste misurazioni possono poi essere utilizzate per determinare un valore base per il tempo di pausa previsto di un’istanza.

  • Si potrebbe rilevare che le operazioni interne, come l’eliminazione MySQL, la pianificazione di eventi MySQL, l’autovacuum PostgreSQL o i processi PostgreSQL pianificati tramite l’estensione pg_cron, non sono in esecuzione o non vengono completate. L’istanza non si riattiva automaticamente per eseguire operazioni che non comportano una connessione utente al database. Se tali operazioni interne sono in corso alla scadenza del timeout della pausa automatica, le attività di manutenzione come l’eliminazione MySQL e l’autovacuum PostgreSQL vengono annullati. Anche i processi programmati dalla pianificazione di eventi MySQL o dall’estensione pg_cron PostgreSQL vengono annullati se sono in corso quando Aurora avvia l’operazione di pausa.

    Per garantire che l’istanza sia periodicamente attiva per eseguire le operazioni pianificate, è possibile avviare una connessione per riprendere l’istanza prima dell’inizio del processo. L’intervallo di timeout della pausa automatica può anche essere aumentato per prolungare le operazioni come l’autovacuum una volta che l’attività dell’utente è terminata. È inoltre possibile utilizzare meccanismi come le funzioni Lambda per eseguire le operazioni del database in base a una pianificazione, in modo da riattivare automaticamente l’istanza quando necessario.

Considerazioni sulla progettazione delle applicazioni per la funzionalità di pausa automatica Aurora Serverless v2

Quando un’istanza database Aurora Serverless v2 riprende dopo essere entrata in pausa automaticamente, inizia con una capacità relativamente bassa, quindi aumenta verticalmente. Questa capacità iniziale si applica anche se, subito prima della pausa automatica, l’istanza database aveva una capacità maggiore.

Utilizzare questa funzionalità con applicazioni che possono tollerare un intervallo di circa 15 secondi quando si stabilisce una connessione. Si tratta di un tipico caso in cui un’istanza Aurora Serverless v2 viene riattivata a causa di una o di poche connessioni in ingresso. Se l’istanza entra in pausa per più di 24 ore, il tempo di ripresa potrebbe essere più lungo.

Se l’applicazione utilizzava già Aurora Serverless v1 e la relativa funzionalità di pausa automatica, gli intervalli di timeout potrebbero essere già impostati per i tentativi di connessione. Se Aurora Serverless v2 è già utilizzato in combinazione con la funzionalità di arresto/avvio del cluster Aurora, il tempo di ripresa per le istanze Aurora Serverless v2 con pausa automatica è in genere molto più breve rispetto a quello necessario per avviare un cluster arrestato.

Quando si codifica la logica di connessione nell’applicazione, riprovare la connessione se il primo tentativo restituisce un errore che ha una causa temporanea. (Se l’errore riguarda l’autenticazione, correggere le credenziali prima di riprovare). Un errore che si verifica immediatamente dopo la ripresa potrebbe riguardare un timeout o i limiti del database. Un nuovo tentativo può risolvere i casi, più rari, in cui la ripresa di un’istanza Aurora Serverless v2 è dovuta a un numero elevato di richieste di connessione simultanee. In questo caso, l’elaborazione di alcune connessioni potrebbe richiedere più tempo del previsto o superare il limite di connessioni simultanee durante il primo tentativo.

Durante lo sviluppo e il debug delle applicazioni, non lasciare le sessioni client o gli strumenti di programmazione con connessioni aperte al database. Aurora non metterà in pausa un’istanza se sono aperte connessioni avviate dall’utente, anche se le connessioni non eseguono istruzioni o transazioni SQL. Quando un’istanza Aurora Serverless v2 in un cluster Aurora non può entrare in pausa, è possibile che anche altre istanze del cluster non vengano sospese. Per ulteriori informazioni, consulta Situazioni in cui Aurora Serverless v2 non viene messo in pausa automaticamente.

Aurora emette eventi quando un’istanza database Aurora Serverless v2 inizia e termina la ripresa e se l’istanza non riesce a riattivarsi per qualche motivo. Per dettagli su questi eventi, consultare Eventi di istanza database.