Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Preferenze
Contattaci
Feedback
AWS Documentation
Crea un Account AWS
Ridimensionamento a zero ACUs 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 del cluster Aurora Monitoraggio della pausa automatica Risoluzione dei problemi relativi alla pausa automatica Progettazione dell'applicazione 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à.

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

Ridimensionamento a zero ACUs con pausa e ripresa automatiche per Aurora Serverless v2

PDFRSS

Puoi specificarlo Aurora Serverless v2 Le istanze DB si ridimensionano fino a zero ACUs e si mettono automaticamente in pausa, se non hanno connessioni avviate dall'attività dell'utente entro un periodo di tempo specificato. A tale scopo, è necessario specificare un ACU valore minimo pari a zero per il cluster DB. Non ti viene addebitato alcun costo per la capacità dell'istanza mentre un'istanza è in pausa. L'attivazione della funzionalità di pausa e ripresa automatica (pausa automatica) per i cluster Aurora poco utilizzati o con lunghi periodi di inattività può aiutarti a gestire i costi per il tuo parco di database.

Nota

La funzione di pausa automatica è disponibile per Aurora Serverless v2 sia con Aurora SQL Postgre che Aurora My. SQL Potrebbe essere necessario aggiornare la versione del motore di database Aurora per sfruttare questa funzionalità. Per le versioni del motore in cui ACUs è disponibile una capacità minima di 0, vedereAurora Serverless v2 capacità.

Panoramica del Aurora Serverless v2 funzione di pausa automatica

Aurora Serverless v2 Le istanze DB possono interrompersi automaticamente dopo un periodo senza connessioni utente e riprendere automaticamente quando arriva una richiesta di connessione. Il Aurora Serverless v2 la funzione di pausa/ripresa automatica aiuta a gestire i costi per i sistemi che non hanno un obiettivo di livello di servizio rigoroso (). SLO 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 durante la ripresa del database. Se il tuo carico di lavoro ha periodi di inattività e può tollerare lievi ritardi nella connessione mentre l'istanza riprende, prendi in considerazione l'utilizzo della pausa automatica con Aurora Serverless v2 istanze per ridurre i costi.

È possibile controllare questo comportamento specificando se Aurora Serverless v2 Le istanze DB in un cluster possono essere messe in pausa automaticamente o meno e per quanto tempo ciascuna istanza deve rimanere inattiva prima di mettersi in pausa. Per abilitare il comportamento di pausa automatica per tutti i Aurora Serverless v2 Per le istanze DB in un cluster Aurora, si imposta il valore di capacità minima per il cluster su zero. ACUs

Se in precedenza hai usufruito del Aurora Serverless v1 funzionalità che è stata ridimensionata a zero ACUs dopo un periodo di inattività, è possibile eseguire l'aggiornamento a Aurora Serverless v2 e usa la funzione di pausa automatica corrispondente.

I vantaggi in termini di risparmio dei costi della funzione di pausa automatica sono simili all'utilizzo della funzionalità stop/start del cluster. Pausa automatica per Aurora Serverless v2 offre i vantaggi aggiuntivi di una ripresa più rapida rispetto all'avvio di un cluster interrotto e di automatizzare il processo di determinazione del momento in cui mettere in pausa e riprendere ciascuna istanza DB.

La funzione di pausa automatica fornisce inoltre una maggiore granularità nel controllo dei costi per le risorse di elaborazione all'interno del cluster. È possibile attivare la pausa di alcune istanze di lettura anche se l'istanza Writer e gli altri lettori del cluster rimangono attivi in qualsiasi momento. A tale scopo, assegnate alle istanze di lettura che possono essere messe in pausa indipendentemente dalle altre istanze una priorità di failover compresa tra 2 e 15.

Le istanze Writer e tutte le istanze Reader con priorità di failover 0 e 1 vengono sempre messe in pausa e riprendono contemporaneamente. Pertanto, le istanze di questo gruppo vengono messe in pausa dopo che nessuna di esse ha avuto alcuna connessione per l'intervallo di tempo specificato.

I cluster Aurora DB possono contenere una combinazione di istanze DB writer e reader e sono predisposti e Aurora Serverless v2 Istanze DB. Pertanto, per utilizzare questa funzionalità in modo efficace, è utile comprendere i seguenti aspetti del meccanismo di pausa automatica:

  • Le circostanze in cui un'istanza DB potrebbe interrompersi automaticamente.

  • Quando è possibile impedire la pausa di un'istanza DB. Ad esempio, l'abilitazione di alcune funzionalità di Aurora o l'esecuzione di determinati tipi di operazioni sul cluster potrebbe impedire la sospensione delle istanze, anche senza alcuna connessione a tali istanze.

  • Le conseguenze per il monitoraggio e la fatturazione mentre un'istanza è in pausa.

  • Quali azioni fanno sì che un'istanza DB riprenda l'elaborazione.

  • Come cambia la capacità di un'istanza DB nel momento in cui si verificano gli eventi di pausa e ripresa.

  • Come controllare l'intervallo di inattività prima della pausa di un'istanza DB.

  • Come codificare la logica dell'applicazione per gestire il periodo mentre un'istanza DB riprende l'elaborazione.

Prerequisiti e limitazioni per Aurora Serverless v2 funzione di pausa automatica

