Funzionamento di Aurora Serverless v1

Di seguito è descritto il funzionamento di Aurora Serverless v1.

Architettura di Aurora Serverless v1

L'immagine seguente mostra una panoramica dell'architettura di Aurora Serverless v1.

Anziché effettuare il provisioning e gestire i server di database, puoi specificare le unità di capacità di Aurora (ACU). Ogni ACU è una combinazione di circa 2 gigabyte (GB) di memoria, CPU corrispondente e rete. Lo storage del database esegue automaticamente il dimensionamento da 10 gibibyte (GiB) a 128 tebibytes (TiB), lo stesso storage di un cluster di database Aurora standard.

Puoi specificare l'ACU minima e massima. L'unità di capacità Aurora minima è l'ACU più bassa a cui un cluster di database può essere ridotto. L'unità di capacità Aurora massima è l'ACU più alta a cui un cluster di database può essere aumentato. In base alle impostazioni, Aurora Serverless v1 crea automaticamente regole di dimensionamento basate sulle soglie per utilizzo della CPU, delle connessioni e di memoria disponibile.

Aurora Serverless v1 gestisce il pool di risorse nella Regione AWS per ridurre al minimo il tempo di dimensionamento. Quando Aurora Serverless v1 aggiunge nuove risorse al cluster di database Aurora, utilizza il parco istanze del router per passare le connessioni client attive alle nuove risorse. Paghi soltanto i costi delle ACU che vengono attivamente usate nel tuo cluster di database Aurora in un momento specifico.

Scalabilità automatica per Aurora Serverless v1

La capacità allocata al cluster di database Aurora Serverless v1 si ridimensiona senza problemi in base al carico generato dall'applicazione client. Qui, il carico è l'utilizzo della CPU e il numero di connessioni. Quando la capacità è vincolata da una di queste opzioni, Aurora Serverless v1 scala verso l'alto. Anche Aurora Serverless v1 scala verso l'alto quando rileva problemi di prestazioni che possono essere risolti in questo modo.

Puoi visualizzare gli eventi di ridimensionamento per il cluster Aurora Serverless v1 nel AWS Management Console . Durante il dimensionamento automatico, Aurora Serverless v1 reimposta il parametro EngineUptime. Il valore del parametro di reset non è indice di un problema con il dimensionamento né di un'interruzione della connessione da parte di Aurora Serverless v1. È semplicemente il punto di partenza per i tempi di attività della nuova capacità. Per maggiori informazioni sui parametri, consulta Monitoraggio dei parametri in un cluster di database Amazon Aurora.

Se il tuo cluster DB Aurora Serverless v1 non ha connessioni attive, può ridurre fino a zero capacità (0 ACU). Per ulteriori informazioni, vedi Sospendi e riprendi per Aurora Serverless v1.

Quando è necessario eseguire un'operazione di ridimensionamento, Aurora Serverless v1 prova prima a identificare un punto di dimensionamento, ovvero un momento in cui non vengono elaborate query. Aurora Serverless v1 potrebbe non riuscire a trovare un punto di dimensionamento per i seguenti motivi:

• Query di lunga durata

• Transazioni in corso

• Tabelle temporanee o blocchi di tabelle

Per aumentare il tasso di successo del cluster di database Aurora Serverless v1 quando si trova un punto di dimensionamento, si consiglia di evitare query e transazioni di lunga durata. Per ulteriori informazioni sulle operazioni che provocano il blocco del dimensionamento e su come evitarle, consulta Best practice per l'utilizzo di Aurora Serverless v1 .

Per impostazione predefinita, Aurora Serverless v1 prova a trovare un punto di dimensionamento per 5 minuti (300 secondi). Puoi specificare un periodo di timeout diverso quando crei o modifichi il cluster. Il periodo di timeout può essere compreso tra 60 secondi e 10 minuti (600 secondi). Se Aurora Serverless v1 non riesce a trovare un punto di dimensionamento entro il periodo specificato, l'operazione di scalabilità automatica raggiunge il timeout.

