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 v2

La seguente panoramica descrive il funzionamento di Aurora Serverless v2.

Panoramica di Aurora Serverless v2

Amazon Aurora Serverless v2 è adatto per i carichi di lavoro più impegnativi e altamente variabili. Ad esempio, l'uso del database potrebbe essere pesante per un breve periodo di tempo, seguito da lunghi periodi di attività leggera o nessuna attività. Alcuni esempi sono siti web per la vendita al dettaglio, i giochi o sportivi con eventi promozionali periodici e database in grado di generare report quando necessario. Altri sono ambienti di sviluppo e test e nuove applicazioni in cui l'utilizzo potrebbe aumentare rapidamente. In casi come questi e molti altri, non sempre è possibile configurare correttamente la capacità in anticipo con il modello fornito. Ciò può anche comportare costi più elevati se si esegue il provisioning eccessivo e si dispone di capacità che poi non viene utilizzata.

Al contrario, i cluster di Aurora con provisioning sono adatti per carichi di lavoro stabili. Con i cluster con provisioning, si sceglie una classe di istanza DB con una quantità predefinita di memoria, potenza della CPU, I/O larghezza di banda e così via. Se il carico di lavoro cambia, modifichi manualmente la classe di istanza dello scrittore e dei lettori. Il modello soggetto a provisioning funziona bene quando è possibile regolare la capacità in anticipo rispetto ai modelli di consumo previsti ed è accettabile soffrire di brevi interruzioni mentre si modifica la classe di istanza dello scrittore e dei lettori all'interno del cluster.

Aurora Serverless v2 è progettato da zero per supportare cluster di database serverless che risultino istantaneamente scalabili. Aurora Serverless v2 è progettato per garantire lo stesso grado di sicurezza e isolamento degli scrittori e dei lettori con provisioning. Questi aspetti sono cruciali negli ambienti cloud serverless multitenant. Il meccanismo di dimensionamento dinamico impone un overhead molto ridotto in modo da poter rispondere rapidamente alle modifiche del carico di lavoro del database. È anche abbastanza potente da soddisfare i considerevoli aumenti della domanda di elaborazione.

Utilizzando Aurora Serverless v2 puoi creare un cluster Aurora DB senza essere legato a una capacità di database specifica per ogni scrittore e lettore. Puoi specificare l'intervallo minimo e massimo per la capacità. Aurora bilancia ciascuno scrittore o lettore Aurora Serverless v2 nel cluster all'interno di tale intervallo di capacità. Utilizzando un cluster Multi-AZ in cui ogni scrittore o lettore può dimensionarsi dinamicamente puoi sfruttare la scalabilità dinamica e l'elevata disponibilità.

Aurora Serverless v2 dimensiona le risorse del database automaticamente in base alle specifiche di capacità minima e massima. La scalabilità è rapida perché la maggior parte delle operazioni legate agli eventi di dimensionamento mantiene lo scrittore o il lettore sullo stesso host. Nei rari casi in cui uno scrittore o un lettore Aurora Serverless v2 debbano essere spostati da un host all'altro, Aurora Serverless v2 gestisce automaticamente le connessioni. Non è necessario modificare il codice dell'applicazione client del database o le stringhe di connessione al database.

Con Aurora Serverless v2, come per i cluster con provisioning, la capacità di archiviazione e la capacità di calcolo sono indipendenti. Quando ci riferiamo a capacità e scalabilità di Aurora Serverless v2, facciamo sempre riferimento alla capacità di calcolo che aumenta o diminuisce. Pertanto, il cluster può contenere molti terabyte di dati anche quando la CPU e la capacità di memoria si dimensionano verso il basso.

Anziché effettuare il provisioning e gestire i server di database, puoi indicare la capacità del database. Per informazioni dettagliate sulle capacità di Aurora Serverless v2, consulta Capacità di Aurora Serverless v2. La capacità effettiva di ciascuno scrittore o lettore Aurora Serverless v2 varia nel tempo, a seconda del carico di lavoro. Per i dettagli su questi meccanismi, consulta Dimensionamento di Aurora Serverless v2.

