D: Cos'è Amazon Aurora?

Amazon Aurora è un motore di database relazionale che unisce la velocità e la disponibilità dei database commerciali di fascia alta alla semplicità e alla tariffa ridotta dei database open source. Amazon Aurora MySQL è in grado di offrire prestazioni cinque volte superiori rispetto a MySQL senza la necessità di modificare la maggior parte delle applicazioni MySQL; analogamente, Amazon Aurora PostgreSQL offre prestazioni tre volte superiori rispetto a PostgreSQL. Amazon RDS gestisce i database di Amazon Aurora per quanto riguarda le attività dispendiose a livello di tempo quali, ad esempio, il provisioning, l'applicazione di patch, il backup, il recupero, il rilevamento degli errori e la riparazione. Viene applicata una tariffa mensile per ogni istanza database di Amazon Aurora usata. Non sono previste tariffe minime né impegni anticipati.

D: Cosa significa "compatibile con MySQL"?

Significa che la maggior parte di codice, applicazioni, driver e strumenti usati con i database MySQL può essere usata con Aurora con modifiche minime o senza alcuna modifica. Il motore di database Amazon Aurora è stato progettato per essere compatibile a livello di cablaggio con MySQL 5.6 mediante il motore di storage InnoDB. Alcune funzionalità MySQL, ad esempio il motore di storage MyISAM, non sono disponibili con Amazon Aurora.

D: Cosa significa "compatibile con PostgreSQL"?

Significa che la maggior parte di codice, applicazioni, driver e strumenti usati con i database PostgreSQL può essere usata con Aurora con modifiche minime o senza alcuna modifica. Il motore di database Amazon Aurora è progettato per essere compatibile a livello di cablaggio con PostgreSQL 9.6 e supporta lo stesso set di estensioni PostgreSQL supportate con RDS per PostgreSQL 9.6, facilitando lo spostamento di applicazioni tra i due motori.  

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

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

D: Quanto costa Amazon Aurora?

Consulta la pagina dei prezzi 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?

No. La replica di Amazon Aurora è inclusa nel prezzo. Il costo verrà addebitato in base allo storage consumato dal database nel layer 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 per informazioni 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 funzionalità di migrazione di snapshot DB di RDS per eseguire la migrazione di uno snapshot DB MySQL RDS in Amazon Aurora usando la Console di gestione AWS. Per la maggior parte dei clienti il processo di migrazione viene completato in meno di un'ora, anche se la durata dipende dal formato e dalle dimensioni del set di dati. Per ulteriori informazioni, consulta Data Export and Import guide di 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 funzionalità di migrazione di snapshot DB di RDS per eseguire la migrazione di uno snapshot DB PostgreSQL 9.6 RDS in Amazon Aurora usando la Console di gestione AWS. Per la maggior parte dei clienti il processo di migrazione viene completato in meno di un'ora, anche se la durata dipende dal formato e dalle dimensioni del set di dati. Per ulteriori informazioni, consulta Data Export and Import guide di Amazon Aurora.

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 database. Attualmente, Amazon Aurora non offre alcun supporto per le micro-istanze database. Consulta la pagina dei prezzi 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 layer di storage virtualizzato basato su SSD. Ogni operazione di lettura delle pagine del database vengono considerate un I/O. Il motore di database Aurora esegue le letture nel layer di storage per recuperare le pagine del database non presenti nella cache del buffer. La dimensione di ogni pagina del database è pari a 16 KB in Aurora MySQL e pari a 8 KB in Aurora 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 usati solo durante l'invio dei record del log delle transazioni al layer di storage con lo scopo di rendere durevoli le letture. Gli I/O di scrittura vengono conteggiati in base a unità da 4 KB. Ad esempio, un record del log delle transazioni la cui dimensione è pari a 1024 byte verrà considerato come un'operazione di I/O. Tuttavia, le operazioni di scrittura simultanee i cui log delle transazioni hanno dimensioni minori di 4 KB possono essere combinate dal motore di database Aurora per ottimizzare il consumo degli I/O. A differenza dei motori di database tradizionali, Amazon Aurora non esegue mai il push delle pagine di database modificate nel layer di storage. Ciò consente di ridurre ulteriormente il consumo degli I/O.