Per impostazione predefinita, se l'autoscaling non trova un punto di dimensionamento prima del timeout, Aurora Serverless v1 mantiene il cluster alla capacità corrente. Questo comportamento di default può essere modificato quando si crea o si modifica il cluster di database Aurora Serverless v1 selezionando l'opzione Force the capacity change (Forza la modifica della capacità). Per ulteriori informazioni, consulta Operazione di timeout per le modifiche di capacità.

Operazione di timeout per le modifiche di capacità

Se la scalabilità automatica raggiunge il timeout senza trovare un punto di dimensionamento, per impostazione predefinita Aurora mantiene la capacità corrente. Se desideri che Aurora forzi la modifica, abilita l'opzione Force the capacity change (Forza la modifica della capacità). Questa opzione è disponibile nella sezione Autoscaling timeout and action (Timeout e operazione di scalabilità automatica) della pagina Create database (Crea database) quando crei il cluster.

L'opzione Force the capacity change (Forza la modifica della capacità) è disabilitata di default. Lascia questa opzione deselezionata per evitare modifiche alla capacità del tuo cluster di database Aurora Serverless v1 nel caso in cui l'operazione di dimensionamento scada senza che sia stato trovato un punto di dimensionamento.

Se selezioni questa opzione, il cluster di database Aurora Serverless v1 applicherà la modifica della capacità anche senza un punto di dimensionamento. Prima di selezionare questa opzione, devi essere consapevole delle conseguenze che essa può avere:

• Tutte le transazioni in corso vengono interrotte e viene visualizzato il seguente messaggio di errore.

  Aurora MySQL versione 2 - ERRORE 1105 (HY000): L'ultima transazione è stata interrotta a causa del dimensionamento continuo. Riprova.

  Puoi inviare nuovamente la transazione non appena il cluster di database Aurora Serverless v1 diventa disponibile.

• Le connessioni a tabelle temporanee e ai blocchi vengono eliminate.

  Ti consigliamo di selezionare Force the capacity change (Forza la modifica della capacità) solo se è possibile recuperare l'applicazione in seguito a connessioni interrotte o transazioni incomplete.

Le selezioni che effettui nella AWS Management Console quando crei un cluster di database Aurora Serverless v1 sono archiviate nell'oggetto ScalingConfigurationInfo, in SecondsBeforeTimeout e nelle proprietà TimeoutAction. Quando si crea il cluster, il valore della proprietà TimeoutAction viene impostato su uno dei seguenti valori:

• RollbackCapacityChange: questo valore viene impostato quando selezioni l'opzione Roll back the capacity change (Eseguire il rollback della modifica della capacità). Questo è il comportamento che segue di default.

• ForceApplyCapacityChange: questo valore viene impostato quando selezioni l'opzione Force the capacity change (Forza la modifica della capacità).

È possibile ottenere il valore di questa proprietà su un cluster Aurora Serverless v1 DB esistente utilizzando il describe-db-clustersAWS CLIcomando, come illustrato di seguito.

Per LinuxmacOS, oUnix:

aws rds describe-db-clusters --region region \
  --db-cluster-identifier your-cluster-name \
  --query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

Per Windows:

aws rds describe-db-clusters --region region ^
  --db-cluster-identifier your-cluster-name ^
  --query "*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}"

Ad esempio, di seguito è riportata la query e la risposta per un cluster di database Aurora Serverless v1 denominato west-coast-sles nella Regione Stati Uniti occidentali (California settentrionale).

$ aws rds describe-db-clusters --region us-west-1 --db-cluster-identifier west-coast-sles 
--query '*[].{ScalingConfigurationInfo:ScalingConfigurationInfo}'

[
    {
        "ScalingConfigurationInfo": {
            "MinCapacity": 1,
            "MaxCapacity": 64,
            "AutoPause": false,
            "SecondsBeforeTimeout": 300,
            "SecondsUntilAutoPause": 300,
            "TimeoutAction": "RollbackCapacityChange"
        }
    }
]