Prima di utilizzare la funzione di pausa automatica, controlla quali versioni del motore utilizzare. Inoltre, verifica se la pausa automatica funziona in combinazione con le altre funzionalità di Aurora che intendi utilizzare. Non puoi attivare la pausa automatica se utilizzi una versione del motore che non la supporta. Per le funzionalità incompatibili, non riceverai alcun errore se le utilizzi in combinazione con la pausa automatica. Se il cluster utilizza funzionalità o impostazioni incompatibili, Aurora Serverless v2 le istanze non verranno messe in pausa automaticamente.

Alcune condizioni o impostazioni impediscono Aurora Serverless v2 le istanze si interrompano automaticamente. Per ulteriori informazioni, consulta Situazioni in cui Aurora Serverless v2 non si mette in pausa automaticamente.

Attivazione e disattivazione della funzione di pausa automatica

Puoi attivare e disattivare la funzione di pausa automatica a livello di cluster. A tale scopo, si utilizzano le stesse procedure utilizzate per regolare la capacità minima e massima del cluster. La funzione di pausa automatica è rappresentata da una capacità minima di 0. ACUs

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

Segui la procedura riportata in Impostazione del Aurora Serverless v2 intervallo di capacità per un cluster. Per la capacità minima, scegli 0. ACUs Quando scegli una capacità minima pari a 0ACUs, puoi anche specificare il periodo di inattività dell'istanza prima che venga messa automaticamente in pausa.

L'CLIesempio 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'CLIesempio 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 (3600 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
}

Configurabile Aurora Serverless v2 intervallo di timeout di pausa automatica

L'intervallo di timeout è rappresentato nell'ServerlessV2ScalingConfigurationattributo del cluster Aurora. È possibile specificare questo intervallo AWS Management Console durante la creazione o la modifica di un cluster Aurora, se la capacità minima è impostata su zero. ACUs È possibile specificarlo AWS CLI utilizzando il --serverless-v2-scaling-configuration parametro durante la creazione o la modifica di un cluster Aurora. È possibile specificarlo RDS API utilizzando il ServerlessV2ScalingConfiguration parametro durante la creazione o la modifica di un cluster Aurora.

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

Si supponga di disattivare la funzionalità di pausa automatica per un cluster modificando 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 funzione di pausa automatica è disattivata per quel cluster. Se successivamente riattivi la pausa automatica, puoi specificare nuovamente qualsiasi intervallo personalizzato in quel momento.

Ripresa di una pausa automatica Aurora Serverless v2 istanza

  • Quando ti connetti a un'unità in pausa Aurora Serverless v2 istanza, riprende e accetta automaticamente la connessione.

  • Un tentativo di connessione che non include credenziali valide causa comunque la ripresa dell'istanza DB.

  • Se ti connetti tramite l'endpoint writer, Aurora riprende l'istanza Writer DB se viene messa in pausa automaticamente. 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 ti connetti tramite l'endpoint del lettore, Aurora sceglie un'istanza del lettore in modo casuale. Se l'istanza del lettore è in pausa, Aurora la riprende. Aurora riprende inoltre per prima l'istanza writer, poiché l'istanza writer deve essere sempre attiva se sono attive delle istanze Reader. Quando Aurora riprende l'istanza Writer, vengono ripristinate anche tutte le istanze Reader nei livelli di promozione di failover zero e uno.

  • Se invii una richiesta al tuo cluster tramite RDS DataAPI, Aurora riprende l'istanza writer se è in pausa. Quindi Aurora elabora la richiesta di datiAPI.

  • Quando si modifica il valore di un parametro di configurazione in un gruppo di parametri del cluster DB, Aurora riprende automaticamente qualsiasi parametro in pausa Aurora Serverless v2 istanze in tutti i cluster che utilizzano quel gruppo di parametri del cluster. Allo stesso modo, quando modificate il valore di un parametro in un gruppo di parametri DB, Aurora riprende automaticamente qualsiasi valore in pausa Aurora Serverless v2 istanze che utilizzano quel gruppo di parametri DB. Lo stesso comportamento di ripristino automatico 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 DB diverso.

  • L'esecuzione di una richiesta di backtrack riprende automaticamente il Aurora Serverless v2 istanza writer se è in pausa. Aurora elabora la richiesta di backtrack dopo la ripresa dell'istanza writer. È possibile tornare indietro a un periodo in cui un Aurora Serverless v2 l'istanza è stata messa in pausa.

  • L'acquisizione di un'istantanea del cluster o l'eliminazione di un'istantanea non ne causa alcuna Aurora Serverless v2 istanze da riprendere.

  • La creazione di un clone di Aurora fa sì che Aurora riprenda l'istanza writer del cluster che viene clonato.

  • Se un'istanza in pausa riceve un gran numero di richieste di connessione prima del termine della ripresa, alcune sessioni potrebbero non riuscire a connettersi. Si consiglia di implementare la logica di ripetizione per le connessioni ai cluster Aurora che ne hanno Aurora Serverless v2 istanze con pausa automatica abilitata. Ad esempio, è possibile riprovare una connessione fallita tre volte.

  • Aurora può eseguire alcuni tipi di manutenzione interna minore senza riattivare un'istanza. Tuttavia, alcuni tipi di manutenzione che avvengono durante la finestra di manutenzione del cluster richiedono che Aurora riprenda l'istanza. Al termine della manutenzione, l'istanza viene nuovamente messa in pausa automaticamente se non c'è più attività dopo l'intervallo specificato.

    Nota

    Aurora non riprende automaticamente un'istanza in pausa per i lavori pianificati specifici del motore, come quelli dell'estensione Postgre o SQL pg_cron dello scheduler My event. SQL Per garantire l'esecuzione di tali lavori, avvia manualmente una connessione all'istanza prima dell'orario pianificato. Aurora non mette in coda alcun lavoro in cui si verifica l'ora pianificata mentre l'istanza DB è in pausa. Tali processi vengono saltati quando l'istanza viene riavviata in un secondo momento.

  • Se il cluster Aurora viene sottoposto a un failover durante un Aurora Serverless v2 l'istanza viene messa in pausa automaticamente, Aurora potrebbe riprendere un'istanza e quindi promuovere quell'istanza come scrittrice. Lo stesso potrebbe accadere se una o più istanze DB vengono rimosse dal cluster mentre un'istanza è in pausa. In questo caso, l'istanza diventa l'autore immediatamente quando viene ripresa.

  • Le operazioni che modificano le proprietà del cluster causano anche eventuali pause automatiche Aurora Serverless v2 istanze da riprendere. Ad esempio, un'istanza in pausa automatica riprende per operazioni come le seguenti:

    • Modifica dell'intervallo di scalabilità del cluster.

    • Aggiornamento della versione del motore del cluster.

    • Descrizione o download di file di registro da un'istanza in pausa. È possibile esaminare i dati di registro storici delle istanze in pausa abilitando i caricamenti dei log CloudWatch e analizzando i log. CloudWatch

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

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