Configurazioni per i cluster Aurora DB

Per ciascuno dei cluster di Aurora DB è possibile scegliere qualsiasi combinazione di capacità, capacità con provisioning o entrambi di Aurora Serverless v2.

Puoi impostare un cluster che contiene entrambi sia Aurora Serverless v2 che capacità con provisioning, indicato con la denominazione cluster a configurazione mista. Ad esempio, supponiamo di aver bisogno di una read/write capacità maggiore di quella disponibile per uno scrittore. Aurora Serverless v2 In questo caso puoi configurare il cluster con uno scrittore con provisioning di dimensioni molto ampie. In tal caso, puoi ancora utilizzare Aurora Serverless v2 per i lettori. Oppure supponi che il carico di lavoro in scrittura per il cluster vari ma che il carico di lavoro in lettura sia costante. In questo caso, puoi configurare il cluster con uno scrittore Aurora Serverless v2 e uno o più lettori con provisioning.

Puoi anche impostare un cluster di database in tutta la capacità è gestita da Aurora Serverless v2. Per fare ciò, puoi creare un nuovo cluster e utilizzare Aurora Serverless v2 fin dall'inizio. In alternativa, puoi sostituire tutta la capacità soggetta a provisioning in un cluster esistente con Aurora Serverless v2. Ad esempio, alcuni percorsi di aggiornamento delle versioni precedenti del motore richiedono di iniziare con uno scrittore con provisioning e sostituirlo con uno scrittore Aurora Serverless v2. Per le procedure per creare un nuovo cluster di database con Aurora Serverless v2 o per passare da un cluster di database esistente a Aurora Serverless v2, consulta Creare un Aurora Serverless v2 cluster di database e Passaggio da un cluster fornito a Aurora Serverless v2.

Se non utilizzi per nulla Aurora Serverless v2 in un cluster di database, tutti gli scrittori e i lettori del cluster di database sono con provisioning. Questo è il tipo di cluster di database più vecchio e più comune con cui la maggior parte degli utenti ha familiarità. Infatti, prima dell'arrivo di Aurora Serverless, non c'era un nome speciale per questo tipo di cluster di Aurora DB. La capacità fornita è costante. Le tariffe sono relativamente semplici da prevedere. Tuttavia, è necessario prevedere in anticipo quanta capacità è necessaria. In alcuni casi le previsioni potrebbero essere imprecise o le esigenze di capacità potrebbero cambiare. In questi casi, il cluster di database può rivelarsi soggetto a provisioning in modo insufficiente (più lento di quello desiderato) o provisioning in modo eccessivo (più costoso di quello desiderato).

Capacità di Aurora Serverless v2

L'unità di misura per Aurora Serverless v2 è l'Unità di capacità Aurora (ACU). La capacità di Aurora Serverless v2 non è legata alle classi dell'istanza database utilizzate per i cluster sottoposti a provisioning.

Ogni ACU è una combinazione di circa 2 gigabyte (GiB) di memoria, CPU corrispondente e rete. Puoi specificare l'intervallo di capacità del database utilizzando questa unità di misura. I parametri ServerlessDatabaseCapacity e ACUUtilization consentono di determinare la capacità effettivamente utilizzata dal database e se tale capacità rientra nell'intervallo specificato.

In qualsiasi momento, a ogni scrittore o lettore del database Aurora Serverless v2 è associata una capacità. La capacità è rappresentata come un numero a virgola mobile che rappresenta. ACUs La capacità aumenta o diminuisce ogni volta che lo scrittore o il lettore si dimensionano. Questo valore viene misurato ogni secondo. Per ogni cluster di database in cui intendi utilizzare Aurora Serverless v2, definisci un intervallo di capacità: i valori minimo e massimo dell'intervallo di capacità all'interno del quale ogni scrittore o lettore di Aurora Serverless v2 può dimensionarsi. L'intervallo di capacità è lo stesso per ciascuno scrittore o lettore di Aurora Serverless v2 in un cluster di database. Ogni scrittore o lettore di Aurora Serverless v2 presenta una propria capacità che ricade in qualche modo in tale intervallo.