Come mostra la risposta, questo cluster di database Aurora Serverless v1 utilizza l'impostazione predefinita.

Per ulteriori informazioni, consulta Creazione di un cluster di database Aurora Serverless v1. Dopo aver creato il Aurora Serverless v1, potrai inoltre modificare l'azione di timeout e altre impostazioni della capacità in qualsiasi momento. Per scoprire come, consulta Modifica di un cluster di database Aurora Serverless v1.

Sospendi e riprendi per Aurora Serverless v1

Puoi scegliere di mettere in pausa il cluster di database Aurora Serverless v1 dopo un determinato periodo di tempo in cui non è stata registrata alcuna attività. Specifica il periodo di tempo in cui non viene registrata alcuna attività prima che il cluster di database venga messo in pausa. Quando si seleziona questa opzione, il tempo di inattività predefinito è di cinque minuti, ma è possibile modificare questo valore. Questa è un'impostazione facoltativa.

Quando il cluster di database viene messo in pausa, non avvengono attività di elaborazione o memoria e vengono addebitati soltanto i costi per lo storage. Se vengono richieste connessioni al database quando un cluster di database Aurora Serverless v1 è messo in pausa, il cluster di database si riavvia automaticamente e adempie alle richieste di connessione.

Quando il cluster di database riprende l'attività, ha la stessa capacità che aveva quando Aurora ha messo in pausa il cluster. Il numero di ACU dipende dalla scalabilità del cluster Aurora verso l'alto o verso il basso prima di essere messo in pausa.

Nota

Se un cluster di database viene messo in pausa per oltre sette giorni potrebbe essere sottoposto a backup con uno snapshot. In questo caso, Aurora ripristina il cluster di database dalla snapshot quando viene avanzata una richiesta di connessione.

Determinazione del numero massimo di connessioni di database per Aurora Serverless v1

Gli esempi seguenti sono per un cluster di database Aurora Serverless v1 compatibile con MySQL 5.7. Puoi utilizzare un client MySQL o l'editor di query, se è stato configurato l'accesso. Per ulteriori informazioni, consulta Esecuzione di query nell'editor della query.

Trovare il numero massimo di connessioni al database