È possibile visualizzare il numero di I/O consumati da un'istanza di Aurora nella console AWS. Per verificare il consumo degli I/O, passa alla sezione RDS della console, controlla l'elenco delle istanze, seleziona le istanze di Aurora e quindi verifica le metriche “Billed read operations” e “Billed write operations” nella sezione relativa al monitoraggio.

D: È necessario modificare i driver del client per utilizzare Amazon Aurora PostgreSQL?

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

D: Cos'è Amazon Aurora Serverless?

In occasione di re:Invent 2017, abbiamo annunciato l'anteprima di Amazon Aurora Serverless, una nuova configurazione dell'edizione compatibile con MySQL che consente un prezioso risparmio di tempo, fatica e costi aumentando o riducendo automaticamente la capacità del database in base alle esigenze della tua applicazione.

D: Che cosa occorre per cominciare a utilizzare Amazon Aurora Serverless?

Amazon Aurora Serverless è ora disponibile in anteprima per l'edizione di Amazon Aurora compatibile con MySQL. Puoi registrarti per richiedere la partecipazione. Annunceremo la disponibilità generale in data futura.

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

Amazon Aurora garantisce incrementi significativi a livello di prestazioni MySQL grazie all'integrazione avanzata del motore di database con un layer di storage virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, alla riduzione delle operazioni di scrittura nel sistema di storage, 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 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 Amazon Aurora MySQL Performance Benchmarking Guide.

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 layer di storage virtualizzato basato su SSD appositamente sviluppato per i carichi di lavoro del database, alla riduzione delle operazioni di scrittura nel sistema di storage, 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 Amazon Aurora PostgreSQL Performance Benchmarking Guide.

D: Come si ottimizza il carico di lavoro del database per Amazon Aurora MySQL?

Amazon Aurora è compatibile con MySQL 5.6. Gli strumenti e le applicazioni MySQL esistenti potranno pertanto essere eseguiti senza alcuna modifica. Tuttavia, una delle aree in cui le prestazioni di Amazon Aurora risultano migliorate in MySQL è 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.

D: Come si ottimizza il carico di lavoro del database per Amazon Aurora PostgreSQL?

Amazon Aurora è compatibile con PostgreSQL 9.6, 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 in 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.

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

Lo storage minimo è pari a 10 GB. In base all'uso del database, la capacità di storage di Amazon Aurora aumenterà automaticamente fino a 64 TB, in base a incrementi di 10 GB senza alcuna conseguenza per le prestazioni del database. Non è necessario effettuare il provisioning di ulteriori quantità di storage.

D: Come viene eseguito lo scaling delle risorse di elaborazione associate all'istanza database di Amazon Aurora?

È possibile eseguire lo scaling delle risorse di elaborazione allocate all'istanza database nella Console di gestione AWS selezionando l'istanza database desiderata, quindi facendo clic sul pulsante Modify. Per modificare le risorse di memoria e CPU, modificare la classe dell'istanza database.

Quando la classe dell'istanza database viene modificata, le modifiche richieste verranno applicate durante la finestra di manutenzione specificata. In alternativa, è possibile utilizzare il flag "apply-immediately" per rendere subito effettive le richieste di scaling. Durante l'esecuzione dell'operazione di scaling entrambe queste opzioni interesseranno la disponibilità per alcuni minuti. Tieni presente che verranno applicate anche tutte le altre modifiche di sistema in sospeso.

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

Nelle istanze 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 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 database in una zona di disponibilità integra senza alcuna perdita di dati. Nel caso improbabile che i dati non siano disponibili nello storage di Amazon Aurora, è possibile eseguire il ripristino da uno snapshot DB oppure un'operazione di ripristino point-in-time in una nuova istanza. È importante sottolineare 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 database?

È possibile scegliere di creare uno snapshot DB finale quando viene eliminata l'istanza database. In questo caso, è possibile usare questo snapshot DB per ripristinare l'istanza database eliminata in un secondo momento. Dopo l'eliminazione dell'istanza 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 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. Questa funzione è utile per condividere dati tra ambienti diversi (produzione, sviluppo/testing, ambienti temporanei e così via) con account AWS diversi, oppure per mantenere i backup di tutti i dati al sicuro in un account separato, nel caso l'integrità dell'account AWS principale dovesse venire compromessa.

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 creare una copia degli snapshot e condividerla manualmente.

