Domande generali

D: Cos'è Amazon Aurora?

Amazon Aurora è un moderno database relazionale che offre prestazioni e alta disponibilità su vasta scala, edizioni compatibili con MySQL e PostgreSQL totalmente open source e una gamma di strumenti di sviluppo per costruire applicazioni serverless e con tecnologia machine learning (ML).

Aurora vanta un sistema di archiviazione distribuito con tolleranza ai guasti e riparazione automatica che è disaccoppiato dalle risorse di calcolo e che si dimensiona automaticamente fino a 128 TB per istanza di database. Offre elevate prestazioni e disponibilità con un massimo di 15 repliche di lettura a bassa latenza, ripristino point-in-time (PITR), backup continuo su Amazon Simple Storage Service (Amazon S3) e replica su tre zone di disponibilità.

Amazon Aurora è anche un servizio completamente gestito che automatizza le attività di amministrazione che richiedono tempo come il provisioning dell'hardware, l'impostazione del database, l'applicazione delle patch e i backup, fornendo al contempo la sicurezza, la disponibilità e l'affidabilità dei database commerciali a 1/10 del costo.

D: Cosa significa "compatibile con MySQL"?

Amazon Aurora è completamente compatibile con i database MySQL open-source esistenti e aggiunge regolarmente assistenza per le nuove versioni. In questo modo, puoi migrare facilmente i database MySQL verso e da Aurora usando gli strumenti di import/export standard o gli snapshot. Significa anche che la maggior parte del codice, delle applicazioni, dei driver e degli strumenti già usati con i database MySQL può essere usata con Aurora con modifiche minime o senza alcuna modifica. Quando si confronta Aurora con MySQL, è importante capire che il motore del database Amazon Aurora è stato progettato per essere wire-compatible con MySQL 5.6 e 5.7 mediante il motore di archiviazione InnoDB. Questo rende facile lo spostamento delle applicazioni tra i due motori. Alcune caratteristiche MySQL, ad esempio il motore di archiviazione MyISAM, non sono disponibili con Amazon Aurora.

D: Cosa significa "compatibile con PostgreSQL"?

Amazon Aurora è completamente compatibile con i database PostgreSQL open-source esistenti e aggiunge regolarmente assistenza per le nuove versioni. In questo modo puoi migrare facilmente i database PostgreSQL verso e da Aurora usando gli strumenti di import/export standard o gli snapshot. Significa anche che la maggior parte del codice, delle applicazioni, dei driver e degli strumenti già usati con i database PostgreSQL può essere usata con Aurora con modifiche minime o senza alcuna modifica. 

D: Quali sono gli aspetti da prendere in considerazione tra Amazon Aurora e Amazon Relational Database Service (Amazon RDS)?

R: Amazon RDS è un servizio di database completamente gestito, altamente disponibile e sicuro che rende semplice impostare, operare ed eseguire la scelta di sette motori di database relazionali: PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, Amazon Aurora nell'edizione compatibile con MySQL e Amazon Aurora nell'edizione compatibile con PostgreSQL. 

Amazon Aurora nell'edizione compatibile con MySQL e Amazon Aurora nell'edizione compatibile con PostgreSQL sfruttano i vantaggi di Amazon RDS, compresa l'automazione delle attività amministrative del database che richiedono molto tempo e offrono prestazioni, scalabilità e disponibilità migliori rispetto alle comunità open-source MySQL e PostgreSQL.

D: Com'è possibile provare a usare Amazon Aurora?

Per provare Amazon Aurora, accedi alla Console di gestione AWS, seleziona RDS nella categoria Database e scegli Amazon Aurora come motore di database.

D: Quanto costa Amazon Aurora?

Consulta la pagina dei prezzi di Aurora per informazioni aggiornate.

D: Amazon Aurora replica ogni blocco del volume del database sei volte sulle tre zone di disponibilità. Ciò significa che il prezzo effettivo dello storage sarà moltiplicato per tre o per sei rispetto a quanto riportato nella pagina dei prezzi?

La replica di Amazon Aurora è inclusa nel prezzo. Il costo verrà addebitato in base allo storage consumato dal database nel layer di database e non in base allo storage consumato dal layer di storage virtualizzato di Amazon Aurora.

D: In quali regioni AWS è disponibile Amazon Aurora?

Consulta la pagina dei prezzi di Aurora per informazioni aggiornate su tariffe e regioni.

D: Com'è possibile eseguire la migrazione da MySQL ad Amazon Aurora e viceversa?

Sono disponibili numerose opzioni. È possibile usare la utility mysqldump standard per esportare i dati da MySQL e la utility mysqlimport per importare i dati in Amazon Aurora e viceversa. È inoltre possibile usare la caratteristica di migrazione di snapshot DB di Amazon RDS per eseguire la migrazione di uno snapshot DB Amazon RDS for MySQL in Amazon Aurora usando la Console di gestione AWS. Nella maggior parte dei casi, il processo di migrazione viene completato in meno di un'ora; la durata effettiva dipende tuttavia dal formato e dalle dimensioni del set di dati. Per ulteriori informazioni, consulta il whitepaper Best practice per la migrazione di database MySQL in Amazon Aurora.

D: In che modo è possibile eseguire una migrazione da PostgreSQL ad Amazon Aurora e viceversa?

Sono disponibili numerose opzioni. È possibile usare la utility pg_dump standard per esportare i dati da PostgreSQL e la utility pg_restore per importare i dati in Amazon Aurora e viceversa. È inoltre possibile usare la caratteristica di migrazione di snapshot DB di Amazon RDS per eseguire la migrazione di uno snapshot DB Amazon RDS for PostgreSQL in Amazon Aurora usando la Console di gestione AWS. Nella maggior parte dei casi, il processo di migrazione viene completato in meno di un'ora; la durata effettiva dipende tuttavia dal formato e dalle dimensioni del set di dati. Per migrare le applicazioni SQL Server in Aurora nell'edizione compatibile con PostgreSQL, puoi utilizzare Babelfish per Aurora PostgreSQL. Consulta la pagina delle caratteristiche di Babelfish per maggiori informazioni.

D: Amazon Aurora partecipa al piano gratuito di AWS?

No, al momento no. Il piano gratuito di AWS per Amazon RDS offre vantaggi per micro-istanze di database. Attualmente, Amazon Aurora non offre alcun supporto per le micro-istanze di database. Consulta la pagina dei prezzi di Aurora per informazioni aggiornate.