1. Trova l'intervallo di capacità per il cluster di database Aurora Serverless v1 tramite la AWS CLI.

   aws rds describe-db-clusters \
       --db-cluster-identifier my-serverless-57-cluster \
       --query 'DBClusters[*].ScalingConfigurationInfo|[0]'

   Il risultato mostra che il suo intervallo di capacità è di 1-4 ACU.

   {
       "MinCapacity": 1,
       "AutoPause": true,
       "MaxCapacity": 4,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

2. Esegui la seguente query SQL per trovare il numero massimo di connessioni.

   select @@max_connections;

   Il risultato mostrato è per la capacità minima del cluster, 1 ACU.

   @@max_connections
   90

3. Dimensiona il cluster su 8-32 ACU.

   Per ulteriori informazioni sul dimensionamento, consultare Modifica di un cluster di database Aurora Serverless v1.

4. Conferma l'intervallo di capacità.

   {
       "MinCapacity": 8,
       "AutoPause": true,
       "MaxCapacity": 32,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

5. Trova il numero massimo di connessioni.

   select @@max_connections;

   Il risultato mostrato è per la capacità minima del cluster, 8 ACU.

   @@max_connections
   1000

6. Ridimensiona il cluster al massimo possibile, 256–256 ACU.

7. Conferma l'intervallo di capacità.

   {
       "MinCapacity": 256,
       "AutoPause": true,
       "MaxCapacity": 256,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

8. Trova il numero massimo di connessioni.

   select @@max_connections;

   Il risultato mostrato è per 256 ACU.

   @@max_connections
   6000

   Nota

   Il valore max_connections non viene dimensionato linearmente con il numero di ACU.

9. Ripristina le dimensioni del cluster a 1-4 ACU.

   {
       "MinCapacity": 1,
       "AutoPause": true,
       "MaxCapacity": 4,
       "TimeoutAction": "RollbackCapacityChange",
       "SecondsUntilAutoPause": 3600
   }

   Questa volta, il valore max_connections è per 4 ACU.

   @@max_connections
   270

10. Consenti una riduzione del cluster a 2 ACU.

    @@max_connections
    180

    Se il cluster è stato configurato per essere sospeso dopo un certo periodo di tempo di inattività, viene ridotto fino a 0 ACU. Tuttavia, max_connections non scende sotto il valore per 1 ACU.

    @@max_connections
    90

Gruppi di parametri per Aurora Serverless v1

Quando crei il tuo cluster di database Aurora Serverless v1, è possibile scegliere un motore del database Aurora specifico e un gruppo di parametri del cluster di database associato. A differenza di cluster di database Aurora con provisioning, un cluster di database Aurora Serverless v1 ha una singola istanza database di lettura/scrittura configurata solo con un gruppo di parametri del cluster di database—, non ha un gruppo di parametri database separato. Durante la scalabilità automatica, Aurora Serverless v1 deve essere in grado di modificare i parametri affinché il cluster funzioni al meglio per aumentare o diminuire la capacità. Così, con un cluster di database Aurora Serverless v1, alcune delle modifiche apportate ai parametri per un particolare tipo di motore del database potrebbero non essere applicabili.

Ad esempio, un cluster di database basato su Aurora PostgreSQL – Aurora Serverless v1 non può utilizzare apg_plan_mgmt.capture_plan_baselines e altri parametri che potrebbero essere utilizzati in cluster di database Aurora PostgreSQL con provisioning per la gestione del piano di query.

È possibile ottenere un elenco di valori predefiniti per i gruppi di parametri predefiniti per i vari motori Aurora DB utilizzando il comando CLI describe-engine-default-cluster-parameters e interrogando il. Regione AWS Di seguito sono riportati i valori che è possibile utilizzare per l'opzione --db-parameter-group-family.

Aurora MySQL versione 2	aurora-mysql5.7
Aurora PostgreSQL versione 11	aurora-postgresql11
Aurora PostgreSQL versione 13	aurora-postgresql13

Ti consigliamo di configurare la AWS CLI con il tuo ID chiave di accesso AWS e la chiave di accesso segreto AWS e di impostare la Regione AWS prima di utilizzare i comandi AWS CLI. Fornire la regione alla configurazione CLI consente di evitare di immettere il parametro --region l'esecuzione dei comandi. Per ulteriori informazioni sulla configurazione di AWS CLI, consulta Nozioni di base sulla configurazione nella Guida per l'utente di AWS Command Line Interface.

Nell'esempio seguente si recupera un elenco di parametri dal gruppo di cluster di database predefinito per Aurora MySQL versione 2.

PerLinux, o: macOS Unix

aws rds describe-engine-default-cluster-parameters \
  --db-parameter-group-family aurora-mysql5.7 --query \
  'EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, `serverless`) == `true`] | [*].{param:ParameterName}' \
  --output text

Per Windows:

aws rds describe-engine-default-cluster-parameters ^
   --db-parameter-group-family aurora-mysql5.7 --query ^
   "EngineDefaults.Parameters[*].{ParameterName:ParameterName,SupportedEngineModes:SupportedEngineModes} | [?contains(SupportedEngineModes, 'serverless') == `true`] | [*].{param:ParameterName}" ^
   --output text

Modifica dei valori dei parametri per Aurora Serverless v1

Come spiegato in , non è possibile modificare direttamente i valori in un gruppo di parametri predefinito, indipendentemente dal tipo (gruppo di parametri del cluster di database, gruppo di parametri DB). Al contrario, si crea un gruppo di parametri personalizzato basato sul gruppo di parametri cluster di database predefinito per il motore database Aurora e modificare le impostazioni in base alle esigenze su quel gruppo di parametri. Ad esempio, potresti voler modificare alcune impostazioni del tuo cluster Aurora Serverless v1 DB per registrare le query o caricare log specifici del motore DB su Amazon. CloudWatch

Per creare un gruppo di parametri del cluster di database personalizzato

1. Accedi alla AWS Management Console e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Scegliere Gruppi di parametri.

3. Seleziona Crea gruppo di parametri per aprire il riquadro dei dettagli del gruppo di parametri.

4. Seleziona il gruppo cluster di database predefinito appropriato per il motore database che desideri utilizzare per il cluster di databaseAurora Serverless v1. Assicurati di scegliere le seguenti opzioni:

   1. Per Famiglia gruppo parametri, seleziona la famiglia appropriata per il motore del database scelto. Assicurati che la selezione abbia un nome contenente il prefisso aurora-.

   2. Per Type (Tipo), scegli DB Cluster Parameter Group (Gruppo di parametri del cluster di database).

   3. Per Nome gruppo e Descrizione, specifica nomi significativi per l'utente o per altri utenti che potrebbero dover utilizzare il cluster di database Aurora Serverless v1 e i relativi parametri.

   4. Scegli Create (Crea).

Il gruppo di parametri del cluster di database personalizzato viene aggiunto all'elenco dei gruppi di parametri disponibili per l'account nella Regione AWS. Ora puoi utilizzare il gruppo di parametri del cluster di database personalizzato quando crei nuovi cluster di database Aurora Serverless v1. Puoi anche modificare un cluster di database Aurora Serverless v1 esistente per utilizzare il gruppo di parametri del cluster di database personalizzato. Una volta che il cluster di database Aurora Serverless v1 inizia a utilizzare il gruppo di parametri del cluster di database personalizzato, sarà possibile modificare i valori per i parametri dinamici utilizzando la AWS Management Console o il AWS CLI.

Puoi anche utilizzare la console per visualizzare un side-by-side confronto tra i valori del tuo gruppo di parametri del cluster DB personalizzato rispetto al gruppo di parametri del cluster DB predefinito, come mostrato nella schermata seguente.

Quando modifichi i valori dei parametri in un cluster di database attivo, Aurora Serverless v1 avvia il dimensionamento senza interruzioni per applicare le modifiche ai parametri. Se il tuo cluster di database Aurora Serverless v1 è in pausa, riprende l'attività e inizia il dimensionamento in modo che possa apportare la modifica. L'operazione di dimensionamento per la modifica di un gruppo di parametri forza sempre la modifica della capacità, quindi tieni presente che la modifica dei parametri potrebbe comportare la perdita di connessioni se non è possibile trovare un punto di dimensionamento durante il periodo di dimensionamento.

Registrazione per Aurora Serverless v1

Per impostazione predefinita, i log degli errori di Aurora Serverless v1 sono abilitati e caricati automaticamente su Amazon CloudWatch. Puoi anche fare in modo che il cluster Aurora Serverless v1 DB carichi i log specifici del motore di database Aurora su. CloudWatch Per fare ciò, abilita i parametri di configurazione nel gruppo di parametri del cluster di database personalizzati. Il tuo cluster Aurora Serverless v1 DB carica quindi tutti i log disponibili su Amazon. CloudWatch A questo punto, puoi utilizzarli CloudWatch per analizzare i dati di registro, creare allarmi e visualizzare le metriche.

Per Aurora MySQL, la tabella seguente mostra i log che è possibile abilitare. Se abilitati, vengono caricati automaticamente dal tuo cluster Aurora Serverless v1 DB su Amazon CloudWatch.

Log Aurora MySQL	Descrizione
general_log	Crea il log generale. Imposta su 1 per attivare questa opzione. Il valore predefinito è disattivato (0).
log_queries_not_using_indexes	Registra tutte le query nel log delle query lente che non utilizzano un indice. Il valore predefinito è disattivato (0). Imposta su 1 per attivare questo log.
long_query_time	Impedisce che le query in esecuzione rapida vengano registrate nel log delle query lente. Può essere impostato su un valore variabile compreso tra 0 e 31.536.000. Il valore predefinito è 0 (non attivo).
server_audit_events	L'elenco degli eventi da catturare nei log. I valori supportati sono CONNECT, QUERY, QUERY_DCL, QUERY_DDL, QUERY_DML e TABLE.
server_audit_logging	Imposta su 1 per attivare la registrazione di controllo del server. Se attivi questa opzione, puoi specificare gli eventi di controllo a cui inviare CloudWatch elencandoli nel server_audit_events parametro.
slow_query_log	Crea un log di query lente. Imposta su 1 per attivare il log di query lente. Il valore predefinito è disattivato (0).

Per ulteriori informazioni, consulta Utilizzo del controllo avanzato con un cluster Amazon Aurora My DB SQL.

Per Aurora PostgreSQL, la tabella seguente mostra i log che è possibile abilitare. Se abilitati, vengono caricati automaticamente dal tuo cluster Aurora Serverless v1 DB su Amazon CloudWatch insieme ai normali log degli errori.

Log Aurora PostgreSQL	Descrizione
log_connections	Attivato di default e non può essere modificato. Registra i dettagli per tutte le nuove connessioni client.
log_disconnections	Attivato di default e non può essere modificato. Registra tutte le disconnessioni client.
log_hostname	Sono disattivati per impostazione predefinita e non possono essere modificati. I nomi host non vengono registrati.
log_lock_waits	Il valore predefinito è 0 (disattivato). Imposta su 1 per registrare le attese di blocco.
log_min_duration_statement	La durata minima (in millisecondi) per l'esecuzione di un'istruzione prima della registrazione.
log_min_messages	Imposta i livelli dei messaggi che vengono registrati. I valori supportati sono debug5, debug4, debug3, debug2, debug1, info, notice, warning, error, log, fatal, panic. Per registrare i dati delle prestazioni nel log postgres, imposta il valore su debug1.
log_temp_files	Registra l'utilizzo di file temporanei che si trovano al di sopra dei kilobyte (kB) specificati.
log_statement	Controlla le istruzioni SQL specifiche che vengono registrate. I valori supportati sono none, ddl, mod e all. Il valore predefinito è none.

Dopo aver attivato i log per Aurora MySQL o Aurora Aurora Serverless v1 PostgreSQL per il cluster DB, puoi visualizzare i log in. CloudWatch

Visualizzazione dei Aurora Serverless v1 log con Amazon CloudWatch

Aurora Serverless v1carica automaticamente («pubblica») su Amazon CloudWatch tutti i log abilitati nel gruppo di parametri del cluster DB personalizzato. Non è necessario scegliere o specificare i tipi di log. Il caricamento dei log inizia non appena si attiva il parametro di configurazione log. Se in seguito questo parametro viene disattivato, gli altri caricamenti saranno interrotti. Tuttavia, tutti i log che sono già stati pubblicati CloudWatch rimarranno finché non li elimini.

Per ulteriori informazioni sull'utilizzo CloudWatch con i log MySQL di Aurora, consulta. Monitoraggio degli eventi di registro in Amazon CloudWatch

Per ulteriori informazioni su CloudWatch Aurora PostgreSQL, consulta. Pubblicazione dei log di Aurora Postgree su Amazon Logs SQL CloudWatch

Per visualizzare i log per il cluster di database Aurora Serverless v1

1. Apri la console all'indirizzo https://console.aws.amazon.com/cloudwatch/ CloudWatch .

2. Scegli il tuo Regione AWS.

3. Scegli Log groups (Gruppi di log).

4. Seleziona il log del cluster di database Aurora Serverless v1 dall'elenco. Per i log di errori, il modello di denominazione è il seguente.

   /aws/rds/cluster/cluster-name/error

Ad esempio, nello screenshot seguente sono riportati gli elenchi dei log pubblicati per un cluster di database Aurora Serverless v1 Aurora PostgreSQL denominato western-sles. Sono riportati anche diversi elenchi per il cluster di database Aurora Serverless v1 Aurora PostgreSQL denominato west-coast-sles. Seleziona il log desiderato per iniziare ad esplorarne il contenuto.

Aurora Serverless v1 e manutenzione

La manutenzione per un cluster di database Aurora Serverless v1, ad esempio l'applicazione delle funzionalità, correzioni e aggiornamenti di sicurezza più recenti, viene eseguita automaticamente. Aurora Serverless v1 ha una finestra di manutenzione che è possibile visualizzare nella AWS Management Console in Manutenzione e backup per il tuo cluster di database Aurora Serverless v1. È possibile trovare la data e l'ora in cui potrebbe essere eseguita la manutenzione e se è in corso una manutenzione per il cluster DB, come illustrato nella figura seguente. Aurora Serverless v1

Puoi impostare la finestra di manutenzione quando crei il cluster di database Aurora Serverless v1 e modificarla in un secondo momento. Per ulteriori informazioni, consulta Impostazione della finestra di manutenzione preferita del cluster database.

Le finestre di manutenzione vengono utilizzate per gli aggiornamenti programmati delle versioni principali. Gli aggiornamenti e le patch delle versioni minori vengono applicati immediatamente durante il ridimensionamento. Il ridimensionamento avviene in base alle impostazioni dell'utente per: TimeoutAction

• ForceApplyCapacityChange— La modifica viene applicata immediatamente.

• RollbackCapacityChange— Aurora aggiorna forzatamente il cluster dopo 3 giorni dal primo tentativo di patch.

Come per qualsiasi modifica forzata senza un punto di ridimensionamento appropriato, ciò potrebbe interrompere il carico di lavoro.

Quando possibile, Aurora Serverless v1 esegue la manutenzione in modalità non invasiva. Quando è necessaria la manutenzione, il cluster di database Aurora Serverless v1 dimensionerà automaticamente la propria capacità per gestire le operazioni necessarie. Prima di scalare, Aurora Serverless v1 cerca un punto di dimensionamento. Lo fa per un massimo di tre giorni, se necessario.

Alla fine di ogni giorno che Aurora Serverless v1 non riesce a trovare un punto di dimensionamento, viene creato un evento cluster. Questo evento notifica la manutenzione in sospeso e la necessità di eseguire il dimensionamento per eseguire la manutenzione. La notifica include la data in cui Aurora Serverless v1 può forzare il dimensionamento del cluster di database.

Per ulteriori informazioni, consulta Operazione di timeout per le modifiche di capacità.

Aurora Serverless v1 e failover

Se l'istanza database per un cluster di database Aurora Serverless v1 diventa non disponibile o la zona di disponibilità (AZ) restituisce un errore, Aurora crea nuovamente l'istanza database in una AZ diversa. Tuttavia, il cluster Aurora Serverless v1 non è un cluster Multi-AZ. Questo perché è costituito da una singola istanza database in un'unica zona di disponibiità. Perciò, questo meccanismo di failover richiede più tempo rispetto a un cluster Aurora con provisioning o alle istanze Aurora Serverless v2. Il tempo di failover per Aurora Serverless v1 è indefinito perché dipende dalla richiesta e dalla disponibilità di capacità in altre AZ nella Regione AWS specificata.

Poiché Aurora separa la capacità di calcolo e lo storage, il volume di storage per il cluster è suddiviso in più zone di disponibilità. I dati rimangono disponibili anche se un'interruzione riguarda l'istanza database o la zona di disponibilità associata.

Aurora Serverless v1 e snapshot

Il volume del cluster per un cluster Aurora Serverless v1 è sempre crittografato. Puoi scegliere la chiave di crittografia, ma non è possibile disabilitare la crittografia. Per copiare o condividere uno snapshot di un cluster Aurora Serverless v1, esegui la crittografia dello snapshot utilizzando la tua AWS KMS key. Per ulteriori informazioni, consulta Copia di snapshot del cluster DB. Per ulteriori informazioni sulla crittografia e Amazon Aurora, consulta Creazione di un cluster di database Amazon Aurora