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

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 v2 funzionamento

La seguente panoramica descrive come Aurora Serverless v2 funziona.

Aurora Serverless v2 resoconto

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, puoi scegliere una classe di istanza database con una quantità predefinita di memoria, potenza della CPU, larghezza di banda I/O 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 DB serverless che sono immediatamente scalabili. Aurora Serverless v2 è progettato per fornire lo stesso grado di sicurezza e isolamento degli autori e dei lettori predisposti. 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 vincolato a una capacità di database specifica per ogni scrittore e lettore. Puoi specificare l'intervallo minimo e massimo per la capacità. Aurora scala ciascuno Aurora Serverless v2 scrittore o lettore nel cluster entro 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 ridimensiona automaticamente le risorse del database 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 un Aurora Serverless v2 lo scrittore o il lettore viene spostato 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 forniti, la capacità di archiviazione e la capacità di elaborazione sono separate. Quando ci riferiamo a Aurora Serverless v2 capacità e scalabilità, è sempre la capacità di elaborazione ad aumentare o diminuire. 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 su Aurora Serverless v2 capacità, vedereAurora Serverless v2 capacità. La capacità effettiva di ciascuno Aurora Serverless v2 scrittore o lettore varia nel tempo, a seconda del carico di lavoro. Per i dettagli su questi meccanismi, consulta Aurora Serverless v2 scalabilità.

Configurazioni per i cluster Aurora DB

Per ciascuno dei tuoi cluster Aurora DB, puoi scegliere qualsiasi combinazione di Aurora Serverless v2 capacità, capacità fornita o entrambe.

È possibile configurare un cluster che contenga entrambi Aurora Serverless v2 e capacità assegnata, denominata cluster a configurazione mista. Ad esempio, si supponga di aver bisogno di una capacità di lettura/scrittura superiore a quella disponibile per un Aurora Serverless v2 scrittore. In questo caso puoi configurare il cluster con uno scrittore con provisioning di dimensioni molto ampie. In tal caso, puoi ancora usare 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 tuo cluster con un Aurora Serverless v2 scrittore e uno o più lettori autorizzati.

È inoltre possibile configurare un cluster DB in cui tutta la capacità è gestita da Aurora Serverless v2. Per fare ciò, puoi creare un nuovo cluster e utilizzare Aurora Serverless v2 dall'inizio. Oppure puoi sostituire tutta la capacità fornita in un cluster esistente con Aurora Serverless v2. Ad esempio, alcuni percorsi di aggiornamento da versioni precedenti del motore richiedono di iniziare con un writer fornito e sostituirlo con un Aurora Serverless v2 scrittore. Per le procedure per creare un nuovo cluster DB con Aurora Serverless v2 o per passare a un cluster DB esistente Aurora Serverless v2, vedi Creare un Aurora Serverless v2 cluster di database ePassaggio da un cluster fornito a Aurora Serverless v2.

Se non lo usi Aurora Serverless v2 in un cluster DB, viene eseguito il provisioning di tutti gli scrittori e i lettori del cluster DB. Questo è il tipo di cluster di database più vecchio e più comune con cui la maggior parte degli utenti ha familiarità. In effetti, prima Aurora Serverless, non c'era un nome speciale per questo tipo di cluster 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).

Aurora Serverless v2 capacità

L'unità di misura per Aurora Serverless v2 è l'unità di capacità Aurora (ACU). Aurora Serverless v2 la capacità non è legata alle classi di istanze DB utilizzate per i cluster assegnati.

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, ogni Aurora Serverless v2 Lo scrittore o lettore DB ha 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 DB in cui intendi utilizzare Aurora Serverless v2, si definisce un intervallo di capacità: i valori di capacità minima e massima di ciascuno Aurora Serverless v2 lo scrittore o il lettore possono passare da uno all'altro. L'intervallo di capacità è lo stesso per ciascuno Aurora Serverless v2 scrittore o lettore in un cluster DB. Ciascuno Aurora Serverless v2 lo scrittore o il lettore hanno le proprie capacità, che rientrano in questa gamma.

La tabella seguente mostra le Aurora Serverless v2 intervalli di capacità supportati per Aurora MySQL e Aurora PostgreSQL.

Il più piccolo Aurora Serverless v2 la capacità che è possibile definire è 0 ACUs, per Aurora Serverless v2 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 del minimo Aurora Serverless v2 impostazione della capacità per un cluster. Per tutte le considerazioni nella scelta del valore massimo della capacità, consulta Scelta del massimo Aurora Serverless v2 impostazione 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 Aurora Serverless v2 scalabilità.

Monitoraggio Aurora Serverless v2 prevede la misurazione dei valori di capacità dello scrittore e dei lettori nel cluster DB 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.

Le spese per Aurora Serverless v2 la capacità è misurata in termini di ore ACU. Per informazioni su come Aurora Serverless v2 i costi sono calcolati, consulta la pagina dei prezzi di Aurora.

Supponiamo che il numero totale di scrittori e lettori del 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 del Aurora Serverless v2 intervallo di capacità per un cluster Aurora. I valori ACU minimi e massimi specificati influiscono anche sul funzionamento di alcuni parametri di configurazione di Aurora. Aurora Serverless v2. Per informazioni dettagliate sull'interazione tra l'intervallo di capacità e i parametri di configurazione, vedereUtilizzo di gruppi di parametri per Aurora Serverless v2.

Aurora Serverless v2 scalabilità