D: Cosa sono gli I/O in Amazon Aurora e come vengono calcolati?

Gli I/O sono operazioni di input/output eseguite dal motore di database Aurora nel relativo livello di archiviazione virtualizzato basato su unità di memoria a stato solido (SSD). Ogni operazione di lettura delle pagine del database viene considerata un I/O. Il motore di database Aurora esegue le letture nel layer di storage per recuperare le pagine del database non presenti in memoria nella cache. Se il traffico di query può essere fornito totalmente dalla memoria o dalla cache, non ti sarà addebitato alcun costo per il recupero delle pagine di dati dalla memoria. Se il traffico di query non può essere fornito totalmente dalla memoria, ti saranno addebitati dei costi per ogni pagina di dati che sarà necessario recuperare dall'archiviazione. Ogni pagina di database è di 16 KB in Aurora nell'edizione compatibile con MySQL e 8 KB in Aurora nell'edizione compatibile con PostgreSQL. 

Aurora è stato sviluppato in modo da eliminare le operazioni di I/O non necessarie e pertanto ridurre i costi e garantire la disponibilità delle risorse per la gestione del traffico di lettura/scrittura. Gli I/O di scrittura vengono consumati solo quando vengono rieseguiti registri su Aurora nell'edizione compatibile con MySQL o quando vengono scritti in anticipo registri di log su Aurora nell'edizione compatibile con PostgreSQL nel livello di archiviazione con lo scopo di rendere le scritture durevoli. Gli I/O di scrittura vengono conteggiati in unità da 4 KB. Ad esempio, un registro di log la cui dimensione è pari a 1.024 byte verrà considerato come una operazione di I/O. Tuttavia, se il registro di log è più grande di 4 KB, sarà necessaria più di un’operazione di I/O per conservarlo. Operazioni di scrittura simultanee i cui registri di log sono inferiori a 4 KB vengono raggruppate in batch dal motore di database di Aurora per ottimizzare l’utilizzo I/O, se sono conservate negli stessi gruppi di protezione archiviazione. Diversamente dai tradizionali motori di database, Aurora non scarica pagine di dati sporche nell'archiviazione. È possibile visualizzare il numero di richieste I/O utilizzate da un'istanza di Aurora nella Console di gestione AWS. È possibile visualizzare il numero di richieste I/O utilizzate da un'istanza di Aurora nella Console. Per verificare il consumo degli I/O, passa alla sezione Amazon RDS della console, controlla l'elenco delle istanze, seleziona le istanze di Aurora, quindi verifica i parametri "Operazioni di lettura fatturate" e "Operazioni di scrittura fatturate" nella sezione relativa al monitoraggio.

D: È necessario modificare i driver del client per utilizzare Amazon Aurora nell'edizione compatibile con PostgreSQL?

No, Amazon Aurora è compatibile con i driver standard del database PostgreSQL.

Prestazioni

D: Cosa significa "prestazioni cinque volte superiori rispetto a MySQL"?

Amazon Aurora garantisce incrementi significativi a livello di prestazioni rispetto a MySQL grazie all'integrazione avanzata del motore del database con un livello di archiviazione virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, riducendo le operazioni di scrittura nel sistema di archiviazione, nonché il conflitto tra blocchi e permettendo l'eliminazione dei ritardi creati dai thread dei processi del database. I nostri test con SysBench su istanze r3.8xlarge hanno dimostrato che Amazon Aurora è in grado di offrire oltre 500.000 selezioni/sec e 100.000 aggiornamenti/sec, ovvero prestazioni cinque volte superiori allo stesso benchmark eseguito in MySQL con lo stesso hardware. Per istruzioni dettagliate su questo benchmark e su come replicarlo, consulta la Guida Amazon Aurora nell'edizione compatibile con MySQL Performance Benchmarking.

D: Cosa significa "prestazioni tre volte superiori rispetto a PostgreSQL"?

Amazon Aurora garantisce incrementi significativi a livello di prestazioni di PostgreSQL grazie all'integrazione avanzata del motore di database con un livello di archiviazione virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, alla riduzione delle operazioni di scrittura nel sistema di archiviazione, alla riduzione del conflitto tra blocchi e all'eliminazione dei ritardi creati dai thread dei processi del database. I nostri test con SysBench su istanze r4.16xlarge hanno dimostrato che Amazon Aurora è in grado di offrire selezioni/sec e aggiornamenti/sec oltre tre volte superiori allo stesso benchmark eseguito in PostgreSQL con lo stesso hardware. Per istruzioni dettagliate su questo benchmark e su come replicarlo, consulta la Guida Amazon Aurora nell'edizione compatibile con PostgreSQL Performance Benchmarking.

D: Come si ottimizza il carico di lavoro del database per Amazon Aurora nell'edizione compatibile con MySQL?

Amazon Aurora è compatibile con MySQL, perciò gli strumenti e le applicazioni MySQL esistenti potranno essere eseguiti senza alcuna modifica. Tuttavia, una delle aree in cui le prestazioni di Amazon Aurora risultano migliorate rispetto a MySQL è costituita dai carichi di lavoro a elevata simultaneità. Per ottimizzare la velocità effettiva del carico di lavoro in Amazon Aurora, consigliamo di costruire applicazioni in grado di gestire un numero elevato di query e transazioni simultanee.

D: Come si ottimizza il carico di lavoro del database per Amazon Aurora nell'edizione compatibile con PostgreSQL?

Amazon Aurora è compatibile con PostgreSQL, perciò gli strumenti e le applicazioni PostgreSQL esistenti potranno essere eseguiti senza alcuna modifica. Tuttavia, una delle aree in cui le prestazioni di Amazon Aurora risultano migliorate rispetto a PostgreSQL è costituita dai carichi di lavoro a elevata simultaneità. Per ottimizzare il throughput del carico di lavoro in Amazon Aurora, consigliamo di creare applicazioni in grado di gestire un numero elevato di query e transazioni simultanee.

Hardware e dimensionamento

D: Quali sono i limiti di archiviazione minimi e massimi di un database Amazon Aurora?

La soglia minima di archiviazione è pari a 10 GB. In base all'utilizzo del database, la capacità di archiviazione di Amazon Aurora aumenterà automaticamente fino a 128 TB, con incrementi di 10 GB senza alcuna conseguenza per le prestazioni del database. Non è necessario effettuare il provisioning di archiviazione in anticipo.

D: Come viene eseguito il dimensionamento delle risorse di calcolo associate all'istanza database Amazon Aurora?