La tabella seguente mostra gli intervalli di Aurora Serverless v2 capacità e il supporto delle versioni del motore per Aurora MySQL e Aurora PostgreSQL.

La tabella seguente mostra le versioni della Aurora Serverless v2 piattaforma con le relative gamme ACU e le caratteristiche prestazionali.

È possibile determinare la versione della piattaforma su cui è in esecuzione il cluster nella sezione Configurazione dell'istanza di AWS Management Console o tramite l'API visualizzando il file ServerlessV2PlatformVersion per un DBCluster.

La Aurora Serverless v2 capacità minima che è possibile definire è 0 ACUs, per Aurora Serverless v2 le versioni che supportano la funzione di pausa automatica. Puoi specificare un numero superiore se inferiore o uguale al valore di capacità massima. L'impostazione della capacità minima su un numero ridotto consente ai cluster di database con carichi leggeri di consumare risorse di calcolo minime. Allo stesso tempo, rimangono pronti ad accettare immediatamente le connessioni e a dimensionarsi quando diventano impegnati.

Si consiglia di impostare il minimo su un valore che consenta a ciascuno scrittore o lettore del database DB di mantenere il set di lavoro dell'applicazione nel buffer pool. In questo modo, il contenuto del buffer pool non viene scartato durante i periodi di inattività. Per tutte le considerazioni nella scelta del valore massimo della capacità, consulta Scelta dell'impostazione Aurora Serverless v2 minima della capacità per un cluster. Per tutte le considerazioni nella scelta del valore massimo della capacità, consulta Scelta dell'impostazione Aurora Serverless v2 massima della capacità per un cluster.

A seconda di come si configurano i lettori in un'implementazione Multi-AZ, le loro capacità possono essere legate alla capacità dello scrittore o indipendentemente. Per i dettagli su come eseguire queste operazioni, consulta Dimensionamento di Aurora Serverless v2.

Il monitoraggio di Aurora Serverless v2 prevede la misurazione dei valori di capacità per lo scrittore e i lettori all'interno del cluster di database nel tempo. Se il database non viene si dimensiona verso il basso fino alla capacità minima, puoi intraprendere azioni come la regolazione del minimo e l'ottimizzazione dell'applicazione database. Se il database raggiunge costantemente la sua capacità massima, puoi intraprendere operazioni come l'aumento di tale vincolo. Puoi inoltre ottimizzare l'applicazione di database e distribuire il carico di query su più lettori.

Gli addebito per la capacità di Aurora Serverless v2 sono misurati in termini di ore ACU. Per informazioni su come sono calcolati gli addebiti di Aurora Serverless v2, consulta la Pagina dei prezzi di Aurora.

Supponiamo che il numero totale di scrittori e lettori nel cluster sia. n In tal caso, il cluster consuma approssimativamente n x minimum ACUs quando non si eseguono operazioni di database. Aurora stessa potrebbe eseguire operazioni di monitoraggio o manutenzione che causano una piccola quantità di carico. Nel momento in cui il database è in esecuzione a piena capacità, quel cluster non consuma più di n x maximum ACUs.

Per ulteriori informazioni sulla scelta dei valori minimi e massimi appropriati di ACU, consulta Scelta dell'intervallo di capacità di Aurora Serverless v2 per un cluster Aurora. I valori ACU minimo e massimo specificati influiscono anche sul modo in cui funzionano alcuni parametri di configurazione di Aurora per Aurora Serverless v2. Per informazioni dettagliate sull'interazione tra l'intervallo di capacità e i parametri di configurazione, consulta Uso di gruppi di parametri per Aurora Serverless v2.

Dimensionamento di Aurora Serverless v2

