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

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:

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:

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:

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

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.

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.

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

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.

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.

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

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

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