Puoi utilizzare Aurora Serverless, una configurazione on demand a scalabilità automatica per Amazon Aurora, per dimensionare le risorse di calcolo del database in base alla domanda dell’applicazione. Consente di eseguire il tuo database nel cloud senza doverne gestire la capacità. Puoi specificare l’intervallo di capacità del database desiderato e il database verrà dimensionato in base alle necessità dell’applicazione. Scopri di più nella Guida per l’utente di Aurora Serverless.

Puoi anche dimensionare manualmente le risorse di calcolo associate al database selezionando il tipo di istanza database desiderato nella Console di gestione AWS. La modifica richiesta verrà applicata durante la finestra di manutenzione specificata oppure puoi utilizzare il flag "Applica immediatamente" per modificare immediatamente il tipo di istanza database. Durante l'esecuzione dell'operazione di dimensionamento entrambe queste opzioni incideranno sulla disponibilità per alcuni minuti. Tieni presente che verranno applicate anche tutte le altre modifiche di sistema in sospeso.

Backup e ripristino

D: Come vengono abilitati i backup per l'istanza di database?

Nelle istanze di database di Amazon Aurora i backup automatici sono sempre abilitati. I backup non hanno alcuna influenza sulle prestazioni del database.

D: È possibile creare snapshot DB e conservarli per tutto il tempo necessario?

Sì. La creazione di snapshot non ha alcuna influenza sulle prestazioni. Il ripristino dei dati mediante gli snapshot DB richiede tuttavia la creazione di una nuova istanza di database.

D: Se si verifica un errore del database, qual è il percorso di ripristino?

Amazon Aurora conserva automaticamente sei copie dei dati in tre zone di disponibilità e tenterà automaticamente di ripristinare il tuo database in una zona di disponibilità integra senza alcuna perdita di dati. Nel caso improbabile che i dati non siano disponibili nell'archiviazione di Amazon Aurora, è possibile eseguire il ripristino da uno snapshot DB oppure un'operazione di ripristino point-in-time in una nuova istanza. Tieni presente che l'intervallo ripristinabile massimo per un'operazione di ripristino point-in-time può essere pari a un intervallo massimo di 5 minuti nel passato.

D: Cosa accade ai backup e agli snapshot DB quando viene eliminata l'istanza di database?

È possibile scegliere di creare uno snapshot DB finale quando viene eliminata l'istanza di database. In questo caso, è possibile usare questo snapshot DB per ripristinare l'istanza di database eliminata in un secondo momento. Dopo l'eliminazione dell'istanza di database, Amazon Aurora conserva questo snapshot DB creato dall'utente finale insieme a tutti gli altri snapshot DB creati manualmente. Solo gli snapshot DB vengono conservati dopo l'eliminazione dell'istanza di database, ovvero i backup automatici creati per il ripristino point-in-time non vengono conservati.

D: È possibile condividere uno snapshot con un altro account AWS?

Sì. Aurora consente di creare snapshot dei database da utilizzare in un secondo momento per ripristinarli. Condividere uno snapshot con un altro account AWS è possibile; il proprietario del secondo account potrà usare lo snapshot per ripristinare un database contenente i tuoi dati. Puoi anche scegliere di rendere pubblici gli snapshot, in modo che chiunque possa ripristinare un database contenente i tuoi dati pubblici. Puoi utilizzare questa funzione per condividere i dati tra i vari ambienti (produzione, sviluppo/test, staging, ecc.) che hanno diversi account AWS, oltre a mantenere i backup di tutti i dati protetti in un account separato nell’improbabile caso in cui l'account AWS principale sia compromesso.

D: Quali costi vengono addebitati per gli snapshot condivisi?

Per condividere snapshot tra account diversi non viene addebitato alcun costo. Tuttavia, saranno addebitati i costi per gli snapshot e per i database ripristinati dagli snapshot condivisi. Per ulteriori informazioni, consulta la pagina dei prezzi di Aurora.

D: È possibile condividere snapshot in modo automatico?

La condivisione automatica di snapshot di database non è attualmente supportata. Per condividere automaticamente snapshot, è necessario crearne una copia e condividerla manualmente.

D: Con quanti account è possibile condividere snapshot?

È possibile condividere manualmente snapshot con un massimo di 20 ID account AWS. Se desideri condividere uno snapshot con più di 20 account, puoi condividerlo pubblicamente oppure contattare il supporto per modificare le limitazioni.

D: In quali regioni è possibile condividere gli snapshot di Aurora?

Gli snapshot di Aurora possono essere condivisi in tutte le regioni AWS in cui è disponibile Aurora.

D: È possibile condividere gli snapshot di Aurora tra regioni diverse?

No. Gli snapshot condivisi di Aurora saranno accessibili esclusivamente da account nella stessa regione dell'account che li condivide.

D: È possibile condividere uno snapshot di Aurora crittografato?

Sì, puoi condividere snapshot di Aurora crittografati.

Disponibilità elevata e replica

D: In che modo Amazon Aurora migliora la tolleranza ai guasti del database in caso di errori del disco?

Amazon Aurora suddivide automaticamente il volume del database in segmenti da 10 GB su più dischi. Ogni blocco da 10 GB di tale volume viene replicato sei volte in tre zone di disponibilità. Amazon Aurora è stato progettato per gestire in modo trasparente la perdita di un massimo di due copie di dati senza compromettere la disponibilità delle operazioni di scrittura del database e di un massimo di tre copie senza compromettere la disponibilità delle operazioni di lettura. Per lo storage di Amazon Aurora viene inoltre eseguita la riparazione automatica. I blocchi di dati e i dischi vengono analizzati continuamente alla ricerca di eventuali errori e riparati automaticamente.

D: In che modo Aurora migliora i tempi di ripristino dopo un arresto anomalo del database?

A differenza di altri database, dopo un arresto anomalo del database Amazon Aurora non deve rieseguire il log di ripristino dall'ultimo checkpoint del database (in genere cinque minuti) e confermare l'applicazione di tutte le modifiche prima di rendere disponibile il database per le operazioni. Ciò consente di ridurre i tempi di riavvio del database a meno di 60 secondi nella maggior parte dei casi. Amazon Aurora sposta la cache del buffer esternamente al processo del database e la rende subito disponibile al riavvio. Ciò evita di limitare l'accesso finché la cache non viene ripopolata per evitare sbalzi a livello di prestazioni.

D: Quali tipi di replica sono supportati da Aurora?