Per ogni scrittore o lettore di Aurora Serverless v2, Aurora tiene costantemente traccia dell'utilizzo di risorse come CPU, memoria e rete. Queste misurazioni sono chiamate collettivamente carico. Il carico include le operazioni di database eseguite dall'applicazione. Include anche l'elaborazione in background per il server di database e le attività amministrative di Aurora. Quando la capacità è vincolata da una di queste opzioni, Aurora Serverless v2 esegue un dimensionamento verso l'alto. Aurora Serverless v2 esegue un dimensionamento verso l'alto anche quando rileva problemi di prestazioni che possono essere risolti in questo modo. Puoi monitorare l'utilizzo delle risorse e come questo influisce sul dimensionamento di Aurora Serverless v2 utilizzando le procedure in CloudWatch Parametri Amazon importanti per Aurora Serverless v2 e Monitoraggio delle prestazioni di Aurora Serverless v2 con Approfondimenti sulle prestazioni.

Il carico può variare tra lo scrittore e i lettori del cluster di database. Lo scrittore gestisce tutte le istruzioni DDL (Data Definition Language), come CREATE TABLE,ALTER TABLE e DROP TABLE. Lo scrittore gestisce anche tutte le istruzioni DML (Data Manipulation Language), come ad esempio INSERT e UPDATE. I lettori possono elaborare istruzioni di sola lettura, come ad esempio le query SELECT.

Il dimensionamento è l'operazione che incrementa o riduce le capacità di Aurora Serverless v2 per il tuo database. ConAurora Serverless v2, ogni scrittore e lettore ha il proprio valore di capacità attuale, misurato in ACUs. Aurora Serverless v2ridimensiona uno scrittore o un lettore fino a una capacità superiore quando la sua capacità attuale è troppo bassa per gestire il carico. Ridimensiona lo scrittore o il lettore a una capacità inferiore quando la sua capacità corrente è superiore a quella necessaria.

A differenza di Aurora Serverless v1, che si dimensiona raddoppiando la capacità ogni volta che il cluster di database raggiunge una specifica soglia, Aurora Serverless v2 può aumentare la capacità in modo incrementale. Quando la richiesta di carico di lavoro inizia a raggiungere l'attuale capacità del database di uno scrittore o di un lettore, Aurora Serverless v2 aumenta il numero di ACUs utenti che scrivono o leggono. Aurora Serverless v2ridimensiona la capacità negli incrementi richiesti per fornire le migliori prestazioni per le risorse consumate. Il ridimensionamento avviene con incrementi fino a 0,5. ACUs Maggiore è la capacità attuale, maggiore è l'incremento nel dimensionamento e quindi più velocemente può essere garantito il dimensionamento.

Poiché Aurora Serverless v2 il ridimensionamento è così frequente, granulare e senza interruzioni, non causa eventi discreti come accade. AWS Management Console Aurora Serverless v1 Puoi invece misurare i CloudWatch parametri di Amazon come ServerlessDatabaseCapacity e ACUUtilization e tenere traccia dei loro valori minimi, massimi e medi nel tempo. Per maggiori informazioni sui parametri di Aurora, consulta Monitoraggio dei parametri in un cluster di database Amazon Aurora. Per suggerimenti sul monitoraggio di Aurora Serverless v2, consulta CloudWatch Parametri Amazon importanti per Aurora Serverless v2.

Puoi scegliere di creare un dimensionamento del lettore in modo contemporaneo allo scrittore associato o indipendentemente da questo. Tale obiettivo si raggiunge specificando il livello di promozione per quel lettore.

Per i dettagli sui livelli di promozione, consulta Scelta del livello di promozione per un'istanza Aurora Serverless v2 di lettura.

Le nozioni di punti di dimensionamento e periodi di timeout associati presenti in Aurora Serverless v1 non si applicano a Aurora Serverless v2. Il dimensionamento di Aurora Serverless v2 può avvenire mentre le connessioni al database sono aperte, mentre le transazioni SQL sono in corso, mentre le tabelle sono bloccate e mentre le tabelle temporanee sono in uso. Aurora Serverless v2 non attende un momento di scarso utilizzo per avviare il dimensionamento. Il dimensionamento non interrompe le operazioni del database in corso.

Se il carico di lavoro richiede una capacità di lettura superiore a quella disponibile con un singolo scrittore e un singolo lettore, è possibile aggiungere più Aurora Serverless v2 lettori al cluster. Ogni lettore Aurora Serverless v2 può dimensionarsi all'interno dei valori di capacità minimo e massimo specificati per il cluster di database. Puoi utilizzare l'endpoint di lettura del cluster per gestire le sessioni di sola lettura attraverso i lettori e ridurre il carico sullo scrittore.

