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

La seguente panoramica descrive il funzionamento di Aurora serverless.

Panoramica di Aurora serverless

Amazon Aurora serverless è 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 è progettato da zero per supportare cluster DB serverless che risultino istantaneamente scalabili. Aurora serverless è 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 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 nel cluster all'interno di tale intervallo di capacità. Utilizzando un Multi-AZ cluster in cui ogni scrittore o lettore può scalare dinamicamente, è possibile sfruttare la scalabilità dinamica e l'elevata disponibilità.

Aurora serverless 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 debbano essere spostati da un host all'altro, Aurora serverless gestisce automaticamente le connessioni. Non è necessario modificare il codice dell'applicazione client del database o le stringhe di connessione al database.

Con Aurora serverless, 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, 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, consulta Capacità di Aurora serverless. La capacità effettiva di ciascuno scrittore o lettore Aurora serverless varia nel tempo, a seconda del carico di lavoro. Per i dettagli su questi meccanismi, consulta Dimensionamento di Aurora serverless.

Configurazioni per i cluster di database Aurora

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

Puoi impostare un cluster che contiene entrambi sia Aurora serverless che capacità con provisioning, indicato con la denominazione cluster a configurazione mista. Ad esempio, supponete di aver bisogno di una read/write capacità maggiore di quella disponibile per uno scrittore. Aurora serverless In questo caso puoi configurare il cluster con uno scrittore con provisioning di dimensioni molto ampie. In tal caso, puoi ancora utilizzare Aurora serverless 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 e uno o più lettori con provisioning.

Puoi anche impostare un cluster di database in tutta la capacità è gestita da Aurora serverless. Per fare ciò, puoi creare un nuovo cluster e utilizzare Aurora serverless fin dall'inizio. In alternativa, puoi sostituire tutta la capacità soggetta a provisioning in un cluster esistente con Aurora serverless. 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. Per le procedure per creare un nuovo cluster di database con Aurora serverless o per passare da un cluster di database esistente a Aurora serverless, consulta Creazione di un cluster di database Aurora serverless e Conversione di un'istanza di lettura o scrittura con provisioning per Aurora serverless.

Se non utilizzi per nulla Aurora serverless 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

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

Ogni ACU è una combinazione di circa 2 gigabyte (GiB) di memoria, CPU corrispondente e rete. È possibile specificare l'intervallo di capacità del database (minimo e massimo) utilizzando questa unità di misura. Aurora serverlessoffre una capacità da 0 ACU a 256 ACU. Con una capacità minima di 0 ACU, il cluster verrà scalato a 0 quando non è in esecuzione alcun carico di lavoro. Le ACUUtilization metriche ServerlessDatabaseCapacity and consentono di determinare la capacità effettivamente utilizzata dal database e dove tale capacità rientra nell'intervallo specificato.

In qualsiasi momento, a ogni scrittore o lettore del database Aurora serverless è associata una capacità. La capacità è rappresentata da un numero a virgola mobile che rappresenta le ACU. 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, 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 può dimensionarsi. L'intervallo di capacità è lo stesso per ciascuno scrittore o lettore di Aurora serverless in un cluster di database. Ogni scrittore o lettore di Aurora serverless presenta una propria capacità che ricade in qualche modo in tale intervallo.

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

Le versioni della piattaforma Aurora serverless rappresentano miglioramenti delle prestazioni, delle capacità o delle funzionalità di scalabilità. Amazon Aurora gestisce automaticamente le assegnazioni delle versioni della piattaforma a livello di cluster. Tutti i nuovi cluster, ripristini di database e nuovi cloni vengono lanciati con l'ultima versione della piattaforma disponibile nel tuo. Regione AWS Quando diventa disponibile una nuova versione della piattaforma, i cluster esistenti nelle versioni precedenti della piattaforma possono essere aggiornati direttamente alla versione più recente della piattaforma arrestando e riavviando il cluster o utilizzando le distribuzioni. blue/green Amazon Aurora consiglia l'aggiornamento alla versione più recente della piattaforma per beneficiare di tutti i miglioramenti più recenti.