Amazon Aurora nell'edizione compatibile con MySQL e Amazon Aurora nell'edizione compatibile con PostgreSQL supportano le repliche di Amazon Aurora che condividono lo stesso volume sottostante dell’istanza primaria all’interno della stessa regione AWS. Gli aggiornamenti eseguiti dall'istanza primaria sono visibili in tutte le repliche di Amazon Aurora. Con Amazon Aurora nell'edizione compatibile con MySQL, è inoltre possibile creare repliche di lettura MySQL attraverso più regioni in base al motore di replica basato su binlog di MySQL. Nelle repliche di lettura di MySQL i dati provenienti dall'istanza primaria vengono riprodotti nella replica come transazioni. Per la maggior parte dei casi d'uso, compresi il dimensionamento delle operazioni di lettura e la disponibilità elevata, consigliamo di usare le repliche di Amazon Aurora.

È possibile combinare questi due tipi di replica con estrema flessibilità in base alle specifiche esigenze delle applicazioni:

Caratteristica Repliche di Amazon Aurora
Repliche di MySQL
Numero di repliche Fino a 15 Fino a 5
Tipo di replica Asincrona (millisecondi) Asincrona (secondi)
Impatto sulle prestazioni dell'istanza primaria Basso Elevate
Posizione della replica Nella regione
Tra più regioni
Funge da target di failover Sì (nessuna perdita di dati) Sì (potenziale perdita di alcuni minuti di dati)
Failover automatico No
Supporto del ritardo di replica definito dall'utente No
Supporto di dati o schemi diversi rispetto all'istanza primaria No

Hai a disposizione due ulteriori opzioni per effettuare delle repliche oltre a quelle elencate di sopra. Puoi utilizzare Amazon Aurora Global Database per repliche fisiche più veloci tra cluster di Aurora in regioni differenti. E per le repliche tra Aurora e database nell'edizione compatibile con MySQL diversi da Aurora (anche al di fuori di AWS), puoi impostare la tua replica di binlog personale auto-gestita.

D: È possibile creare repliche in più regioni con Amazon Aurora?

Sì, è possibile configurare repliche di Aurora in più regioni tramite replica logica o fisica. La replica fisica, definita Amazon Aurora Global Database, utilizza un'infrastruttura dedicata che lascia i database completamente disponibili al servizio dell’applicazione e può replicarsi in un massimo di cinque regioni secondarie con latenza tipica di meno di un secondo. È disponibile per Aurora nell'edizione compatibile con MySQL e Aurora nell'edizione compatibile con PostgreSQL. Per letture globali a bassa latenza e ripristino di emergenza, si consiglia di utilizzare Amazon Aurora Global Database.

Aurora supporta la replica logica nativa in ogni motore di database (binlog per MySQL e slot di replica PostgreSQL per PostgreSQL), permettendoti di replicare sui database Aurora e non, anche tra più regioni.

Aurora nell'edizione compatibile con MySQL offre anche una caratteristica di replica di lettura tra più regioni facile da utilizzare che supporta fino a cinque regioni AWS secondarie. Si basa su una replica binlog di MySQL a thread singolo; lo sfasamento della replica può variare in base alla frequenza di modifica/applicazione e ai ritardi a livello di comunicazione di rete tra le regioni selezionate.

È possibile creare repliche di Aurora su un cluster di replica su più regioni?

Sì, puoi aggiungere fino a 15 repliche di Aurora in ogni cluster su più regioni che condividerà la stessa archiviazione sottostante della replica corrispondente. Una replica su più regioni sarà quella principale sul cluster, mentre le repliche di Aurora nel cluster avranno in genere un ritardo rispetto alla replica principale di poche decine di millisecondi.

È possibile configurare il failover di un'applicazione dalla replica principale a una su più regioni?

Sì, puoi promuovere la replica su più regioni a replica principale tramite la console Amazon RDS. La durata del processo di promozione di replica logica (binlog) in genere è di pochi minuti e dipende dal carico di lavoro. La replica su più regioni verrà interrotta al momento dell'avvio del processo di promozione.

Amazon Aurora Global Database consente la promozione di una regione secondaria per eseguire carichi di lavoro di lettura/scrittura completi in meno di un minuto.

D: È possibile fornire una priorità maggiore ad alcune repliche in quanto target di failover?

Sì. È possibile assegnare un livello di priorità maggiore ad ogni istanza in un cluster. Quando si verifica un errore nell'istanza primaria, Amazon RDS promuove la replica con la priorità maggiore a istanza primaria. Se due o più repliche di Aurora hanno la stessa priorità, Amazon RDS dà precedenza alla replica di dimensioni più grandi. Se due o più repliche di Aurora hanno le stesse priorità e dimensioni, Amazon RDS dà precedenza in modo arbitrario a una replica nello stesso livello di promozione. Per ulteriori informazioni sulla logica di failover, consulta la guida per l’utente di Amazon Aurora.

D: È possibile modificare i livelli di priorità per le istanze dopo la loro creazione?

Sì, i livelli di priorità possono essere modificati in qualsiasi momento. La modifica dei livelli di priorità non attiverà un failover.

D: È possibile impedire ad alcune repliche di essere promosse a istanza primaria?

È possibile assegnare alle repliche che non desideri usare come istanze primarie un livello di priorità inferiore. Tuttavia, se le repliche con livelli di priorità maggiori nel cluster non sono integre o non sono disponibili, Amazon RDS promuoverà quelle repliche con priorità minore.

D: In che modo è possibile migliorare la disponibilità di un database di Amazon Aurora?

È possibile aggiungere repliche di Amazon Aurora. Le repliche di Aurora all’interno della stessa regione AWS condivideranno la stessa archiviazione sottostante dell’istanza primaria. Qualsiasi replica di Amazon Aurora può essere promossa di livello e impostata come replica primaria senza alcuna perdita di dati; quindi, essere usata per ottimizzare la tolleranza ai guasti in caso di errore di un'istanza di database primaria. Per migliorare la disponibilità del database, è sufficiente creare da una a 15 repliche in una qualsiasi delle tre zone di disponibilità. Amazon RDS includerà automaticamente tali repliche nella selezione primaria del failover in caso di interruzione della disponibilità del database.

È possibile utilizzare Amazon Aurora Global Database se si desidera che il database copra più regioni AWS. Ciò replicherà i dati senza alcun impatto sulle prestazioni del database e offre il servizio di ripristino di emergenza in caso di interruzioni a livello regionale.