L'esecuzione del dimensionamento da parte di Aurora Serverless v2 e la velocità di dimensionamento dopo l'avvio dipendono anche dalle impostazioni ACU minima e massima per il cluster. Inoltre, dipendono dal fatto che un lettore sia configurato per dimensionarsi contemporaneamente allo scrittore o indipendentemente da esso. Per i dettagli sui fattori che influenzano il dimensionamento di Aurora Serverless v2, consulta Prestazioni e dimensionamento per Aurora Serverless v2.

Scalabilità a zero

Nelle versioni recenti di Aurora MySQL e Aurora PostgreSQL, gli autori e i lettori possono scalare fino a zero. Aurora Serverless v2 ACUs Ci riferiamo a questa funzionalità come pausa e ripresa automatiche o pausa automatica. È possibile scegliere se consentire questo comportamento specificando un valore zero o diverso da zero per la capacità minima. Puoi anche scegliere per quanto tempo aspettare prima che un'Aurora Serverless v2istanza venga messa in pausa. Per informazioni sulle versioni dotate di questa funzionalità, consultaCapacità di Aurora Serverless v2. Per informazioni su come utilizzarlo in modo efficace, vedereRidimensionamento a zero ACUs con pausa e ripresa automatiche per Aurora Serverless v2.

Nelle versioni precedenti di Aurora MySQL e Aurora PostgreSQL, gli scrittori e i lettori Aurora Serverless v2 inattivi possono ridimensionarsi fino al valore ACU minimo specificato per il cluster, ma non fino a zero. ACUs In tal caso, zero non ACUs è disponibile come scelta quando si imposta l'intervallo di capacità. Questo comportamento è diverso da quello di Aurora Serverless v1, che può sospendere i processi dopo un periodo di inattività ma richiede un po' di tempo per la ripartenza quando si apre una nuova connessione.

Quando il cluster DB con Aurora Serverless v2 capacità non è necessario per qualche tempo, puoi anche arrestare e avviare l'intero cluster, come con i cluster DB di cui è stato effettuato il provisioning. Questa tecnica è più adatta per i sistemi di sviluppo e test, in cui potrebbero non essere necessari per molte ore consecutive e la velocità di ripristino del cluster non è fondamentale. La funzionalità stop/start cluster è disponibile per tutte le Aurora Serverless v2 versioni. Per ulteriori informazioni su questa funzionalità, vedereAvvio e arresto di un cluster di database Amazon Aurora.

Aurora Serverless v2 ed elevata disponibilità

Il modo per garantire un'elevata disponibilità di un cluster Aurora DB consiste nel renderlo un cluster di database Multi-AZ. Un cluster di database Aurora Multi-AZ garantisce capacità di calcolo disponibile in ogni momento in più di una zona di disponibilità (AZ). Tale configurazione mantiene il database attivo e funzionante anche in caso di rilevanti malfunzionamenti. Aurora esegue un failover automatico in caso di problemi che riguardano lo scrittore o persino l'intera AZ. Con Aurora Serverless v2 puoi scegliere la capacità di calcolo in stand-by da dimensionare verso l'alto e verso il basso insieme alla capacità dello scrittore. In questo modo, la capacità di calcolo nella seconda AZ è pronta a rilevare il carico di lavoro corrente in qualsiasi momento. Allo stesso tempo, la capacità di elaborazione complessiva AZs può essere ridotta quando il database è inattivo. Per informazioni dettagliate sul funzionamento di Aurora Regioni AWS e sulle zone di disponibilità, consulta. Architetture ad alta disponibilità per istanze database Aurora

La funzionalità Multi-AZ di Aurora Serverless v2 utilizza dei lettori in aggiunta allo scrittore. Il supporto per i lettori è nuovo in Aurora Serverless v2 rispetto a quanto offerto da Aurora Serverless v1. Puoi aggiungere fino a 15 Aurora Serverless v2 lettori distribuiti su 3 AZs a un cluster Aurora DB.

