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

In che modo Aurora Serverless v1 funzionamento

Di seguito, puoi scoprire come Aurora Serverless v1 funziona.

Aurora Serverless v1 architecture

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

Invece di effettuare il provisioning e gestire i server di database, si specificano le unità ACUs di capacità Aurora (). 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 tue impostazioni, Aurora Serverless v1 crea automaticamente regole di ridimensionamento per le soglie relative all'utilizzo della CPU, alle connessioni e alla memoria disponibile.

Aurora Serverless v1 gestisce il pool di risorse disponibili in modo da ridurre Regione AWS al minimo i tempi di scalabilità. Quando Aurora Serverless v1 aggiunge nuove risorse al cluster Aurora DB, utilizza la flotta di router per passare le connessioni client attive alle nuove risorse. In qualsiasi momento specifico, ti vengono addebitati solo i costi ACUs che vengono utilizzati attivamente nel tuo cluster Aurora DB.

Scalabilità automatica per Aurora Serverless v1

La capacità assegnata al tuo Aurora Serverless v1 Il cluster DB si ridimensiona facilmente verso l'alto e verso il basso in base al carico generato dall'applicazione client. Qui, il carico è l'utilizzo della CPU e il numero di connessioni. Quando la capacità è limitata da uno di questi fattori, Aurora Serverless v1 aumenta. Aurora Serverless v1 si espande inoltre quando rileva problemi di prestazioni che possono essere risolti in questo modo.

Puoi visualizzare gli eventi di scalabilità per i tuoi Aurora Serverless v1 cluster in. AWS Management Console Durante la scalabilità automatica, Aurora Serverless v1 ripristina la metrica. EngineUptime Il valore del valore della metrica di ripristino non significa che il ridimensionamento senza interruzioni abbia avuto problemi o altro Aurora Serverless v1 connessioni interrotte. È 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.

Quando il tuo Aurora Serverless v1 Il cluster DB non ha connessioni attive, può essere ridimensionato fino a una capacità zero (0 ACUs). Per ulteriori informazioni, consulta Metti in pausa e riprendi per Aurora Serverless v1.

Quando è necessario eseguire un'operazione di scalabilità, Aurora Serverless v1 cerca innanzitutto di identificare un punto di scala, un momento in cui non viene elaborata alcuna richiesta. Aurora Serverless v1 potrebbe non essere in grado di trovare un punto di scala per i seguenti motivi:

Per aumentare il tuo Aurora Serverless v1 La percentuale di successo del cluster DB nel trovare un punto di scalabilità, ti consigliamo di evitare query e transazioni di lunga durata. Per ulteriori informazioni sulle operazioni che bloccano la scalabilità e su come evitarle, consulta Best practice for working with Aurora Serverless v1.

Per impostazione predefinita, Aurora Serverless v1 tenta di trovare un punto di scala 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 scala entro il periodo specificato, l'operazione di scalabilità automatica scade.

Per impostazione predefinita, se la scalabilità automatica non trova un punto di scala prima del timeout, Aurora Serverless v1 mantiene il cluster alla capacità attuale. È possibile modificare questo comportamento predefinito quando si crea o si modifica il Aurora Serverless v1 Cluster DB selezionando l'opzione 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. Mantieni deselezionata questa opzione per avere la tua Aurora Serverless v1 La capacità del cluster DB rimane invariata se l'operazione di scalabilità scade senza trovare un punto di scalabilità.

La selezione di questa opzione causa Aurora Serverless v1 Cluster DB per imporre la modifica della capacità, anche senza un punto di scalabilità. Prima di selezionare questa opzione, devi essere consapevole delle conseguenze che essa può avere:

Le scelte che fai AWS Management Console quando crei un Aurora Serverless v1 I cluster DB sono archiviati nell'ScalingConfigurationInfooggetto, nelle TimeoutAction proprietà SecondsBeforeTimeout and. 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 una proprietà esistente Aurora Serverless v1 Cluster DB utilizzando il describe-db-clusters AWS CLI comando, come illustrato di seguito.

In Linux, macOS, oppure Unix:

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

In Windows:

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

A titolo di esempio, di seguito vengono illustrate la query e la risposta per un Aurora Serverless v1 Cluster DB 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 Aurora Serverless v1 Il cluster DB utilizza l'impostazione predefinita.

Per ulteriori informazioni, consulta Creare un Aurora Serverless v1 cluster di database. Dopo aver creato il tuo Aurora Serverless v1, puoi modificare l'azione di timeout e altre impostazioni di capacità in qualsiasi momento. Per scoprire come, consulta Modificare un Aurora Serverless v1 cluster di database.

Metti in pausa e riprendi per Aurora Serverless v1

Puoi scegliere di mettere in pausa il tuo Aurora Serverless v1 Cluster DB dopo un determinato periodo di tempo senza 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 Aurora Serverless v1 Il cluster DB è in pausa, il cluster DB riprende automaticamente e soddisfa le 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 ACUs dipende da quanto Aurora ha aumentato o ridotto il cluster prima di metterlo in pausa.

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