L'CLIesempio seguente mostra come disattivare la funzionalità di pausa automatica per un cluster Aurora esistente. L'describe-db-clustersoutput mostra che l'SecondsUntilAutoPauseattributo 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
}

In che modo Aurora Serverless v2 la funzione di pausa automatica funziona

Puoi utilizzare le seguenti informazioni per pianificare l'utilizzo della funzione di pausa automatica. Comprendere le circostanze in cui le istanze si interrompono, riprendono o rimangono attive può aiutarti a bilanciare i compromessi tra disponibilità, reattività e risparmio sui costi.

Cosa succede quando Aurora Serverless v2 le istanze si interrompono

Quando un Aurora Serverless v2 L'istanza DB si interrompe dopo un periodo senza connessioni:

  • Aurora inizia a mettere in pausa l'istanza dopo lo scadere dell'intervallo specificato senza alcuna connessione all'istanza, indipendentemente dal numero ACUs di istanze presenti in quel momento.

  • Il meccanismo di pausa non è istantaneo. Un record Aurora Serverless v2 un'istanza che sta per essere messa in pausa automaticamente potrebbe attendere brevemente per recuperare il ritardo con tutte le modifiche allo storage Aurora.

  • I costi di istanza relativi a quell'istanza vengono sospesi. La ServerlessV2Usage metrica ha un valore pari a 0 mentre l'istanza è in pausa.

  • Il valore di stato dell'istanza non cambia. Lo stato viene comunque visualizzato come «disponibile».

  • L'istanza interrompe la scrittura nei file di registro del database. Smette di inviare metriche a CloudWatch, ad eccezione della registrazione dello zero percento per CPUUtilization e ACUUtilization dello zero per. ServerlessDatabaseCapacity

  • Aurora emette eventi quando un Aurora Serverless v2 L'istanza DB inizia la pausa, termina la pausa e se il meccanismo di pausa viene interrotto o non funziona correttamente. Per informazioni dettagliate su questi eventi, consulta. Eventi di istanza database

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

Quando un Aurora Serverless v2 L'istanza DB riprende dopo essere stata messa in pausa automaticamente, si applicano le seguenti condizioni:

  • Tutte le modifiche ai parametri incluse nelle pending-reboot modifiche vengono applicate alla ripresa dell'istanza.

  • Aurora emette eventi a livello di istanza ogni volta che Aurora Serverless v2 L'istanza DB inizia a riprendere, termina la ripresa e se l'istanza non riesce a riprendere per qualche motivo. Per informazioni dettagliate su questi eventi, consulta. Eventi di istanza database

  • Tutte le connessioni richieste vengono stabilite al termine della ripresa dell'istanza DB. Poiché il tempo di ripristino tipico potrebbe essere di circa 15 secondi, consigliamo di regolare le impostazioni di timeout del client in modo che superino i 15 secondi. Ad esempio, nelle impostazioni del JDBC driver puoi regolare i valori per le sslResponseTimeout impostazioni connectTimeout e in modo che siano più lunghi di 15 secondi.

Nota

Se un Aurora Serverless v2 l'istanza rimane in pausa per più di 24 ore, Aurora può mettere l'istanza in uno stato di sonno più profondo che richiede più tempo per riprendere. In tal caso, il tempo di ripristino può essere di 30 secondi o più, all'incirca equivalente al riavvio dell'istanza. Se il database presenta periodi di inattività che durano più di un giorno, consigliamo di impostare i timeout di connessione su almeno 30 secondi.

Come funziona la fatturazione delle istanze per le istanze in pausa automatica Aurora Serverless v2 cluster

Mentre un Aurora Serverless v2 l'istanza viene messa in pausa automaticamente, il costo dell'istanza è zero. La ServerlessV2Usage metrica è zero durante quel periodo. AWS addebita ancora lo storage Aurora e altri aspetti del cluster che non sono legati a quella specifica istanza DB.