Per le applicazioni aziendali critiche che devono rimanere disponibili anche in caso di problemi che interessano l'intero cluster o l'intera AWS regione, puoi configurare un database globale Aurora. Puoi utilizzare le funzionalità di Aurora Serverless v2 nei cluster secondari in modo che siano pronti a subentrare durante un eventuale ripristino di emergenza. Possono anche dimensionarsi verso il basso quando il database non è impegnato. Per informazioni dettagliate sui database globali di Aurora, consulta Utilizzo del database globale Amazon Aurora.

Aurora Serverless v2 funziona come un database con provisioning per quanto riguarda il failover e altre funzionalità ad alta disponibilità. Per ulteriori informazioni, consulta Elevata disponibilità di Amazon Aurora.

Supponiamo tu voglia garantire la massima disponibilità per il tuo cluster Aurora Serverless v2. Puoi un lettore in aggiunta allo scrittore. Se assegni il lettore al livello di promozione 0 o 1, qualsiasi dimensionamento avvenga per lo scrittore esso viene replicato anche per il lettore. In questo modo, un lettore con capacità identica è sempre pronto a prendere il posto dello scrittore in caso di failover.

Supponi di voler eseguire report trimestrali per la tua azienda nello stesso momento in cui il cluster continua a elaborare le transazioni. Se aggiungi un lettore Aurora Serverless v2 al cluster e lo assegni a un livello di promozione da 2 a 15, puoi connetterti direttamente a quel lettore per eseguire i report. A seconda di quanto le query di reporting sono esigenti in termini di memoria e di utilizzo della CPU, il lettore può dimensionarsi verso l'alto per adattarsi al carico di lavoro. Può successivamente dimensionarsi di nuovo verso il basso una volta terminata la generazione dei report.

Aurora Serverless v2 e spazio di archiviazione

Lo storage per ogni cluster Aurora DB è composto da sei copie di tutti i dati, distribuite su tre. AZs Questa replica dei dati integrata si applica indipendentemente dal fatto che il cluster di database includa dei lettori in aggiunta allo scrittore. In questo modo i dati sono al sicuro anche da problemi che influiscono sulla capacità di calcolo del cluster.

Lo spazio di archiviazione di Aurora Serverless v2 ha le stesse caratteristiche di affidabilità e durata descritte in Archiviazione Amazon Aurora. Questo perché lo spazio di archiviazione per i cluster di database Aurora funziona allo stesso modo, indipendentemente dal fatto che la capacità di calcolo utilizzi Aurora Serverless v2 o un database con provisioning.

Parametri di configurazione per i cluster Aurora

Puoi regolare tutti gli stessi parametri di configurazione del cluster e del database per i cluster con funzionalità Aurora Serverless v2 così come faresti per i cluster di database con provisioning. Tuttavia, alcuni parametri relativi alla capacità sono gestiti in modo diverso da Aurora Serverless v2. In un cluster a configurazione mista, i valori specificati per i parametri relativi alla capacità si applicano a tutti gli scrittori e i lettori con provisioning.

Quasi tutti i parametri funzionano allo stesso modo per gli scrittori e i lettori Aurora Serverless v2 in modo analogo a quanto accade a quelli con provisioning. Le eccezioni riguardano alcuni parametri che Aurora regola automaticamente durante il dimensionamento e alcuni parametri che Aurora mantiene a valori fissi dipendenti dall'impostazione della capacità massima.

Ad esempio, la quantità di memoria riservata alla cache del buffer aumenta man mano che uno scrittore o un lettore si dimensionano verso l'alto e diminuisce man mano che si dimensionano verso il basso. In questo modo, la memoria può essere rilasciata quando il database non è impegnato. Al contrario, Aurora imposta automaticamente il numero massimo di connessioni su un valore appropriato in base all'impostazione della capacità massima. In questo modo, le connessioni attive non vengono interrotte se il carico diminuisce e Aurora Serverless v2 si ridimensiona verso il basso. Per informazioni sui come Aurora Serverless v2 gestisce parametri specifici, consulta Uso di gruppi di parametri per Aurora Serverless v2.