D: Quali operazioni vengono eseguite durante un failover e con quale durata?

Il failover viene gestito automaticamente da Amazon Aurora, consentendoti di riprendere l'operatività del database con la massima rapidità senza alcun intervento manuale a livello amministrativo.

  • Se è disponibile una replica di Amazon Aurora nella stessa zona di disponibilità o in una zona diversa, in caso di failover Aurora fa in modo che il record di nome canonico (CNAME) dell'istanza di database punti alla replica integra, che a sua volta viene alzata di livello e impostata come nuova replica primaria. L'esecuzione completa dell'intero processo di failover in genere impiega meno di 30 secondi. 
  • Se Aurora Serverless è in esecuzione e l'istanza DB o la zona di disponibilità diventano non disponibili, Aurora ricrea automaticamente l'istanza DB in una zona di disponibilità diversa. 
  • Se non si dispone di una replica di Amazon Aurora (istanza singola) e se Aurora Serverless non è in esecuzione, Aurora tenterà di creare una nuova istanza database nella stessa zona di disponibilità dell'istanza originale. Questa sostituzione dell'istanza originale viene eseguita in base al tentativo migliore e potrebbe non avvenire, ad esempio, se si verifica un problema che interessa in qualche modo la zona di disponibilità.

L'applicazione deve tentare di ristabilire le connessioni al database in caso di perdita della connessione. Il servizio di disaster recovery in più regioni è un processo manuale, in cui si promuove una regione secondaria ad incaricata di carichi di lavoro di lettura/scrittura.

D: In presenza di un database primario e di una replica di Amazon Aurora che gestisce attivamente il traffico di lettura, cosa succede se si verifica un failover?

Amazon Aurora rileva automaticamente un problema relativo all'istanza primaria e attiva un failover. Se si sta utilizzando l'endpoint cluster, le tue connessioni di lettura/scrittura verranno automaticamente reindirizzate a una replica di Amazon Aurora che verrà promossa a primaria. Inoltre, il traffico di lettura gestito dalle repliche di Aurora verrà brevemente interrotto. Se si sta utilizzando l'endpoint di lettura del cluster per indirizzare il traffico in lettura alla replica di Aurora, le connessioni in sola lettura verranno orientate alla replica di Aurora appena promossa fino a quando il vecchio nodo primario non viene recuperato come replica.

D: Qual è il ritardo delle repliche rispetto all'istanza primaria?

Dal momento che le repliche di Amazon Aurora condividono lo stesso volume di dati dell'istanza primaria all’interno della stessa regione AWS, virtualmente non si verifica alcun ritardo di replica. In genere sono stati rilevati ritardi nell'ordine di decine di millisecondi. Per le repliche di lettura di MySQL, il ritardo di replica può aumentare in modo indefinito in base alla frequenza di modifica/applicazione e ai ritardi a livello di comunicazione di rete. Tuttavia, in condizioni standard è comune rilevare meno di un minuto di ritardo di replica.

Le repliche su più regioni che utilizzano la replica logica possono subire variazioni in base alla frequenza di modifica/applicazione e ai ritardi a livello di comunicazione di rete tra le regioni selezionate. Le repliche su più regioni che utilizzano Amazon Aurora Global Database hanno, in genere, uno sfasamento di meno di un secondo.

D: Posso impostare una replica tra il mio database Aurora nell'edizione compatibile con MySQL con e un database MySQL esterno?

Sì, puoi impostare repliche di binlog tra un'istanza di Aurora nell'edizione compatibile con MySQL e un database MySQL esterno. Può trattarsi di un altro database eseguito su Amazon RDS o un database auto-gestito su AWS o completamente al di fuori di AWS.

Se stai eseguendo Aurora nell'edizione compatibile con MySQL 5.7, considera di impostare una replica di binlog basata su GTID. Ciò ti permette di ottenere delle repliche omogenee senza perdere transazioni o generare conflitti, anche dopo failover o tempi di inattività.

D: Cos'è Amazon Aurora Global Database?

Amazon Aurora Global Database è una caratteristica che consente a un singolo database Amazon Aurora di coprire più regioni AWS. Replica i dati senza alcun impatto sulle performance del database, abilita letture locali veloci con, in genere, una latenza di meno di un secondo in ogni regione e assicura il servizio di ripristino di emergenza in caso di interruzioni a livello regionale. Nella rara eventualità di rallentamenti o interruzioni a livello regionale, una regione secondaria può ottenere il pieno delle capacità di lettura/scrittura in meno di un minuto.

Questa caratteristica è disponibile per Aurora nell'edizione compatibile con MySQL e Aurora nell'edizione compatibile con PostgreSQL.

D: Come si crea un Amazon Aurora Global Database?

È possibile creare un Aurora Global Database in pochi clic dalla console di Amazon RDS. In alternativa puoi usare il Software Development Kit (SDK) di AWS o l'interfaccia a riga di comando (CLI) di AWS. È necessario eseguire il provisioning di almeno un'istanza per regione nel tuo Amazon Aurora Global Database.

D: Quante regioni secondarie può avere un Amazon Aurora Global Database?

È possibile creare fino a cinque regioni secondarie per un Amazon Aurora Global Database.

D: Se utilizzo Amazon Aurora Global Database, posso usare anche la replica logica (binlog) sul database primario?

Sì. Se l’obiettivo è analizzare l'attività del database, valuta l'utilizzo della funzionalità di controllo avanzato di Aurora, dei log generali e dei log delle query lente, per evitare di influire sulle prestazioni del tuo database.

D: Aurora eseguirà automaticamente il failover su una regione secondaria di Amazon Aurora Global Database?

No. Nel caso in cui tua regione primaria non sia più disponibile, è possibile rimuovere manualmente una regione secondaria da Amazon Aurora Global Database e promuoverla per ottenere il pieno delle capacità di lettura/scrittura. Inoltre, è necessario l’indirizzamento della tua applicazione alla regione appena promossa.

D: Cos'è Amazon Aurora Multi-Master?

Amazon Aurora Multi-Master, è una nuova caratteristica dell'edizione di Aurora compatibile con MySQL che aggiunge la possibilità di dimensionare le prestazioni di scrittura in più zone di disponibilità, consentendo l'indirizzamento dei carichi di lavoro di lettura/scrittura da parte delle applicazioni a più istanze in un cluster di database e operazioni a disponibilità più elevata.

D: Che cosa occorre per cominciare a utilizzare Amazon Aurora Multi-Master?