D: Con quanti account è possibile condividere snapshot?

È possibile condividere manualmente snapshot con fino a 20 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.

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 5 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: Che tipi di replica sono supportati da Aurora?

Amazon Aurora MySQL e Amazon Aurora PostgreSQL supportano le repliche di Amazon Aurora che condividono lo stesso volume sottostante come istanza primaria. Gli aggiornamenti eseguiti dall'istanza primaria sono visibili in tutte le repliche di Amazon Aurora. Con Amazon Aurora MySQL, è inoltre possibile creare repliche di lettura MySQL 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 lo scaling 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:

Funzionalità Repliche di Amazon Aurora Repliche MySQL
Numero di repliche Fino a 15 Fino a 5
Tipo di replica Asincrona (millisecondi) Asincrona (secondi)
Impatto sulle prestazioni dell'istanza primaria Basso Elevato
Destinazione del 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

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

Sì, con Aurora MySQL puoi configurare repliche di Aurora su più regioni dalla console di RDS. La replica su più regioni 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. Aurora PostgreSQL attualmente non supporta la replica in più regioni.

D: È possibile creare repliche di lettura di Aurora su un cluster di replica su più regioni?
Sì, puoi aggiungere repliche di Aurora sul cluster che condividerà lo stesso storage della replica su più regioni. La replica su più regioni sarà quella principale sul cluster, mentre le replica di Aurora nel cluster avrà in genere un ritardo rispetto alla replica principale di poche decine di millisecondi.

D: È 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 RDS. La durata del processo 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.

D: È possibile fornire una priorità maggiore ad alcune repliche in quanto destinazioni 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 2 o più repliche hanno pari priorità, Amazon RDS promuoverà una replica con le stesse dimensioni dell'istanza da sostituire. Per ulteriori informazioni sulla logica di failover, consulta la Amazon Aurora User Guide.

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

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 integri o non sono disponibili, Amazon RDS promuoverà tali 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 Amazon Aurora condividono lo stesso storage sottostante dell'istanza primaria. Qualsiasi replica di Amazon Aurora può essere alzata di livello e impostata come replica primaria senza alcuna perdita di dati e quindi essere usata per migliorare la tolleranza ai guasti in caso di errore di un'istanza 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.

D: Quali operazioni vengono eseguite durante un failover e quanto dura?

Il failover viene gestito automaticamente da Amazon Aurora, consentendoti di riprendere l'operatività delle applicazioni 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 Amazon Aurora fa in modo che il record di nome canonico (CNAME) dell'istanza 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 non si dispone di una replica di Amazon Aurora (istanza singola), Aurora tenterà di creare una nuova istanza database nella stessa zona di disponibilità dell'istanza originale. Se risulta impossibile eseguire questa operazione, Aurora tenterà di creare una nuova istanza database in una zona di disponibilità diversa. L'esecuzione completa dell'intero processo di failover in genere impiega meno di 15 minuti.

L'applicazione deve tentare di ristabilire le connessioni al database in caso di perdita della connessione.

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 RDS rileverà automaticamente un problema a livello di istanza primaria e procederà a instradare il traffico di lettura/scrittura verso una replica di Amazon Aurora. In media questo tipo di failover viene completato in 30 secondi. Inoltre, il traffico di lettura gestito dalle repliche di Amazon Aurora verrà brevemente interrotto.

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, virtualmente non si verifica alcun ritardo di replica. In genere sono stati rilevati ritardi nell'ordine di decimi di millisecondo. 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.

D: Cos'è Amazon Aurora Multi-Master?

In occasione di re:Invent 2017, abbiamo annunciato l'anteprima per Amazon Aurora Multi-Master, una nuova funzionalità 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 di 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?

Amazon Aurora Multi-Master è ora disponibile in anteprima per l'edizione di Amazon Aurora compatibile con MySQL. Puoi registrarti per richiedere la partecipazione. Annunceremo la disponibilità generale in data futura.

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