I seguenti esempi riguardano un Aurora Serverless v1 Cluster DB 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 Aurora Serverless v1 Cluster DB, scegli uno specifico motore Aurora DB e un gruppo di parametri del cluster DB associato. A differenza dei cluster Aurora DB forniti, un Aurora Serverless v1 Il cluster DB dispone di una singola istanza DB di lettura/scrittura configurata solo con un gruppo di parametri del cluster DB e non dispone di un gruppo di parametri DB separato. Durante la scalabilità automatica, Aurora Serverless v1 deve essere in grado di modificare i parametri affinché il cluster funzioni al meglio in caso di aumento o diminuzione della capacità. Quindi, con un Aurora Serverless v1 Cluster DB, alcune delle modifiche che potresti apportare ai parametri per un particolare tipo di motore DB potrebbero non essere applicabili.

Ad esempio, una versione Aurora basata su PostgreSQL Aurora Serverless v1 Il cluster DB non può utilizzare apg_plan_mgmt.capture_plan_baselines e altri parametri che potrebbero essere utilizzati sui cluster Aurora PostgreSQL DB forniti per la gestione dei piani 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 configurarlo AWS CLI con l'ID della chiave di AWS accesso e la chiave di accesso AWS segreta e di impostarlo prima di utilizzare i Regione AWS 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 AWS CLI, consulta Nozioni di base sulla configurazione nella Guida per l'AWS Command Line Interface utente.

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

In Linux, macOS, oppure 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

In 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 Aurora Serverless v1 Cluster 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. È possibile utilizzare il gruppo di parametri del cluster DB personalizzato quando si crea un nuovo Aurora Serverless v1 Cluster DB. È inoltre possibile modificare un file esistente Aurora Serverless v1 Cluster DB per utilizzare il gruppo di parametri del cluster DB personalizzato. Dopo il tuo Aurora Serverless v1 Il cluster DB inizia a utilizzare il gruppo di parametri del cluster DB personalizzato, è possibile modificare i valori per i parametri dinamici utilizzando il AWS Management Console o il AWS CLI.

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

Quando si modificano i valori dei parametri su un cluster DB attivo, Aurora Serverless v1 avvia una scala senza interruzioni per applicare le modifiche ai parametri. Se le ricette di Aurora Serverless v1 Il cluster DB è in uno stato di pausa, riprende e inizia a scalare in modo da poter 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 registri degli errori per Aurora Serverless v1 sono abilitati e caricati automaticamente su Amazon CloudWatch. Puoi anche avere il tuo Aurora Serverless v1 Il cluster DB carica 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 Aurora Serverless v1 Il cluster 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 Aurora Serverless v1 Cluster 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 Aurora Serverless v1 Cluster DB su Amazon CloudWatch insieme ai normali log degli errori.

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

Visualizzazione Aurora Serverless v1 registri con Amazon CloudWatch

Aurora Serverless v1 carica 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, vedere. Pubblicazione dei log di Aurora PostgreSQL su Amazon Logs CloudWatch

Ad esempio, nella schermata seguente è possibile trovare elenchi di log pubblicati per Aurora PostgreSQL Aurora Serverless v1 Cluster DB denominato. western-sles Puoi anche trovare diversi elenchi per Aurora MySQL Aurora Serverless v1 Cluster DB,. west-coast-sles Seleziona il log desiderato per iniziare ad esplorarne il contenuto.

Aurora Serverless v1 e manutenzione

Manutenzione per Aurora Serverless v1 Il cluster DB, ad esempio l'applicazione delle funzionalità, delle correzioni e degli aggiornamenti di sicurezza più recenti, viene eseguito automaticamente per te. Aurora Serverless v1 dispone di una finestra di manutenzione che puoi visualizzare AWS Management Console nella sezione Manutenzione e backup per il tuo Aurora Serverless v1 Cluster DB. Puoi trovare la data e l'ora in cui potrebbe essere eseguita la manutenzione e se ci sono interventi di manutenzione in sospeso per il tuo Aurora Serverless v1 Cluster DB, come illustrato nella figura seguente.

È possibile impostare la finestra di manutenzione quando si crea il Aurora Serverless v1 Cluster DB e puoi modificare la finestra 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 senza interruzioni. Quando è necessaria la manutenzione, il Aurora Serverless v1 Il cluster DB ridimensiona la propria capacità per gestire le operazioni necessarie. Prima della scalabilità, Aurora Serverless v1 cerca un punto di scala. Lo fa per un massimo di tre giorni, se necessario.

Alla fine di ogni giornata quello Aurora Serverless v1 non riesce a trovare un punto di scalabilità, crea un evento di 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 la scalabilità del cluster DB.

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

Aurora Serverless v1 e failover

Se l'istanza DB per un Aurora Serverless v1 Il cluster DB diventa non disponibile o la zona di disponibilità (AZ) in cui si trova fallisce, Aurora ricrea l'istanza DB in una zona di disponibilità diversa. Tuttavia, Aurora Serverless v1 il cluster non è un cluster Multi-AZ. Questo perché è costituito da una singola istanza database in un'unica zona di disponibiità. Pertanto, questo meccanismo di failover richiede più tempo rispetto a un cluster Aurora con provisioning o Aurora Serverless v2 istanze. Il Aurora Serverless v1 il tempo di failover non è definito perché dipende dalla domanda e dalla disponibilità di capacità in altri paesi AZs all'interno del dato dato. Regione AWS

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

Aurora Serverless v1 e istantanee

Il volume del cluster per un Aurora Serverless v1 il cluster è sempre crittografato. Puoi scegliere la chiave di crittografia, ma non puoi disabilitare la crittografia. Per copiare o condividere un'istantanea di un Aurora Serverless v1 cluster, crittografa l'istantanea usando 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