Situazioni in cui Aurora Serverless v2 non si mette in pausa automaticamente

  • Se il valore di capacità minima per il cluster DB è superiore a zeroACUs, Aurora Serverless v2 le istanze nel cluster non vengono messe in pausa automaticamente. Se disponi di cluster esistenti con Aurora Serverless v2 nelle istanze precedenti alla disponibilità della funzione di pausa automatica, l'impostazione della capacità minima minima era 0,5. ACUs Per utilizzare la funzione di pausa automatica con tali cluster, modifica l'impostazione della capacità minima su zero. ACUs

  • Se alcune connessioni avviate dall'utente sono aperte a Aurora Serverless v2 istanza, l'istanza non verrà messa in pausa. Inoltre, l'istanza non si interromperà mentre sono in corso attività come l'applicazione di patch e gli aggiornamenti. Le connessioni amministrative utilizzate da Aurora per i controlli di integrità non vengono conteggiate come attività e non impediscono la sospensione dell'istanza.

  • In un cluster Aurora Postgre con replica logica abilitata o in un SQL cluster Aurora My SQL con replica binlog abilitata, l'istanza writer e tutte le istanze di lettura nei livelli di promozione del failover zero e uno non vengono messe in pausa automaticamente. Aurora esegue una quantità minima costante di attività per verificare lo stato della connessione di replica.

    Per i cluster con replica abilitata, puoi comunque avere istanze di lettore Aurora nel cluster di origine che si interrompono automaticamente. A tale scopo, imposta la loro priorità di failover su un valore diverso da zero o uno. In questo modo, possono essere messi in pausa indipendentemente dall'istanza di writer.

  • Se al cluster Aurora è associato un RDS proxy, il proxy mantiene una connessione aperta a ogni istanza DB del cluster. Quindi, qualsiasi Aurora Serverless v2 le istanze in tale cluster non si interromperanno automaticamente.

  • Se il cluster è il cluster principale di un database globale di Aurora, Aurora non sospende automaticamente il Aurora Serverless v2 istanza writer. Questo perché è necessario un livello costante di attività sull'istanza writer per gestire gli altri cluster nel database globale. Poiché l'istanza writer rimane attiva, qualsiasi Aurora Serverless v2 inoltre, le istanze di lettura con priorità di failover zero o uno non vengono messe in pausa automaticamente.

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

  • In un cluster a cui è associata un'ETLintegrazione zero con Redshift, l'istanza writer e tutte le istanze Reader nei livelli di promozione del failover zero e uno non vengono messe in pausa automaticamente.

  • Oltre all'attività sulla porta del database principale dell'istanza, se un'istanza di Aurora Postgre ha la funzionalità Babelfish abilitata, qualsiasi connessione e attività sulla SQL porta T impedisce che l'SQListanza venga messa in pausa automatica.

Come funziona la pausa automatica con la funzione di stop/start del cluster

Puoi arrestare e avviare un cluster Aurora quando la funzione di pausa automatica è abilitata. Non importa se alcune istanze vengono messe in pausa. Quando riavvii il cluster, qualsiasi elemento viene messo in pausa Aurora Serverless v2 le istanze vengono ripristinate automaticamente.

Mentre un cluster Aurora è fermo, qualsiasi cluster viene messo in pausa Aurora Serverless v2 le istanze non vengono riattivate automaticamente in base ai tentativi di connessione. Una volta riavviato il cluster, i soliti meccanismi di pausa e ripresa Aurora Serverless v2 si applicano le istanze.

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

  • Mentre un Aurora Serverless v2 l'istanza viene messa in pausa automaticamente, se si tenta di aggiornare il cluster Aurora, Aurora riprende l'istanza e la aggiorna.

  • Aurora riprende periodicamente qualsiasi pausa automatica Aurora Serverless v2 istanze per eseguire la manutenzione, ad esempio aggiornamenti di versioni minori e modifiche alle proprietà, ad esempio i gruppi di parametri.

  • Dopo un Aurora Serverless v2 l'istanza si riattiva per un'operazione amministrativa come un aggiornamento o l'applicazione della manutenzione, Aurora attende almeno 20 minuti prima di sospendere nuovamente l'istanza. Questo per consentire il completamento di qualsiasi operazione in background. Il periodo di venti minuti evita inoltre di sospendere e riprendere l'istanza più volte se l'istanza viene sottoposta a più operazioni amministrative in successione.

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

  • Il tempo di ripresa è migliorato in Aurora Serverless v2 rispetto a Aurora Serverless v1. Il tempo di ripresa è in genere di circa 15 secondi se l'istanza è stata messa in pausa per meno di 24 ore. Se l'istanza viene messa in pausa per più di 24 ore, il tempo di ripresa potrebbe essere più lungo.

  • Il modo in cui Aurora Serverless v2 se si applica ai cluster Multi-AZ, significa che alcune istanze DB nel cluster potrebbero essere messe in pausa mentre altre sono attive. L'istanza writer riprende ogni volta che un lettore è in esecuzione, perché lo writer è necessario per coordinare determinate attività all'interno del cluster. Perché Aurora Serverless v1 non utilizza istanze di lettura, l'intero cluster sarebbe sempre in pausa o attivo.

  • Quando l'endpoint reader sceglie casualmente un'istanza del lettore a cui connettersi, quell'istanza del lettore potrebbe essere già attiva o potrebbe essere messa in pausa automaticamente. Pertanto, il tempo necessario per accedere all'istanza del lettore potrebbe variare ed essere più difficile da prevedere. 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 del lettore.

  • Aurora Serverless v2 le istanze vengono sottoposte a operazioni di manutenzione con la stessa frequenza delle istanze fornite. Poiché Aurora riprende automaticamente le istanze in cui è necessaria tale manutenzione, potresti scoprire che Aurora Serverless v2 le istanze vengono riattivate più frequentemente di Aurora Serverless v1 i cluster lo hanno fatto.