Sì. Tutte le istanze database di Amazon Aurora devono essere create in VPC. Con Amazon VPC, è possibile definire una topologia di rete virtuale simile a una rete tradizionale che si potrebbe gestire nel proprio 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 (KMS). In un'istanza database eseguita con crittografia Amazon Aurora, i dati inattivi memorizzati nello storage sottostante sono criptati, 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 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 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. In questo modo viene fornito un layer di sicurezza aggiuntivo per i dati. Per istruzioni dettagliate sulle modalità di collegamento al database di Amazon, consulta la Amazon Aurora Connectivity Guide.

D: Per quali dimensioni delle istanze sarà disponibile Performance Insights?

Per tutte le dimensioni, ad eccezione delle micro-istanze. Di pari passo con l'introduzione di nuove dimensioni delle istanze da parte di RDS, Performance Insights sarà disponibile per quelle dotate di prestazioni sufficienti.

D: Quando sarà disponibile Performance Insights per RDS per PostgreSQL, Aurora MySQL, RDS per MySQL, RDS per Oracle, RDS per SQL Server e RDS per MariaDB?

Performance Insights sarà inizialmente disponibile in Aurora PostgreSQL e, a breve, anche in Aurora MySQL. Ulteriori motori verranno aggiunti nel corso del tempo.

D: In che modo Performance Insights mostra la causa dei problemi di prestazioni?

I problemi di prestazioni appaiono nella sezione Performance Insights della console RDS come picchi nel grafico di carico del database. Un'occhiata a questo grafico può permettere di capire subito su quale tipo di risorse la tua applicazione impiega tempo e risorse nel database. La console consente di allargare qualsiasi periodo all'interno del periodo di retention. Selezionando i periodi di carico elevato, i clienti possono visualizzare un elenco di istruzioni SQL, ordinate per contributo complessivo al carico.

D: In che modo Performance Insights ottiene informazioni sul carico nella mia istanza database RDS?

Performance Insights esegue il campionamento dello stato di tutte le sessioni connesse nella tua istanza database ogni secondo. Se una sessione dedica tempo a un'operazione relativa al database, Performance Insights registra il tempo di campionamento, il tipo di operazione (I/O, CPU, blocco, ecc.), l'istruzione SQL attuale e vari altri attributi delle sessioni. Su determinati periodi di tempo, questi dati campione vengono utilizzati per definire il modo in cui le sessioni contribuiscono al carico nella tua istanza database.

D: È possibile eseguire query sui dati delle prestazioni dall'interno dell'istanza RDS?

No. Il processo di campionamento di Performance Insights non compila alcuna tabella nel database e non presenta i dati da recuperare dall'interno del database tramite SQL.

Q: È possibile visualizzare che cosa succede nella mia istanza in tempo reale?

Sì. Come impostazione predefinita, Performance Insights visualizza una finestra mobile di un'ora di dati delle prestazioni. La caratteristica è progettata per presentare le più recenti informazioni sulle prestazioni entro pochi secondi dalla realtà.

D: Quanto costa Performance Insights?

Performance Insights include 24 ore di dati memorizzati e accesso alla console. Durante l'anteprima, Performance Insights offre un piano gratuito che include l'ultimo periodo di 24 ore di memorizzazione dei dati. I prezzi per la memorizzazione dei dati per una durata superiore saranno annunciati in seguito.

D: Fino a quanto tempo indietro posso risalire per osservare i dati delle prestazioni archiviati in Performance Insights?

Puoi osservare 24 ore di cronologia delle prestazioni. Opzioni per una memorizzazione di maggior durata saranno annunciate in data futura.

D: Posso disattivare Performance Insights sulle nuove istanze, anche se è attivato come impostazione predefinita?

Sì. L'opzione per Performance Insights è selezionata come impostazione predefinita nella console AWS quando utilizzi la procedura guidata per la creazione dell'istanza. Puoi deselezionare l'opzione nella procedura guidata per impedire l'attivazione di Performance Insights, oppure puoi disattivare Performance Insights in un'istanza abilitata modificando l'istanza stessa.

D: Performance Insights funziona sulle istanze database RDS che utilizzano uno storage crittografato?