La funzionalità Multi-Master di Amazon Aurora è ora disponibile al pubblico. Per ulteriori informazioni, consulta la documentazione di Amazon Aurora. Puoi creare un cluster Aurora Multi-Master in pochi clic sulla Console di Amazon RDS o scaricare gli SDK AWS o l'interfaccia a riga di comando più recenti.

Sicurezza

D: È possibile usare Amazon Aurora in Amazon Virtual Private Cloud (Amazon VPC)?

Sì. Tutte le istanze di database di Amazon Aurora devono essere create in VPC. Con Amazon VPC è possibile definire una topologia di rete virtuale molto simile a una rete tradizionale come quella che potrebbe essere gestita nel tuo data center. Questa soluzione offre il controllo completo sugli utenti che possono accedere ai database di Amazon Aurora.

D: I dati in transito o inattivi vengono crittografati da Amazon Aurora?

Sì. Amazon Aurora usa il protocollo SSL (AES-256) per mettere al sicuro la connessione tra istanza di database e applicazione. Amazon Aurora consente di crittografare i database usando le chiavi gestite mediante AWS Key Management Service (AWS KMS). In un'istanza di database eseguita con crittografia Amazon Aurora, i dati inattivi memorizzati nell'archiviazione sottostante sono crittografati, analogamente a quanto accade ai backup, alle repliche e agli snapshot corrispondenti nello stesso cluster. La crittografia e la decrittografia sono gestite in modo omogeneo. Per ulteriori informazioni sull'uso di AWS KMS con Amazon Aurora, consulta la Amazon RDS User's Guide.

D: È possibile crittografare un database non crittografato esistente?

Al momento la crittografia di un'istanza non crittografata esistente di Aurora non è supportata. Per usare la crittografia di Amazon Aurora su un database non crittografato esistente, è necessario creare una nuova istanza di database con la crittografia attivata in cui eseguire la migrazione dei dati.

D: Com'è possibile accedere al database di Amazon Aurora?

L'accesso ai database di Amazon Aurora deve essere eseguito mediante la porta di database specificata durante la creazione del database. Ciò garantisce un livello di sicurezza aggiuntivo per i dati. Per istruzioni dettagliate sulle modalità di collegamento al database di Amazon, consulta la Amazon Aurora Connectivity Guide.

D: È possibile usare Amazon Aurora con applicazioni che richiedono la conformità HIPAA?

Sì, le edizioni di Aurora compatibili con MySQL e PostgreSQL sono idonee per l'Health Insurance Portability and Accountability Act (HIPAA), quindi è possibile usarle per costruire applicazioni conformi allo standard HIPAA e archiviare informazioni sanitarie, fra cui i dati sanitari protetti (PHI) da un Business Associate Agreement (BAA) stipulato con AWS. Se è già stato stipulato un contratto BAA, non è necessaria alcuna operazione per iniziare a usare questi servizi negli account coperti dal contratto BAA. Per ulteriori informazioni sulla creazione di applicazioni conformi su AWS, consulta Operatori sanitari e assicuratori nel cloud.

D: Dove posso accedere a un elenco di voci CVE (Common Vulnerabilities and Exposures) per le vulnerabilità di sicurezza informatica pubblicamente note per le release di Amazon Aurora?

Al momento, un elenco di CVE è disponibile negli aggiornamenti di sicurezza Amazon Aurora.

Serverless

D: Cos'è Amazon Aurora Serverless?

Aurora Serverless è una configurazione a dimensionamento automatico on demand per Amazon Aurora. Consente di eseguire il tuo database nel cloud senza doverne gestire la capacità. La gestione manuale della capacità di un database può richiedere tempo prezioso e portare all'uso inefficiente delle risorse del database. Con Aurora Serverless è sufficiente creare un del database, specificare l’intervallo di capacità desiderato e connettere le applicazioni. Aurora regolerà automaticamente la capacità all'interno dell'intervallo specificato in base alle esigenze dell'applicazione. Pagherai al secondo per la capacità del database che utilizzi quando il database è attivo. Scopri di più su Aurora Serverless e inizia a utilizzarlo con pochi clic nella console di gestione Amazon RDS.

D: Qual è la differenza tra Aurora Serverless v2 e v1?

Aurora Serverless v2 supporta tutti i tipi di carico di lavoro del database, dagli ambienti di sviluppo e test, ai siti Web e alle applicazioni caratterizzati da carichi di lavoro non frequenti, intermittenti o imprevedibili fino alle applicazioni business-critical che richiedono scalabilità e disponibilità elevate. Si dimensiona in locale aggiungendo più CPU e memoria senza dover eseguire il failover del database su un'istanza di database più grande o più piccola. Di conseguenza, può dimensionarsi anche in presenza di transazioni di lunga durata, blocchi di tabelle, ecc. Inoltre, dimensiona la capacità del database con incrementi fino a 0,5 unità di capacità Aurora (ACU) in modo che la capacità del database corrisponda strettamente alle esigenze dell'applicazione.

Aurora Serverless v1 è una soluzione semplice ed economica per carichi di lavoro poco frequenti, intermittenti o imprevedibili. Si avvia automaticamente, dimensiona la capacità di calcolo in base all'utilizzo dell'applicazione e si arresta quando non è in uso. Consulta la Guida per l'utente di Aurora per ulteriori informazioni.

D: Quali sono le funzionalità di Aurora supportate da Aurora Serverless v2?

Aurora Serverless v2 supporta tutt l funzionalità di Aurora con provisioning, incluse la replica di lettura, la configurazione multi-AZ, database globale, proxy RDS e Performance Insights.

D: Posso iniziare a utilizzare Aurora Serverless v2 con il mio cluster database Aurora?

Sì, puoi iniziare a utilizzare Aurora Serverless v2 per gestire la capacità di calcolo del database nel cluster database Aurora esistente. Un cluster contenente sia le istanze con provisioning che Aurora Serverless v2 è noto come cluster a configurazione mista. Puoi scegliere di avere qualsiasi combinazione di istanze con provisioning e Aurora Serverless v2 nel tuo cluster. Per testare Aurora Serverless v2, aggiungi un lettore al tuo cluster di database Aurora e seleziona Serverless v2 come tipo di istanza. Una volta che il lettore è stato creato ed è disponibile, puoi iniziare a usarlo per carichi di lavoro di sola lettura. Dopo aver confermato che il lettore funziona come previsto, è possibile avviare un failover per iniziare a utilizzare Aurora Serverless v2 sia in lettura che in scrittura. Questa opzione fornisce un'esperienza di inattività minima per iniziare con Aurora Serverless v2.