In che modo Aurora Serverless v2 la pausa automatica funziona per 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 Reader e dal fatto che tutte le istanze siano Aurora Serverless v2 o una combinazione di Aurora Serverless v2 e fornito.

Quando la funzione di pausa automatica è abilitata, puoi organizzare il cluster Aurora per ottenere il giusto equilibrio tra alta disponibilità, risposta rapida e scalabilità in base al tuo caso d'uso. Puoi farlo scegliendo la combinazione di Aurora Serverless v2 istanze, istanze assegnate e livelli di promozione del failover per le istanze DB del cluster.

I seguenti tipi di configurazioni dimostrano diversi compromessi tra alta disponibilità e ottimizzazione dei costi per il cluster:

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

  • Per un sistema che esegue un'applicazione in cui l'alta disponibilità è una priorità, ma il cluster presenta ancora periodi in cui è completamente inattivo, puoi configurare un cluster Multi-AZ in cui si trovano sia le istanze DB di scrittura che quelle di lettura Aurora Serverless v2. Imposta l'istanza del lettore sulla priorità di failover zero o uno, in modo che l'istanza writer e l'istanza reader vengano messe in pausa e riprendano contemporaneamente. Ora ottieni 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 DB per entrambe le istanze vengono sospesi. Quando il cluster riprende l'elaborazione, la prima sessione del database impiega un breve periodo 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, puoi creare un cluster con più di uno Aurora Serverless v2 istanza reader e disaccoppia le capacità di alcune istanze Reader da quelle di chi scrive. Specificate la priorità di failover zero o una per l'istanza writer e un'istanza reader. Specificate una priorità maggiore di una per le altre istanze del lettore. In questo modo, le istanze di lettura nei livelli di priorità più alta possono essere messe in pausa automaticamente, anche mentre lo scrittore e uno dei lettori rimangono attivi.

    In questo caso, puoi utilizzare altre tecniche per garantire che il cluster rimanga sempre disponibile pur continuando a ridurlo a una capacità ridotta durante i periodi di inattività:

    • È possibile utilizzare le istanze assegnate allo scrittore e al lettore con priorità 0 o 1. In questo modo, due istanze DB non vengono mai messe in pausa automatica e sono sempre disponibili per servire il traffico del database ed eseguire failover.

    • È possibile configurare un endpoint personalizzato che includa Aurora Serverless v2 istanze nei livelli di priorità più elevati, ma non lo scrittore o i lettori di livello di promozione 0 o 1. In questo modo, puoi indirizzare sessioni di sola lettura che non sono sensibili alla latenza ai lettori che potrebbero essere messe in pausa automaticamente. È possibile evitare di utilizzare l'endpoint reader per tali richieste, poiché Aurora potrebbe indirizzare le connessioni dell'endpoint reader all'istanza del lettore always-awake 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 capacità di scalabilità aggiuntiva.

In che modo Aurora Serverless v2 la pausa automatica funziona per l'istanza writer in un cluster DB

Quando un cluster Aurora DB contiene solo una singola istanza DB, il meccanismo per mettere in pausa e riprendere automaticamente l'istanza DB è semplice. Dipende solo dall'attività sull'istanza writer. Potresti avere una configurazione di questo tipo per i cluster utilizzati per lo sviluppo e il test o per l'esecuzione di applicazioni in cui l'elevata disponibilità non è fondamentale. Nota che in un cluster a istanza singola, Aurora indirizza le connessioni attraverso l'endpoint reader all'istanza Writer DB. Pertanto, per un cluster DB a istanza singola, il tentativo di connettersi all'endpoint del lettore causa la ripresa dell'istanza DB writer messa in pausa automaticamente.

I seguenti fattori aggiuntivi si applicano ai cluster Aurora con più istanze DB:

  • All'interno di un cluster Aurora DB, in genere si accede frequentemente all'istanza Writer DB. Pertanto, è possibile che l'istanza Writer DB rimanga attiva anche mentre una o più istanze DB Reader si interrompe automaticamente.

  • Alcune attività sulle istanze Reader DB richiedono che l'istanza DB Writer sia disponibile. Pertanto, le istanze DB di Writer non possono essere messe in pausa finché non vengono messe in pausa anche tutte le istanze di Reader. La ripresa di qualsiasi istanza di reader riattiva automaticamente l'istanza di writer, anche se l'applicazione non accede direttamente all'istanza writer.

  • Aurora Serverless v2 le istanze reader in fase di promozione con failover hanno un livello zero e uno scalabile per mantenere la loro capacità sincronizzata con l'istanza writer. Quindi, quando un Aurora Serverless v2 l'istanza dello scrittore riprende, così come qualsiasi altra Aurora Serverless v2 istanze reader che rientrano nei livelli di promozione zero o uno.

In che modo Aurora Serverless v2 la pausa automatica funziona per i cluster Multi-AZ

All'interno di un cluster Aurora DB contenente sia un writer che una o più istanze DB reader, alcune Aurora Serverless v2 Le istanze DB potrebbero essere messe in pausa mentre altre istanze DB sono attive. L'istanza writer e tutte le istanze di lettura con priorità di failover 0 e 1 vengono sempre messe in pausa e riprendono tutte contemporaneamente. Le istanze Reader con priorità diversa da 0 o 1 possono essere messe in pausa e riprendere indipendentemente dalle altre istanze.