La tabella seguente mostra le versioni della piattaforma Aurora serverless con i relativi intervalli ACU e le caratteristiche delle prestazioni.

Le versioni 1, 2 e 3 della piattaforma sono disponibili in tutte le regioni in cui Aurora serverless è supportata. La versione 4 della piattaforma è disponibile nelle seguenti regioni: Stati Uniti orientali (Virginia settentrionale), Stati Uniti orientali (Ohio), Stati Uniti occidentali (California settentrionale), Stati Uniti occidentali (Oregon), Asia Pacifico (Hong Kong), Asia Pacifico (Hyderabad), Asia Pacifico (Giacarta), Asia Pacifico (Malesia), Asia Pacifico (Melbourne), Asia Pacifico (Mumbai), Asia Pacifico (Osaka), Asia Pacifico (Malesia), Asia Pacifico (Melbourne), Asia Pacifico (Mumbai), Asia Pacifico (Osaka), Asia Pacifico (Malesia), Asia Pacifico (Melbourne) (Seoul), Asia Pacifico (Singapore), Asia Pacifico (Sydney), Asia Pacifico (Tokyo), Canada (Centrale), Europa (Francoforte), Europa (Irlanda), Europa (Londra), Europa (Parigi), Europa (Spagna), Europa (Stoccolma), Europa (Zurigo), Sud America (São Paulo), AWS GovCloud (US-East) e AWS GovCloud (US-West).

È possibile determinare la versione della piattaforma su cui è in esecuzione il cluster nella sezione Configurazione dell'istanza di Console di gestione AWS o tramite l'API visualizzando la scheda ServerlessV2PlatformVersion relativa a DbCluster.

La capacità minima Aurora serverless che è possibile definire è 0 ACU, per le versioni Aurora serverless che supportano la funzionalità 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 DB 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 minima della capacità per un cluster. Per tutte le considerazioni nella scelta del valore massimo della capacità, consulta Scelta dell'impostazione Aurora serverless massima della capacità per un cluster.

A seconda di come si configurano i lettori in una Multi-AZ distribuzione, 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.

Il monitoraggio di Aurora serverless 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 addebiti per la Aurora serverless capacità sono misurati in termini di ACU-hours. Per informazioni su come sono calcolati gli addebiti di Aurora serverless, consulta la Pagina dei prezzi di Aurora.

Supponiamo che il numero totale di scrittori e lettori nel tuo cluster sian. In tal caso, il cluster consuma approssimativamente n x minimum ACUs quando non si esegue alcuna operazione 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 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. Per informazioni dettagliate sull'interazione tra l'intervallo di capacità e i parametri di configurazione, consulta Uso di gruppi di parametri per Aurora serverless.

Dimensionamento di Aurora serverless

Per ogni scrittore o lettore di Aurora serverless, 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 esegue un dimensionamento verso l'alto. Aurora serverless 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 utilizzando le procedure in CloudWatch Parametri Amazon importanti per Aurora serverless e Monitoraggio delle prestazioni di Aurora serverless 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 per il tuo database. Con Aurora serverless, ogni scrittore e lettore ha il proprio valore di capacità attuale, misurato in ACU. Aurora serverless dimensiona uno scrittore o un lettore 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.

Aurora serverlesspuò aumentare la capacità in modo incrementale. Quando la domanda del carico di lavoro inizia a raggiungere la capacità del database corrente di uno scrittore o un lettore, Aurora serverless incrementa il numero di ACU per lo scrittore o il lettore. Aurora serverless dimensiona la capacità secondo gli incrementi necessari per fornire le migliori prestazioni per le risorse consumate. Il dimensionamento avviene con incrementi ridotti fino a 0,5 ACU. Maggiore è la capacità attuale, maggiore è l'incremento nel dimensionamento e quindi più velocemente può essere garantito il dimensionamento.

Poiché Aurora serverless il ridimensionamento è così frequente, granulare e senza interruzioni, non causa eventi discreti in. Console di gestione AWS 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, consulta CloudWatch Parametri Amazon importanti per Aurora serverless.