D: Posso eseguire la migrazione da Aurora Serverless v1 ad Aurora Serverless v2?

Sì, puoi migrare da Aurora Serverless v1 a Aurora Serverless v2. Consulta la Guida per l'utente di Aurora per ulteriori informazioni.

D: Quali versioni di Amazon Aurora sono supportate per Aurora Serverless?

Aurora Serverless v2 è disponibile per l'edizione compatibile con MySQL di Amazon Aurora, a partire dalla versione 8.0 e per l'edizione compatibile con PostgreSQL, a partire dalla versione 13.5. Aurora Serverless v1 è disponibile per Aurora MySQL 5.6 e 5.7 e Aurora PostgreSQL 10.14.

D: Posso migrare un cluster DB Aurora esistente in Aurora Serverless?

Sì, è possibile ripristinare uno snapshot eseguito da un cluster Aurora esistente in un cluster DB Aurora Serverless (e viceversa).

D: Come posso connettermi a un cluster DB Aurora Serverless?

Puoi accedere a un cluster DB Aurora Serverless dall'interno di un'applicazione client eseguita nello stesso VPC. Non puoi assegnare un indirizzo IP pubblico a un cluster DB Aurora Serverless.

D: Posso impostare esplicitamente la capacità di un cluster Aurora Serverless?

Anche se Aurora Serverless dimensiona automaticamente in base al carico di lavoro attivo del database, in alcuni casi la capacità potrebbe non aumentare abbastanza velocemente per far fronte a un improvviso cambiamento del carico di lavoro, come ad esempio nel caso di un gran numero di nuove transazioni. In questi casi, è possibile impostare esplicitamente la capacità a un valore specifico con la Console di gestione AWS, AWS CLI o API Amazon RDS.

D: Perché il mio cluster DB Aurora Serverless non si dimensiona automaticamente?

Una volta avviata un'operazione di dimensionamento, Aurora Serverless tenta di trovare un punto di dimensionamento, ovvero un momento in cui il database può completarlo in modo sicuro. Aurora Serverless potrebbe non essere in grado di trovare un punto di dimensionamento se sono in corso query o transazioni di lunga durata, o se sono in uso tabelle temporanee o blocchi di tabelle.

D: Come mi viene fatturato Aurora Serverless?

In Aurora Serverless, la capacità del database viene misurata in unità di capacità di Aurora o ACU (Aurora Capacity Unit). Pagherai una tariffa fissa al secondo di utilizzo dell'ACU. Le tariffe di archiviazione e I/O sono le stesse per le configurazioni assegnate e serverless. Visita la pagina dei prezzi di Aurora per informazioni aggiornate sui prezzi e sulla disponibilità della regione AWS.

Query parallela

D: Cos'è Query parallela di Amazon Aurora?

Per Query parallela di Amazon Aurorasi intende la capacità di trasferire e distribuire il carico computazionale di una singola query attraverso migliaia di CPU sul layer di storage di Aurora. Senza Query parallela, una query inoltrata al database di Amazon Aurora sarebbe eseguita interamente all’interno di una sola istanza del cluster di database; questa operazione è simile al modo in cui opera la maggior parte dei database.

D: Cos'è il caso d’uso di destinazione?

Query parallela è adatta per carichi di lavoro analitici che richiedono dati aggiornati e buone prestazioni di query, anche su tabelle di grandi dimensioni. Carichi di lavoro di questo tipo sono solitamente di natura operativa.

D: Quali sono i vantaggi offerti da Query parallela?

Prestazioni più veloci dei risultati di Query parallela che accelerano le query analitiche fino a due ordini di grandezza. Offre anche semplicità operativa e aggiornamento dei dati: è possibile inviare una query direttamente sui dati transazionali attuali nel cluster Aurora. Inoltre, la Query parallela abilita carichi di lavoro transazionali e analitici nello stesso database consentendo ad Aurora di mantenere un'elevata velocità effettiva delle transazioni accanto alle query analitiche simultanee.

D: Quali query specifiche migliorano con Query parallela?

Ne possono trarre vantaggio la maggior parte delle query su insiemi di dati di grandi dimensioni che non sono già nel pool di buffer. La versione iniziale di Query parallela può spingere verso il basso e ridimensionare l'elaborazione di oltre 200 funzioni SQL, equijoins e proiezioni.

D: Qual è il miglioramento atteso nelle prestazioni?

Il miglioramento delle prestazioni di una query specifica dipende da quanto del piano di query può essere trasferito al livello di archiviazione Aurora. I clienti hanno segnalato miglioramenti superiori a un ordine di grandezza alla latenza delle query.

D: È possibile che le prestazioni siano inferiori?

Sì, ma prevediamo che si tratti di casi sporadici.

D: Quali modifiche è necessario apportare affinché una query tragga vantaggio dall'esecuzione di Query parallela?

Non è necessario apportare modifiche alla sintassi della query. Lo strumento di ottimizzazione delle query deciderà automaticamente se utilizzare Query parallela per una query specifica. Per verificare che una query utilizzi Query parallela, visualizzare il piano di esecuzione di query eseguendo il comando EXPLAIN. Se si desidera ignorare l'euristica e forzare Query parallela a scopo di test, utilizzare la variabile di sessione aurora_pq_force.

D: Come si attiva o disattiva la funzione?

Query parallela può essere abilitata e disabilitata dinamicamente a livello globale e di sessione utilizzando il parametro aurora_pq.

D: Ci sono altri costi aggiuntivi associati a Query parallela?

No, non viene addebitato nulla di diverso da quello che è già stato pagato per istanze, I/O e archiviazione.

D: Poiché la Query parallela riduce l'I/O, accendendola si ridurranno gli addebiti I/O di Aurora?

No, poiché la Query parallela riduce i costi di I/O per la query, vengono misurati al livello di archiviazione e saranno uguali o maggiori con la Query parallela attivata. Il vantaggio risiede nel miglioramento delle prestazioni di query. Esistono due ragioni per eventuali costi maggiori di I/O con Query parallela. Innanzitutto, anche se alcuni dei dati di una tabella si trovano nel pool di buffer, la Query parallela richiede che tutti i dati vengano scansionati nel livello di archiviazione, incorrendo nell'I/O. In secondo luogo, un effetto collaterale di evitare la contesa nel pool di buffer è che l'esecuzione di una Query parallela non scaldi il pool di buffer. Di conseguenza, le esecuzioni consecutive della stessa Query parallela comporteranno il costo di I/O completo.