Quando utilizzi questa funzionalità per cluster con più istanze Reader, puoi gestire i costi senza sacrificare l'elevata disponibilità. L'istanza writer e un'altra istanza di lettura di una o due istanze possono rimanere sempre attive, mentre le istanze di lettura aggiuntive possono essere messe in pausa quando non sono necessarie per gestire volumi di traffico di lettura elevati.

La possibilità di mettere in pausa automaticamente un'istanza reader dipende dal fatto che la sua capacità sia scalabile indipendentemente o dal fatto che la capacità sia legata a quella dell'istanza Writer DB. Questa proprietà di scalabilità dipende dalla priorità di failover dell'istanza DB del lettore. Quando la priorità del lettore è zero o uno, la capacità del lettore tiene traccia della capacità dell'istanza DB di scrittura. Pertanto, per consentire alle istanze DB Reader di interrompersi automaticamente nella più ampia gamma di situazioni, impostate la loro priorità su un valore superiore a uno.

Il tempo necessario per riprendere un'istanza Reader potrebbe essere leggermente più lungo rispetto a quello necessario per riprendere un'istanza Writer. Per una risposta più rapida in caso di interruzione delle istanze, connettiti all'endpoint del cluster.

In che modo Aurora Serverless v2 la pausa automatica funziona per i cluster con istanze assegnate

Qualsiasi istanza DB fornita nel cluster Aurora DB non verrà messa in pausa automaticamente. Solo Aurora Serverless v2 Le istanze DB, con la classe db.serverless instance, possono utilizzare la funzione di pausa automatica.

Quando il cluster Aurora contiene istanze DB di cui è stato effettuato il provisioning, qualsiasi Aurora Serverless v2 l'istanza writer non viene messa in pausa automaticamente. Ciò è dovuto al requisito che l'istanza writer rimanga disponibile mentre tutte le istanze di Reader sono attive. Il fatto che Aurora Serverless v2 lo scrittore rimane attivo significa anche che qualsiasi Aurora Serverless v2 le istanze reader con priorità di failover 0 e 1 non verranno messe in pausa automaticamente in un cluster ibrido contenente istanze di cui è stato eseguito il provisioning.

Monitoraggio dei cluster Aurora che utilizzano la pausa automatica

Per monitorare Aurora, è necessario conoscere già le procedure di monitoraggio Monitoraggio dei parametri di Amazon Aurora con Amazon CloudWatch e le CloudWatch metriche elencate in. Riferimento alle metriche per Tieni presente che ci sono alcune considerazioni speciali quando monitori i cluster Aurora che utilizzano la funzione di pausa automatica:

  • Possono esserci periodi di tempo in cui Aurora Serverless v2 le istanze non registrano i dati di registro e la maggior parte delle metriche perché le istanze sono in pausa. Le uniche metriche inviate CloudWatch mentre un'istanza è in pausa sono lo zero percento per e e lo zero perCPUUtilization. ACUUtilization ServerlessDatabaseCapacity

  • Puoi verificare se Aurora Serverless v2 le istanze si interrompono più o meno frequentemente del previsto. A tale scopo, controlla la frequenza con cui la ServerlessDatabaseCapacity metrica passa da un valore diverso da zero a zero e per quanto tempo rimane zero. Se le istanze non rimangono in pausa per tutto il tempo previsto, non risparmierai quanto potresti sui costi. Se le istanze vengono messe in pausa e riprendono più frequentemente del previsto, il cluster potrebbe avere una latenza non necessaria nel rispondere alle richieste di connessione. Per informazioni sui fattori che influiscono sulla frequenza e sulla frequenza Aurora Serverless v2 le istanze possono mettere in pausa, vedere Prerequisiti e limitazioni per Aurora Serverless v2 funzione di pausa automaticaSituazioni in cui Aurora Serverless v2 non si mette in pausa automaticamente, e. Risoluzione dei problemi per Aurora Serverless v2 pausa automatica

  • È inoltre possibile esaminare un file di registro che registra le operazioni automatiche di pausa e ripresa per un Aurora Serverless v2 istanza. Se un'istanza non si è messa in pausa dopo la scadenza dell'intervallo di timeout, questo file di registro include anche il motivo per cui la pausa automatica non è avvenuta. Per ulteriori informazioni, consulta Monitoraggio Aurora Serverless v2 mettere in pausa e riprendere l'attività.

Verifica se un Aurora Serverless v2 l'istanza è in pausa

Per determinare se un Aurora Serverless v2 l'istanza è in stato di pausa, puoi osservare la ACUUtilization metrica dell'istanza. Tale metrica ha un valore pari a zero mentre l'istanza è in pausa.

Mentre un Aurora Serverless v2 l'istanza è in pausa, il suo valore di stato è ancora indicato come Disponibile. Lo stesso vale quando è in pausa Aurora Serverless v2 l'istanza è in fase di ripresa. Questo perché puoi connetterti correttamente a tale istanza, anche se la connessione presenta un leggero ritardo.

Qualsiasi metrica relativa alla disponibilità delle istanze Aurora considera il periodo in cui l'istanza è in pausa come il periodo in cui l'istanza era disponibile.

Eventi per le operazioni di pausa e ripresa automatica

Aurora emette eventi per Aurora Serverless v2 istanze in cui le operazioni di pausa e ripresa automatica iniziano, terminano o vengono annullate. Gli eventi relativi alla funzione di pausa automatica sono RDS-EVENT-0370 terminati. RDS-EVENT-0374 Per informazioni dettagliate su questi eventi, vedere. Eventi di istanza database