Sì. Performance Insights non legge i dati che archivi nel tuo database.

D: Qual è il carico di database e perché costituisce la misura primaria utilizzata in Performance Insights per rilevare i problemi di prestazioni?

Il carico del database è una serie temporale che mostra la quantità di tempo impiegata dalle applicazioni del cliente sul database e il modo in cui tale tempo viene impiegato. Il carico del database viene misurato in unità di sessioni medie attive (AAS). Una sessione attiva è una connessione (sessione) che ha inviato del lavoro al motore di database ed è in attesa di una sua risposta. Ad esempio, se invii un'istruzione SQL a un'istanza di database, quella sessione viene considerata "attiva" durante il periodo di tempo in cui l'istanza elabora tale query. Contando il numero di sessioni attive in un'istanza in un momento dato, siamo in grado di fornire un parametro che, una volta eseguita la media sui periodi di tempo, può illustrare quanto sia impegnata un'istanza e quanto tempo dedichino le sessioni ad attendere una risposta dell'istanza: questo rappresenta il carico del database. Performance Insights conta le sessioni attive e registra gli attributi di ciascuna sessione circa ogni secondo, utilizzando un meccanismo di campionamento leggero. I dati campione vengono crittografati e aggregati a una varietà di granularità, quindi serviti nel grafico di carico del database. Gli utenti della console possono selezionare il periodo di tempo che desiderano visualizzare.

D: Devo effettuare qualche operazione particolare nel mio database per abilitare Performance Insights?

No. Tuttavia, Performance Insights funzionerà ancora meglio in alcuni motori di database quando è attivo il monitoraggio aggiuntivo delle prestazioni. Ad esempio, quando l'estensione pg_stat_statement è attivata in RDS PostgreSQL o Aurora PostgreSQL, Performance Insights utilizzerà l'identificatore SQL nativo di PostgreSQL per individuare l'istruzione e sarà in grado di raccogliere il testo completo di istruzioni più lunghe. In MySQL, l'attivazione di Performance Schema consentirà a Performance Insights di raccogliere contenuti più ricchi e approfonditi sugli eventi di attesa che influiscono sul database.

D: L'attivazione di Performance Insights influirà negativamente sulle prestazioni del mio database?

L'agente di Performance Insights è progettato per rimanere lontano dai carichi di lavoro dei database. Performance Insights è in esecuzione a una priorità inferiore rispetto agli altri processi della tua istanza e monitora la salute dell'host e del database. Quando Performance Insights rileva un carico pesante o risorse in esaurimento, si allontana dalla normale frequenza di raccolta dei dati, continuando a raccoglierli ma solo quando ciò può essere fatto in sicurezza. Le opzioni database, come pg_stat_statement in RDS PostgreSQL e Aurora Postgres e Performance Schema in MySQL possono utilizzare alcune risorse di database e influire potenzialmente sulle prestazioni. L'influenza o meno di queste opzioni su un particolare sistema dipenderà dal carico di lavoro dell'applicazione. AWS raccomanda di testare tutte le opzioni di database sul carico di lavoro prima di abilitarle su un sistema di produzione.

D: Devo continuare a utilizzare Enhanced Monitoring o solo Performance Insights?

I clienti che utilizzano Enhanced Monitoring per monitorare parametri O/S dovrebbero continuare a ottenere i dati tramite Enhanced Monitoring. Nei prossimi mesi, tali dati, così come un'ampia serie di parametri di database, saranno inoltre disponibili tramite la console Performance Insights e un'API. A quel punto, i clienti potranno ottenere tutti i dati delle prestazioni da Performance Insights. Enhanced Monitoring rimarrà disponibile per i clienti che preferiscano utilizzarlo, ma invitiamo i clienti a standardizzare il monitoraggio dei propri database su Performance Insights.

D: I dati archiviati in Performance Insights sono crittografati?

Sì. Performance Insights crittografa tutti i dati potenzialmente sensibili utilizzando la tua chiave KMS personale. Vengono crittografati i dati memorizzati e in movimento. Il personale di AWS non è in grado di accedere o visualizzare alcun dato potenzialmente sensibile sulle prestazioni. Solo gli utenti del tuo account AWS con pieno accesso a RDS potranno visualizzare Performance Insights. Puoi revocare la concessione di RDS per la tua chiave KMS, che ci consente di elaborare e visualizzare i dati delle tue prestazioni in qualsiasi momento.