Puoi scegliere di fare in modo che un lettore segua le capacità dello scrittore associato o crescere indipendentemente dallo scrittore. 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 di lettura.

Aurora serverlessil ridimensionamento 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 serverlessnon aspetta che arrivi un punto di quiete per iniziare la scalabilità. 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 lettori al cluster. Ogni lettore Aurora serverless 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 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, consulta Prestazioni e dimensionamento per Aurora serverless.

Dimensionamento a Zero

Nelle versioni recenti di Aurora MySQL e Aurora PostgreSQL, le istanze di lettura e scrittura Aurora serverless possono scalare fino a zero ACU. Questa capacità viene indicata 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. È anche possibile scegliere quanto tempo aspettare prima che un’istanza Aurora serverless entri in pausa. Per informazioni sulle versioni dotate di questa capacità, consulta Capacità di Aurora serverless. Per informazioni su come utilizzare questa capacità in modo efficace, consulta Dimensionamento a zero ACU con pausa e ripresa automatiche per Aurora serverless.

Nelle versioni precedenti di Aurora MySQL e Aurora PostgreSQL, le istanze di scrittura e lettura Aurora serverless inattive possono essere ridotte verticalmente fino al valore ACU minimo specificato per il cluster, ma non fino a zero ACU. In questo caso, zero ACU non è un’opzione disponibile per l’impostazione dell’intervallo di capacità.

Quando il cluster di database con capacità Aurora serverless non è necessario per un certo periodo di tempo, è possibile arrestare e avviare l‘intero cluster in modo simile a come accade con i cluster di database con provisioning. Questa tecnica è particolarmente adatta per i sistemi di sviluppo e test, che potrebbero non essere necessari per molte ore consecutive e per i quali la velocità di ripresa del cluster non è essenziale. La funzionalità stop/start cluster è disponibile per tutte le Aurora serverless versioni. Per ulteriori informazioni su questa funzionalità, consulta Avvio e arresto di un cluster di database Amazon Aurora.

Aurora serverless ed elevata disponibilità

Il modo per stabilire un'elevata disponibilità per un cluster Aurora DB consiste nel renderlo un cluster Multi-AZ DB. Un cluster Multi-AZ Aurora DB ha una capacità di elaborazione sempre disponibile 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 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 calcolo in tutte le AZ può dimensionarsi verso il basso 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 Aurora serverless Multi-AZ funzionalità utilizza i lettori oltre allo scrittore. Il supporto per i lettori è una novità perAurora serverless. In un cluster di database Aurora puoi aggiungere fino a 15 lettori Aurora serverless distribuiti su 3 AZ.

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 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 di Database globale Amazon Aurora.

Aurora serverless 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. Puoi un lettore in aggiunta allo scrittore. Se si assegna il lettore al livello di promozione 0 o 1, la capacità minima del lettore corrisponderà alla capacità di scrittura attuale (o alla dimensione della memoria dello scrittore, per gli scrittori predisposti). In questo modo, un lettore è 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 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 dell'uso intensivo della memoria e CPU-intensive delle query di reporting, il lettore può essere scalato per adattarsi al carico di lavoro. Può successivamente dimensionarsi di nuovo verso il basso una volta terminata la generazione dei report.

Aurora serverless e spazio di archiviazione

Lo spazio di archiviazione per ciascun cluster di database Aurora è costituito da sei copie di tutti i dati, distribuite su tre AZ. 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 ha le stesse caratteristiche di affidabilità e durata descritte in Archiviazione Amazon Aurora. Questo perché lo spazio di archiviazione per i cluster DB Aurora funziona allo stesso modo, indipendentemente dal fatto che la capacità di calcolo utilizzi Aurora serverless 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 così come faresti per i cluster DB con provisioning. Tuttavia, alcuni parametri relativi alla capacità sono gestiti in modo diverso da Aurora serverless. 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 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 si ridimensiona verso il basso. Per informazioni sui come Aurora serverless gestisce parametri specifici, consulta Uso di gruppi di parametri per Aurora serverless.