Come funziona la pausa automatica con Performance Insights e Enhanced Monitoring

Mentre un Aurora Serverless v2 l'istanza è in pausa, Aurora non raccoglie informazioni di monitoraggio per quell'istanza tramite Performance Insights o Enhanced Monitoring. Quando l'istanza viene ripresa, potrebbe verificarsi un breve ritardo prima che Aurora riprenda a raccogliere tali informazioni di monitoraggio.

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

Mentre un Aurora Serverless v2 l'istanza è in pausa, non emette la maggior parte delle CloudWatch metriche né scrive alcuna informazione nei registri del database. Le uniche metriche inviate CloudWatch mentre un'istanza è in pausa sono lo zero percento per e e lo zero perCPUUtilization. ACUUtilization ServerlessDatabaseCapacity

Quando CloudWatch le statistiche di calcolo riguardano la disponibilità e l'operatività dell'istanza o del cluster, Aurora Serverless v2 le istanze sono considerate disponibili durante il periodo di pausa.

Quando si avvia un'RDSAPIazione AWS CLI o per descrivere o scaricare i log per una pausa Aurora Serverless v2 istanza, l'istanza viene riattivata automaticamente per rendere disponibili le informazioni di registro.

Esempio di metriche CloudWatch

AWS CLI Gli esempi seguenti mostrano come è possibile osservare la variazione della capacità di un'istanza nel tempo. Durante il periodo di tempo, l'istanza si interrompe automaticamente e poi riprende. Mentre è in pausa, la ServerlessDatabaseCapacity metrica riporta un valore pari a zero. Per determinare se l'istanza è stata messa in pausa in qualsiasi momento durante il periodo di tempo, controlliamo se la capacità minima durante quel periodo di tempo era pari a zero.

Il seguente esempio di Linux rappresenta un Aurora Serverless v2 istanza che è stata messa automaticamente in pausa per qualche tempo. Li campioniamo ServerlessDatabaseCapacity ogni minuto, per un periodo di tre minuti. Il ACU valore minimo di 0,0 conferma che l'istanza è stata messa in pausa a un certo punto 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'elemento in pausa Aurora Serverless v2 istanza. 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 riprenda 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)

Il seguente esempio di Linux dimostra che l'istanza in pausa è stata ripresa, è rimasta inattiva per circa cinque minuti e poi è tornata allo stato di pausa. L'istanza è ripresa con una capacità di 2.0. ACUs Quindi si è leggermente ridimensionata, ad esempio per eseguire alcune operazioni di pulizia interna. Poiché non ha ricevuto alcun tentativo di connessione utente entro il periodo di timeout di cinque minuti, è passato dalla versione 4.0 ACUs direttamente 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 il rapporto avesse lo scopo di mostrare la velocità con cui l'istanza si è scalata per gestire il carico di lavoro, potremmo specificare Maximum la statistica anziché. 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 durante gli orari precisi di pausa e ripresa, potremmo specificare un periodo di un secondo ed esaminare un intervallo di tempo più breve. I valori del timestamp nell'output, ad esempio2024-08-02T22:13:00+00:00, mostrano il formato per specificare parametri precisi per le opzioni and. --start-time --end-time

Risoluzione dei problemi per Aurora Serverless v2 pausa automatica

