Domande generali

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 TiB 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à (AZ).

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.

Amazon Aurora è 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. Questo rende facile lo spostamento delle applicazioni tra i due motori.

Puoi visualizzare le informazioni sulla compatibilità della versione corrente di Amazon Aurora MySQL nella documentazione.

Amazon Aurora è 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.

Puoi visualizzare le informazioni sulla compatibilità della versione corrente di Amazon Aurora PostgreSQL nella documentazione.

Amazon supporta pienamente Aurora PostgreSQL e tutte le estensioni disponibili con Aurora. Se occorre il supporto per Aurora PostgreSQL, contatta il Supporto AWS. Se disponi di un account attivo Supporto AWS Premium, potrai contattare Supporto AWS Premium per i problemi specifici di Amazon Aurora.

Come si inizia 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. Per indicazioni e risorse dettagliate, consulta la nostra pagina Nozioni di base su Amazon Aurora.

Quanto costa Amazon Aurora?

Per Aurora con provisioning puoi scegliere istanze on-demand e pagare una tariffa oraria per il database senza impegni a lungo termine, tariffe anticipate o ancora scegliere istanze riservate per salvataggi aggiuntivi. In alternativa, Aurora Serverless si avvia, si interrompe ed esegue automaticamente il dimensionamento della capacità in base alle esigenze dell'applicazione, pagando solo per la capacità consumata.

Consulta la pagina dei prezzi di Aurora per informazioni aggiornate.

Amazon Aurora replica ogni blocco del volume del database sei volte sulle tre zone di disponibilità. Ciò significa che l’effettivo prezzo di archiviazione sarà tre o sei volte il prezzo indicato sulla 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.

In quali regioni AWS è disponibile Amazon Aurora?

Puoi vedere la disponibilità regionale per Amazon Aurora qui.

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

Se vuoi migrare da MySQL ad Amazon Aurora (e viceversa), esistono diverse 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 per MySQL in Amazon Aurora usando la Console di gestione AWS.

Nella maggior parte dei casi, il processo di migrazione verso Aurora 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.

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

Se vuoi migrare da PostgreSQL ad Amazon Aurora (e viceversa), esistono diverse 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 per PostgreSQL in Amazon Aurora usando la Console di gestione AWS.

Nella maggior parte dei casi, il processo di migrazione verso Aurora 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 ad Aurora nell'edizione compatibile con PostgreSQL, puoi utilizzare Babelfish per Aurora PostgreSQL. Le tue applicazioni funzioneranno senza alcuna modifica. Per ulteriori informazioni, consulta la documentazione Babelfish.

Amazon Aurora partecipa al piano gratuito 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.
Per provare Amazon Aurora, accedi alla Console di gestione AWS, seleziona RDS nella categoria Database e scegli Amazon Aurora come motore di database.

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

È 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

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.

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.

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à di trasmissione effettiva del carico di lavoro in Amazon Aurora, consigliamo di creare applicazioni in grado di gestire un numero elevato di query e transazioni simultanee.

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 la velocità di trasmissione effettiva 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

: 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 TiB, con incrementi di 10 GB senza alcuna conseguenza per le prestazioni del database. Non è necessario effettuare il provisioning di archiviazione in anticipo.

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

Esistono due modi per ridimensionare le risorse di calcolo associate alla mia istanza di database Amazon Aurora: tramite Aurora Serverless e tramite regolazione manuale.

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

Come vengono abilitati i backup per l'istanza DB?

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

È 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 DB.

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à (AZ) 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 in un'operazione di ripristino point-in-time, è possibile il ripristino fino a un massimo di 5 minuti prima.

Cosa accade ai backup e agli snapshot DB quando viene eliminata l'istanza DB?

È possibile scegliere di creare uno snapshot DB finale quando viene eliminata l'istanza DB. 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 mantiene questo snapshot DB creato dall'utente finale insieme a tutti gli altri snapshot DB creati manualmente. Solo gli snapshot DB vengono mantenuti dopo l'eliminazione dell'istanza DB, ovvero i backup automatici creati per il ripristino point-in-time non vengono conservati.

Posso condividere i miei 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.

Vengono addebitati dei costi per gli snapshot condivisi?

Non viene addebitato alcun costo per la condivisione di istantanee tra account. 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.

Posso condividere gli snapshot in modo automatico?

La condivisione automatica di snapshot DB non è supportata. Per condividere uno snapshot, è necessario crearne una copia e condividerla manualmente.

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.

In quali regioni è possibile condividere gli snapshot di Aurora?

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

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

È possibile condividere uno snapshot di Aurora crittografato?

Sì, puoi condividere snapshot di Aurora crittografati.

Disponibilità elevata e replica

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.

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.

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

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

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

In quanto destinazioni di failover, alcune repliche possono avere la priorità su altre?

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.

Posso modificare i livelli di priorità per le istanze dopo la loro creazione?

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

Posso impedire che alcune repliche siano promosse a istanza primaria?

È possibile assegnare alle repliche che non desideri utilizzare 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.

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.

Cosa accade durante un failover e quanto dura?

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 ripristino di emergenza in più regioni è un processo manuale, in cui si promuove una regione secondaria ad incaricata di carichi di lavoro di lettura/scrittura.

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.

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 la replica in più regioni, il ritardo di replica logica basato sul log binario 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 fisica del Database globale Amazon Aurora hanno, in genere, uno sfasamento di meno di un secondo.

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

Cos'è il Database globale Amazon Aurora?

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

Come si crea un Database globale Amazon Aurora?

È possibile creare un Database globale Amazon Aurora 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 Database globale Amazon Aurora.

Quante regioni secondarie può avere un Database globale Amazon Aurora?

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

Se utilizzo il Database globale Amazon Aurora, 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.

Aurora eseguirà automaticamente il failover su una regione secondaria del Database globale Amazon Aurora?

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

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.

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

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

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 Servizio di gestione delle chiavi AWS (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 Guida per l’utente di Amazon RDS.

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

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.

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

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

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.

Qual è la differenza tra Aurora Serverless v2 e v1?

Aurora Serverless v2 supporta ogni tipo 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.

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

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

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.

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.

Quali versioni di Amazon Aurora sono supportate per Aurora Serverless?

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

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 fornire un indirizzo IP pubblico a un database Aurora Serverless.

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.

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.

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

Cos'è Query parallela di Amazon Aurora?

Per Query parallela di Amazon Aurora si 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.

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.

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.

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.

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.

È possibile che le prestazioni siano inferiori?

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

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.

Come posso attivare o disattivare la funzione Query parallela?

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

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.

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

No, i costi di I/O Query parallela per la query in questione vengono misurati al livello di storage e saranno uguali o maggiori con 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.

Ulteriori informazioni su Query parallela nella documentazione.

Query parallela è disponibile per tutti i tipi di istanza?

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

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

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.

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.

Per un data warehouse su cloud su scala exabyte, prendi in considerazione Amazon Redshift .

Amazon DevOps Guru per RDS

Cos'è Amazon DevOps Guru per RDS?

Amazon DevOps Guru per RDS è una nuova funzionalità basata su ML per Amazon RDS (che include Amazon Aurora) 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.

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.

Come funziona Amazon DevOps Guru per RDS?

Amazon DevOps Guru per RDS utilizza il ML per analizzare i dati di telemetria raccolti da Approfondimenti sulle prestazioni di Amazon RDS (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.

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.

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.

In cosa DevOps Guru per RDS è diverso da Approfondimenti sulle prestazioni di Amazon RDS?

Approfondimenti sulle prestazioni di Amazon RDS è 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