D: Quale versione di Amazon Aurora supporta l'esecuzione di Query parallela?

Questa caratteristica è disponibile per la versione di Amazon Aurora compatibile con MySQL 5.6, a partire dalla versione 1.18.0. Abbiamo in programma di estenderla ad Aurora con compatibilità per MySQL 5.7 e ad Aurora nell'edizione compatibile con PostgreSQL.

D: Query parallela è disponibile per tutti i tipi di istanza?

No. Al momento, questa caratteristica è compatibile solo con le istanze della famiglia R.

D: Query parallela è disponibile per tutte le caratteristiche di Aurora?

Non all'inizio. Al momento, è possibile utilizzarle solo per i cluster di database che non eseguono anche funzioni Serverless o Backtrack. Inoltre, non supportano le funzioni specifiche di Aurora con compatibilità per MySQL 5.7.

D: Se Query parallela velocizza le query con perdite di prestazioni sporadiche, è consigliabile mantenere la funzione costantemente attiva per tutti i database?

No. Anche se questa caratteristica migliorerà la latenza delle query nella maggior parte dei casi, i costi di I/O saranno superiori. Consigliamo di testare un carico di lavoro con e senza la caratteristica. Una volta accertato che Query parallela sia la scelta giusta, è possibile utilizzare lo strumento di ottimizzazione delle query per decidere automaticamente a quali query applicare la funzionalità. Nella rara eventualità in cui lo strumento di ottimizzazione non sia la scelta ottimale, è possibile sovrascrivere l'impostazione.

D: Query parallela di Aurora può sostituire un data warehouse?

La Query parallela di Aurora non costituisce un data warehouse e non fornisce le funzionalità tipiche di tali sistemi. È progettato per migliorare le prestazioni delle query su database relazionali ed è ideale per casi d'uso come l'analisi operativa, in cui sia necessario eseguire rapidamente query analitiche su dati aggiornati nel database.

Amazon DevOps Guru per RDS

D: Cos'è Amazon DevOps Guru per RDS?

Amazon DevOps Guru per RDS è una nuova funzionalità basata sul ML per Amazon RDS che è progettata per rilevare automaticamente e diagnosticare le prestazioni del database e i problemi operativi, consentendo di risolvere i problemi in pochi minuti piuttosto che in giorni. Amazon DevOps Guru per RDS è una caratteristica di Amazon DevOps Guru, che è progettata per rilevare problemi operativi e di prestazioni per tutti i motori Amazon RDS e decine di altri tipi di risorse. DevOps Guru per RDS espande le capacità di DevOps Guru per rilevare, diagnosticare e rimediare a un'ampia varietà di problemi relativi al database in Amazon RDS (ad esempio, sovrautilizzo delle risorse e comportamento scorretto di alcune query SQL). Quando si verifica un problema, Amazon DevOps Guru per RDS è progettato per avvisare immediatamente gli sviluppatori e i tecnici DevOps e offre informazioni diagnostiche, dettagli sull'entità del problema e suggerimenti intelligenti di rimedio per aiutare i clienti a risolvere rapidamente i colli di bottiglia delle prestazioni e i problemi operativi legati ai database.

D: Perché dovrei usare DevOps Guru per RDS?

Amazon DevOps Guru per RDS è progettato per eliminare lo sforzo manuale e riduce il tempo (da ore e giorni a pochi minuti) per rilevare e risolvere i colli di bottiglia delle prestazioni difficili da individuare nel tuo carico di lavoro del database relazionale. Puoi abilitare DevOps Guru per RDS per ogni database Amazon Aurora per rilevare automaticamente i problemi di prestazioni dei tuoi carichi di lavoro, ti invierà avvisi su ogni problema, spiegherà i risultati e offrirà suggerimenti sulle operazioni per risolvere il problema. DevOps Guru per RDS aiuta a rendere l'amministrazione dei database più accessibile agli utenti non esperti e assiste gli esperti di database in modo che possano gestire ancora più database.

D: Come funziona Amazon DevOps Guru per RDS?

Amazon DevOps Guru per RDS utilizza il ML per analizzare i dati di telemetria raccolti da Amazon RDS Performance Insights (PI). DevOps Guru per RDS non usa nessuno dei tuoi dati archiviati nel database nella sua analisi. PI misura il carico del database, un parametro che caratterizza come un'applicazione passa il tempo nel database e i parametri selezionati generati dal database, come le variabili di stato del server in MySQL e le tabelle pg_stat in PostgreSQL.

D: Che cosa occorre per cominciare a utilizzare Amazon DevOps Guru per RDS?

Per iniziare a usare DevOps Guru per RDS, assicurati che Performance Insights sia abilitato attraverso la console RDS e poi abilita semplicemente DevOps Guru per i tuoi database Amazon Aurora. Con DevOps Guru, puoi scegliere che il limite di copertura dell'analisi sia il tuo intero account AWS, prescrivere gli stack specifici di AWS CloudFormation che vuoi che DevOps Guru analizzi, o usare i tag AWS per creare il raggruppamento di risorse che vuoi che DevOps Guru analizzi.

D: Quali tipi di problemi può rilevare Amazon DevOps Guru per RDS?

Amazon DevOps Guru per RDS aiuta a identificare una vasta gamma di problemi di prestazioni che possono influenzare la qualità del servizio dell'applicazione, come accumuli bloccati, tempeste di connessioni, regressioni SQL, conflitti tra CPU e I/O e problemi di memoria.

D: In cosa DevOps Guru per RDS è diverso da Amazon RDS Performance Insights?

Amazon RDS Performance Insights è una caratteristica per l’ottimizzazione e il monitoraggio delle prestazioni del database che raccoglie e visualizza parametri di prestazioni del database di Amazon RDS, consentendoti di valutare rapidamente il carico sul tuo database e di determinare quando e dove agire. Amazon DevOps Guru per RDS è progettato per monitorare questi parametri, rilevare quando il tuo database sta avendo problemi di prestazioni, analizzare i parametri e poi dirti cosa non funziona e cosa puoi fare al riguardo.

Ulteriori informazioni sui prezzi di Amazon Aurora

Visita la pagina dei prezzi
Tutto pronto per cominciare?
Inizia a usare Amazon Aurora
Hai altre domande?
Contattaci