Se lo trovi Aurora Serverless v2 le istanze non si interrompono tutte le volte che ti aspetti, verifica le seguenti possibili cause:

  • Verifica che la versione di Aurora in esecuzione supporti una capacità minima pari a zero. ACUs Per le gamme di capacità delle diverse versioni di Aurora, vedere. Aurora Serverless v2 capacità

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

  • Verifica che l'istanza in questione stia effettivamente utilizzando il Aurora Serverless v2 classe di istanzadb.serverless, non una delle classi di istanze fornite.

  • Verifica che il cluster non stia utilizzando nessuna delle funzionalità o impostazioni incompatibili di. Prerequisiti e limitazioni per Aurora Serverless v2 funzione di pausa automatica

  • Esamina il file di registro che mostra quando Aurora Serverless v2 le istanze sono state messe in pausa, riprese o Aurora non è stata in grado di mettere in pausa o riprendere un'istanza per qualche motivo. Per ulteriori informazioni, consulta Monitoraggio Aurora Serverless v2 mettere in pausa e riprendere l'attività.

  • Controlla se alcuni client o applicazioni mantengono le connessioni aperte per lunghi periodi di tempo. Al contrario, controlla se le applicazioni che utilizzano le funzioni RDS Data API o Lambda inviano richieste frequenti in modo che l'istanza non rimanga mai inattiva abbastanza a lungo da poter essere messa in pausa. Puoi esaminare CloudWatch metriche come e. ConnectionAttempts DatabaseConnections Per ulteriori informazioni, consulta Parametri a livello di istanza per Amazon Aurora.

  • Se un'istanza Reader si interrompe raramente, se non mai, verificate la sua priorità di failover. Se il lettore viene utilizzato per il ridimensionamento della lettura e non come standby in caso di failover, impostatelo su una priorità compresa tra 2 e 15.

  • Se l'istanza Writer si interrompe raramente, se non mai, verificate l'utilizzo delle istanze Reader. Lo scrittore può mettersi in pausa solo se l'intero cluster è inattivo. Questo perché una connessione a qualsiasi istanza del lettore fa sì che lo scrittore riprenda.

  • Se l'applicazione riceve dei timeout durante le richieste di connessione mentre Aurora Serverless v2 le istanze sono in fase di ripresa, valuta 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 connessioni non riuscite mentre Aurora Serverless v2 le istanze stanno riprendendo. Tuttavia, i timeout più lunghi possono anche rallentare l'individuazione di problemi di disponibilità nel cluster da parte dell'applicazione.

    Al contrario, valuta la possibilità di allungare l'intervallo di pausa automatica in modo che le applicazioni non incontrino istanze in pausa con la stessa frequenza.

    Se non esiste un equilibrio logico tra il comportamento di pausa automatica e la reattività del cluster per l'applicazione, quel cluster potrebbe non essere un buon candidato per l'utilizzo della funzionalità di pausa automatica.

  • Se stimate per quanto tempo Aurora Serverless v2 i casi verranno messi in pausa, tieni presente che ci sono fattori che rendono poco pratico fare previsioni precise.

    • Le istanze potrebbero riprendere periodicamente per eseguire operazioni di manutenzione, aggiornamenti di versioni minori o applicare modifiche ai gruppi di parametri.

    • Per i cluster Multi-AZ, ci sono situazioni in cui la ripresa di un'istanza causa il ripristino anche di altre istanze. La ripresa di un lettore fa sempre sì che lo scrittore riprenda. La ripresa del writer fa sì che tutti i lettori con priorità di failover 0 e 1 riprendano sempre.

    Consigliamo di misurare il tempo di pausa effettivo su un periodo di diversi giorni, con un carico di lavoro realistico. Utilizza quindi queste misurazioni per impostare una linea di base per la percentuale di tempo che puoi aspettarti che un'istanza venga messa in pausa.

  • Potresti scoprire che le operazioni interne come My SQL purge, My SQL event scheduler, Postgre SQL autovacuum o Postgre SQL job programmati tramite l'estensione non sono in esecuzione o non vengono completate. pg_cron L'istanza non riprende automaticamente a eseguire tali operazioni che non comportano una connessione utente al database. Se tali operazioni interne sono in corso alla scadenza del timeout di pausa automatica, le attività di manutenzione come My SQL purge e Postgre autovacuum vengono annullate. SQL I lavori pianificati dall'utilità di pianificazione dei miei SQL eventi o dall'SQLpg_cronestensione Postgre vengono annullati anche se sono in corso quando Aurora avvia l'operazione di pausa.

    Se devi assicurarti che l'istanza sia periodicamente attiva per eseguire operazioni pianificate, puoi avviare una connessione per riprendere l'istanza prima dell'inizio del processo. Puoi anche aumentare l'intervallo di timeout della pausa automatica in modo che operazioni come l'autovacuum possano essere eseguite più a lungo dopo 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 se necessario.

Considerazioni sulla progettazione delle applicazioni per Aurora Serverless v2 funzione di pausa automatica

Quando un Aurora Serverless v2 L'istanza DB riprende dopo essere stata messa in pausa automaticamente, inizia con una capacità relativamente piccola e da lì si espande verso l'alto. Questa capacità iniziale si applica anche se l'istanza DB aveva una capacità maggiore immediatamente prima di essere messa in pausa automaticamente.

Utilizzate questa funzionalità con applicazioni che possono tollerare un intervallo di circa 15 secondi durante la creazione di una connessione. Ciò rappresenta il caso tipico in cui un Aurora Serverless v2 l'istanza viene ripresa a causa di una o un numero limitato di connessioni in entrata. Se l'istanza viene messa in pausa per più di 24 ore, il tempo di ripresa potrebbe essere più lungo.

Se l'applicazione era già in uso Aurora Serverless v1 e la sua funzione di pausa automatica, è possibile che questi intervalli di timeout siano già in vigore per i tentativi di connessione. Se lo stai già utilizzando Aurora Serverless v2 in combinazione con la funzione Aurora stop/start cluster, il tempo di ripresa per la pausa automatica Aurora Serverless v2 le istanze sono in genere molto più brevi del tempo necessario per avviare un cluster interrotto.

Quando codifichi la logica di connessione nell'applicazione, riprova la connessione se il primo tentativo restituisce un errore che ha una causa temporanea. (Se l'errore è dovuto a un errore di autenticazione, correggete le credenziali prima di riprovare.) Un errore che si verifica immediatamente dopo la ripresa potrebbe essere un timeout o un errore relativo ai limiti del database. Un nuovo tentativo può risolvere i problemi nei casi più rari in cui Aurora Serverless v2 l'istanza viene ripresa a causa di un numero elevato di richieste di connessione simultanee. In tal caso, l'elaborazione di alcune connessioni potrebbe richiedere più tempo del normale o superare il limite di connessioni simultanee al primo tentativo.

Durante lo sviluppo e il debug delle applicazioni, non lasciate 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, indipendentemente dal fatto che le connessioni non eseguano istruzioni o transazioni. SQL Quando uno Aurora Serverless v2 l'istanza in un cluster Aurora non può essere messa in pausa, inoltre potrebbe essere impedita la sospensione di altre istanze del cluster. Per ulteriori informazioni, consulta Situazioni in cui Aurora Serverless v2 non si mette in pausa automaticamente.

Aurora emette eventi quando un Aurora Serverless v2 L'istanza DB inizia a riprendere, termina la ripresa e se l'istanza non riesce a riprendere per qualche motivo. Per informazioni dettagliate su questi eventi, consulta. Eventi di istanza database

Hai bisogno di aiuto?

PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.