D: Se disattivo Performance Insights, AWS conserva i dati o vengono eliminati?

Il piano gratuito di memorizzazione dei dati delle prestazioni è limitato a un giorno. La disattivazione di Performance Insights in un'istanza determina l'eliminazione dei dati delle tue prestazioni per quell'istanza.

D: Che cosa succede alla memorizzazione dei dati di Performance Insights quando arresto la mia istanza di database RDS?

L'arresto di un'istanza RDS in cui è attivato Performance Insights non ha effetto sulla memorizzazione o la visibilità dei dati cronologici per quell'istanza. Il periodo durante il quale l'istanza è stata arrestata semplicemente non conterrà dati.

D: Come posso interfacciare Performance Insights con i miei strumenti delle prestazioni esistenti?

In futuro, Performance Insights renderà pubblicamente disponibile un'API progettata per consentire a clienti e terze parti di sfruttare i preziosi dati di Performance Insights.

D: Esiste un modo per integrare gli strumenti delle prestazioni di terze parti con Performance Insights?

In futuro, Performance Insights renderà pubblicamente disponibile un'API progettata per consentire a clienti e terze parti di sfruttare i preziosi dati di Performance Insights.

D: Performance Insights sarà disponibile in tutte le regioni AWS in cui è disponibile RDS?

Sì. Performance Insights sarà inizialmente disponibile in quattro regioni: Stati Uniti orientali (Virginia settentrionale, Ohio), Stati Uniti occidentali (Oregon) e UE (Irlanda). Nel corso del tempo, la caratteristica sarà resa disponibile in tutte le regioni in cui RDS è supportato.

D: Posso attivare Performance Insights anche sulle istanze esistenti o solo su quelle nuove?

Sì, è possibile attivare Performance Insights sulle istanze esistenti modificando l'istanza per abilitare Performance Insights. Può essere attivato sulle nuove istanze specificando che Performance Insights deve essere attivato al momento della creazione dell'istanza.

D: Performance Insights utilizza parte dello storage della mia istanza di database?

No, Performance Insights non consuma spazio di archiviazione nelle istanze RDS.

D: Quali saranno le differenze, se presenti, di Performance Insights nell'esecuzione in diversi motori di database?

Performance Insights è progettato per presentare un approccio e un aspetto comuni per la sintonizzazione di tutti i motori di database in RDS. Dal momento che determinati attributi, come gli eventi di attesa e gli identificatori SQL, variano in base al tipo di motore, naturalmente varieranno anche in Performance Insights, durante il lavoro con diversi motori di database. Uno dei principi fondanti di Performance Insights è il fatto che concetti, identificatori e attributi di un motore di database devono rimanere intatti. In generale, Performance Insights non reinterpreta o rinomina gli eventi di attesa in altri attributi specifici dei motori, ma li presenta fedelmente, così come indicati dal motore di database.

D: Performance Insights funziona sulle istanze Multi-AZ e sulle istanze di replica di lettura?

Sì. Se un database RDS utilizza Multi-AZ e ha attivato Performance Insights, allora Performance Insights rimarrà attivato quando e se tale istanza esegue il failover sull'altra zona di disponibilità. Dal momento che le repliche di lettura sono istanze indipendenti, i clienti possono attivare o disattivare Performance Insights in quelle istanze.

D: Posso esportare i miei dati da Performance Insights?

In futuro, Performance Insights aggiungerà la funzionalità di esportazione dei dati.

D: Posso reimportare i miei dati in Performance Insights successivamente, al fine di eseguire l'analisi delle prestazioni?

No. Performance Insights visualizza solo i dati raccolti direttamente da un'istanza. I dati ottenuti mediante Performance Insights saranno disponibili nei mesi a venire tramite un'API, quindi l'analisi potrà essere effettuata utilizzando uno dei servizi orientati all'analisi in AWS, quali Amazon Athena, Amazon Redshift, Amazon Redshift Spectrum e Amazon QuickSight.