Per ogni Aurora Serverless v2 scrittore o lettore, Aurora monitora continuamente l'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à è limitata da uno di questi fattori, Aurora Serverless v2 aumenta. Aurora Serverless v2 si espande inoltre quando rileva problemi di prestazioni che può risolvere in tal modo. È possibile monitorare l'utilizzo delle risorse e il modo in cui influisce Aurora Serverless v2 scalabilità utilizzando le procedure di e. CloudWatch Parametri Amazon importanti per Aurora Serverless v2 Monitoraggio Aurora Serverless v2 prestazioni con Performance Insights

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 ridimensionamento è l'operazione che aumenta o diminuisce Aurora Serverless v2 capacità del database. Con Aurora Serverless v2, ogni scrittore e lettore ha il proprio valore di capacità attuale, misurato in ACUs. Aurora Serverless v2 ridimensiona 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 Aurora Serverless v1, scalabile raddoppiando la capacità ogni volta che il cluster DB raggiunge una soglia, Aurora Serverless v2 può aumentare la capacità in modo incrementale. Quando la richiesta di carico di lavoro inizia a raggiungere l'attuale capacità di database di uno scrittore o di un lettore, Aurora Serverless v2 aumenta il numero di ACUs per quello scrittore o lettore. Aurora Serverless v2 ridimensiona 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.

Perché Aurora Serverless v2 il ridimensionamento è così frequente, granulare e senza interruzioni che non causa eventi discreti come AWS Management Console Aurora Serverless v1 fa. 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 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 Aurora Serverless v2 reader.

Le nozioni di punti di scala e i periodi di timeout associati da Aurora Serverless v1 non si applicano in Aurora Serverless v2. Aurora Serverless v2 il 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 Serverless v2 non 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, puoi aggiungerne più di uno Aurora Serverless v2 lettori al cluster. Ciascuno Aurora Serverless v2 reader può scalare entro l'intervallo dei valori di capacità minima e massima specificati per il cluster DB. Puoi utilizzare l'endpoint di lettura del cluster per gestire le sessioni di sola lettura attraverso i lettori e ridurre il carico sullo scrittore.

Se Aurora Serverless v2 esegue il ridimensionamento e la velocità con cui viene eseguito il ridimensionamento una volta avviato dipende anche dalle impostazioni ACU minime e massime per il cluster. Inoltre, dipendono dal fatto che un lettore sia configurato per dimensionarsi contemporaneamente allo scrittore o indipendentemente da esso. Per informazioni dettagliate sui fattori che influiscono Aurora Serverless v2 ridimensionamento, vederePrestazioni e scalabilità per Aurora Serverless v2.

Ridimensionamento a zero

Nelle versioni recenti di Aurora MySQL e Aurora PostgreSQL, Aurora Serverless v2 scrittori e lettori possono scalare fino a zero. 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 quanto tempo aspettare prima di un Aurora Serverless v2 pause di istanza. Per informazioni sulle versioni dotate di questa funzionalità, vedereAurora Serverless v2 capacità. 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, inattiva Aurora Serverless v2 gli autori e i lettori 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 Aurora Serverless v1, che può interrompersi dopo un periodo di inattività, ma che poi impiega del tempo prima che riprenda quando si apre una nuova connessione.

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

Aurora Serverless v2 e alta 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 scalabilità verso l'alto e verso il basso della capacità di elaborazione in standby 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

Il Aurora Serverless v2 La funzionalità Multi-AZ utilizza lettori oltre allo scrittore. Il supporto per i lettori è una novità per Aurora Serverless v2 rispetto a Aurora Serverless v1. Puoi aggiungere fino a 15 Aurora Serverless v2 lettori distribuiti su 3 AZs su 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. È possibile utilizzare… Aurora Serverless v2 capacità nei cluster secondari in modo che siano pronti a subentrare durante il disaster recovery. 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 in modo analogo a quanto previsto per il failover e altre funzionalità di alta disponibilità. Per ulteriori informazioni, consulta Elevata disponibilità di Amazon Aurora.

Supponiamo di voler garantire la massima disponibilità per i Aurora Serverless v2 grappolo. 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 Aurora Serverless v2 è possibile collegare il lettore al cluster e assegnarlo a un livello di promozione compreso tra 2 e 15, è possibile connettersi 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 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.

Aurora Serverless v2 lo storage ha le stesse caratteristiche di affidabilità e durabilità descritte inArchiviazione Amazon Aurora. Questo perché lo storage per i cluster Aurora DB funziona allo stesso modo indipendentemente dalla capacità di elaborazione utilizzata Aurora Serverless v2 o fornito.

Parametri di configurazione per i cluster Aurora

È possibile modificare tutti gli stessi parametri di configurazione del cluster e del database per i cluster con Aurora Serverless v2 capacità come per i cluster DB assegnati. Tuttavia, alcuni parametri relativi alla capacità vengono gestiti in modo diverso per Aurora Serverless v2. In un cluster a configurazione mista, i valori dei parametri specificati per tali parametri relativi alla capacità si applicano ancora a tutti gli scrittori e i lettori forniti.

Quasi tutti i parametri funzionano allo stesso modo per Aurora Serverless v2 scrittori e lettori per quanto riguarda quelli predisposti. 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. Per informazioni su come Aurora Serverless v2 gestisce parametri specifici, vedereUtilizzo di gruppi di parametri per Aurora Serverless v2.