Domande frequenti su HAQM RDS per MySQL

Attualmente, il database relazionale di HAQM (HAQM RDS) per MySQL supporta le versioni 8.4 e 8.0 di MySQL Community Edition. RDS per MySQL supporta anche MySQL 5.7 con il supporto esteso di RDS. Maggiori informazioni sulle versioni secondarie supportate sono disponibili nella Guida per l'utente di HAQM RDS.

In MySQL i numeri di versione sono strutturati come segue:
Versione MySQL = X.Y.Z

X = Versione principale, Y = Livello release, Z = Numero di versione in una serie di release.
Dal punto di vista di HAQM RDS, una modifica della versione è considerata principale se viene modificata la versione principale o il livello di release. Ad esempio l'aggiornamento dalla versione 5.6.X alla versione 5.7.X.

Una modifica della versione è considerata secondaria se viene modificato solo il numero di versione della release. Ad esempio l'aggiornamento dalla versione 5.6.27 alla versione 5.6.29.

Sì. Consulta le Domande frequenti su HAQM RDS.

Il ripristino point-in-time, il ripristino degli snapshot e l'integrazione Zero-ETL con le funzionalità di HAQM Redshift di HAQM RDS per MySQL richiedono un motore di archiviazione da poter ripristinare in caso di anomalie e sono supportati solo per il motore di archiviazione InnoDB. MySQL supporta più motori di archiviazione con funzionalità diverse, ma non tutti sono ottimizzati per il ripristino da arresto anomalo e la durata dei dati. Ad esempio, il motore di archiviazione MyISAM non supporta il ripristino per arresto anomalo in modo affidabile e può causare la perdita o il danneggiamento dei dati al riavvio di MySQL dopo un arresto anomalo, impedendo il regolare ripristino delle funzionalità point-in-time o snapshot. Tuttavia, scegliendo di utilizzare MyISAM con HAQM RDS, in alcuni scenari può essere utile seguire queste fasi per la funzionalità di ripristino dello snapshot del database. Il Federated Storage Engine non è attualmente supportato da RDS per MySQL.

Creando una nuova istanza del database, l'utente primario predefinito ottiene determinati privilegi. Per un elenco dei privilegi, consulta Privilegi dell'account utente master nella Guida per l'utente di HAQM RDS.

Le repliche di lettura di RDS per MySQL necessitano di un motore di archiviazione transazionale e sono supportate solo per il motore di archiviazione InnoDB. I motori di archiviazione MySQL non transazionali come MyISAM potrebbero impedire il corretto funzionamento delle repliche di lettura. Se tuttavia intendi comunque utilizzare MyISAM con le repliche di lettura, ti consigliamo di tenere sotto controllo il parametro "Replica Lag" di HAQM CloudWatch (disponibile tramite la Console di gestione AWS o le API di HAQM CloudWatch) e ricreare la replica di lettura nel caso rimanesse bloccata a causa di errori durante le operazioni di replica. Le stesse considerazioni valgono per l'utilizzo di tabelle temporanee e altri motori non transazionali.

È possibile impostare il formato di registrazione di log binari come basato su riga per le versioni 5.6 e successive di MySQL. Per impostazione predefinita, la replica è configurata in formato misto, ovvero include operazioni sia basate su righe sia basate su istruzioni; questa impostazione consente di soddisfare i requisiti della maggior parte dei casi d'uso. Per ulteriori informazioni sulla differenza tra formato misto e replica basata su righe, consulta la documentazione di MySQL.

Le implementazioni blu/verdi di HAQM RDS sono disponibili in RDS per le versioni di MySQL 5.7 e successive. Puoi trovare ulteriori informazioni sulle versioni disponibili nella documentazione di RDS per MySQL.

Le implementazioni blu/verdi di HAQM RDS sono disponibili in tutte le Regioni AWS (escluse le Regioni AWS Cina) e nelle Regioni AWS GovCloud.

Le implementazioni blu/verde di HAQM RDS consentono di apportare modifiche più sicure, semplici e rapide al database; ad esempio, aggiornamenti di versioni principali o secondarie, modifiche dello schema, ridimensionamento delle istanze, modifiche dei parametri del motore e aggiornamenti di manutenzione.

Le implementazioni blu/verdi di HAQM RDS consentono di effettuare aggiornamenti del database più sicuri, semplici e veloci senza alcuna perdita di dati. Le implementazioni blu/verdi sono delle versioni principali o secondarie, aggiornamenti del sistema operativo, modifiche allo schema in ambienti verdi che non interrompono la replica logica, come l'aggiunta di una nuova colonna alla fine di una tabella o le modifiche alle impostazioni dei parametri del database. È possibile utilizzare le implementazioni blu/verdi per effettuare più aggiornamenti del database contemporaneamente utilizzando un unico switchover. Ciò consente di rimanere aggiornati sulle patch di sicurezza, migliorare le prestazioni del database e accedere alle nuove funzionalità del database con tempi di inattività brevi e prevedibili.

L'esecuzione dei tuoi carichi di lavoro sulle istanze verdi avrà lo stesso prezzo di quella sulle istanze blu. Il costo dell'esecuzione su istanze blu e verdi include i nostri attuali prezzi standard per db.instance, il costo dell'archiviazione, il costo degli I/O di lettura/scrittura e di qualsiasi funzionalità abilitata, come il costo dei backup e degli Approfondimenti sulle prestazioni di HAQM RDS. Di fatto, per tutta la durata dell'implementazione blu/verde ti troverai a pagare circa il doppio del costo dell'esecuzione dei carichi di lavoro su db.instance.

Ad esempio: disponi di un database RDS per MySQL 5.7 in esecuzione su due db.instance r5.2xlarge (un'istanza di database primaria e una replica di lettura), nella regione AWS us-east-1 con una configurazione multi-AZ (MAZ). Ognuna delle db.instance r5.2xlarge è configurata per HAQM Elastic Block Store (HAQM EBS) per uso generico da 20 GiB. Crei un clone della topologia dell'istanza blu utilizzando implementazioni blu/verdi di HAQM RDS, lo esegui per 15 giorni (360 ore) e poi elimini le istanze blu una volta completato lo switchover. Le istanze blu costano 1,387 USD per 15 giorni a una tariffa on demand di 1,926 USD/ora (istanza+costo di EBS). Il costo totale per l'utilizzo delle implementazioni blu/verdi per quei 15 giorni è di 2,774 USD, che è il doppio del costo di esecuzione delle istanze blu per un tale periodo di tempo.

Le implementazioni blu/verde di HAQM RDS consentono di apportare modifiche più sicure, semplici e rapide al database; ad esempio, aggiornamenti di versioni principali o secondarie, modifiche dello schema, ridimensionamento delle istanze, modifiche dei parametri del motore e aggiornamenti di manutenzione.

Quando le implementazioni blu/verdi di HAQM RDS avviano un passaggio, le scritture negli ambienti blu e verdi vengono bloccate fino al completamento del processo. Durante il passaggio, l'ambiente di staging (o ambiente verde) raggiunge l'ambiente blu, garantendo la coerenza dei dati tra gli ambienti blu e verde. Una volta che l'ambiente blu e quello verde sono completamente sincronizzati, le implementazioni blu/verdi promuovono l'ambiente verde come nuovo ambiente blu, reindirizzando il traffico verso l'ambiente verde. Le implementazioni blu/verdi sono progettate per abilitare le scritture nell'ambiente verde dopo che il passaggio è stato completato, prevenendo la perdita di dati durante il processo di passaggio.

Se il tuo ambiente blu è una replica logica autogestita o un abbonato, bloccheremo lo switchover. Si consiglia di interrompere prima la replica nell'ambiente blu, procedere con lo switchover e quindi riprendere la replica. Al contrario, se l'ambiente blu è l'origine di una replica logica autogestita o di un publisher, è possibile continuare con lo switchover. Tuttavia, sarà necessario aggiornare la replica autogestita per eseguire la replica dall'ambiente verde dopo lo switchover.

Le implementazioni blu/verdi di HAQM RDS non cancellano il tuo vecchio ambiente di produzione. Se necessario, puoi accedervi per ulteriori convalide o per effettuare test di regressione o sulle prestazioni. Se non hai più bisogno del vecchio ambiente di produzione, puoi anche eliminarlo. Gli addebiti in fattura standard vengono applicati alle vecchie istanze di produzione fino a quando non le elimini.

La funzione dei guardrail nel processo di passaggio delle implementazioni blu/verdi di HAQM RDS è quella di bloccare la scrittura sugli ambienti blu e verde fino a quando l'ambiente verde non si riporta in pari prima del passaggio. Le implementazioni blu/verdi eseguono anche controlli dell'integrità del primario e delle repliche negli ambienti blu e verde. Inoltre, eseguono controlli dell'integrità della replica, ad esempio, per verificare se la replica è stata interrotta o se sono presenti errori. Rilevano transazioni di lunga durata tra i tuoi ambienti blu e verdi. Puoi specificare il tempo di inattività massimo tollerabile (fino a 30 secondi) e se la transazione in corso lo supera, il passaggio andrà in timeout.

No. Le implementazioni blu/verdi di HAQM RDS non supportano Server proxy per HAQM RDS, repliche di lettura tra Regioni o repliche di lettura a cascata.

No, al momento non puoi utilizzare le implementazioni blu/verdi di HAQM RDS per eseguire il rollback delle modifiche.

MySQL protegge gli utenti dalla perdita di dati scrivendoli due volte in memoria (prima nel "buffer doublewrite" e poi nell'archiviazione tabelle) in pagine da 16 KiB, in un sistema di archiviazione durevole. Le scritture ottimizzate per HAQM RDS scrivono le pagine di dati da 16 KiB direttamente nei file di dati in modo affidabile e duraturo, in un solo passaggio, utilizzando la funzionalità Torn Write Prevention di AWS Nitro System.

Le scritture ottimizzate per HAQM RDS sono disponibili per la versione principale di MySQL 8.0.30 e successive.

Le scritture ottimizzate di HAQM RDS sono disponibili per le istanze db.r6i e db.r5b. Sono disponibili in tutte le Regioni in cui sono presenti queste istanze, escluse le Regioni AWS Cina.

È necessario che tutti gli utenti di RDS per MySQL implementino le scritture ottimizzate per HAQM RDS per una velocità di trasmissione effettiva delle transazioni di scrittura fino a due volte superiore. Le applicazioni che prevedono carichi di lavoro in scrittura pesanti, come i pagamenti digitali, il trading finanziario e le applicazioni di gioco online, troveranno questa funzionalità particolarmente utile.

No. HAQM Aurora edizione compatibile con MySQL evita a priori l'impiego del "buffer doublewrite". Infatti, Aurora replica i dati in sei modi diversi su tre zone di disponibilità (AZ) e utilizza un approccio basato sul quorum per scrivere i dati in modo duraturo e per leggerli correttamente in seguito.

Al momento, questa versione iniziale non supporta l'abilitazione delle scritture ottimizzate di HAQM RDS per le istanze di database esistenti, anche se la classe di istanza supporta le scritture ottimizzate.

Le scritture ottimizzate di HAQM RDS sono disponibili per i clienti di RDS per MySQL senza costi aggiuntivi.

I carichi di lavoro che utilizzano oggetti temporanei su MySQL per l'elaborazione delle query possono trarre beneficio dalle letture ottimizzate per HAQM RDS, che collocano oggetti temporanei nell'archiviazione dell'istanza basata su NVMe dell'istanza di database, anziché nel volume HAQM EBS. In questo modo si può arrivare ad aumentare la velocità di elaborazione delle query complesse fino al 50%.

Le letture ottimizzate per HAQM RDS sono disponibili per RDS per MySQL sulle versioni di MySQL 8.0.28 e successive.

Le letture ottimizzate di HAQM RDS sono disponibili in tutte le regioni in cui sono disponibili le istanze db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn e X2iedn. Per ulteriori informazioni, consulta la documentazione sulle classi di istanze database di HAQM RDS.

I clienti dovrebbero utilizzare le letture ottimizzate per HAQM RDS in presenza di carichi di lavoro che richiedono query complesse o analisi per uso generico, o che richiedono gruppi complessi, catalogazioni, aggregazioni di hash, join a carico elevato e Common Table Expressions (CTE). Questi casi d'uso comportano la creazione di tabelle temporanee, consentendo alle letture ottimizzate di accelerare l'elaborazione delle query del carico di lavoro.

Sì, i clienti possono convertire il loro database HAQM RDS esistente per utilizzare le letture ottimizzate di HAQM RDS spostando il carico di lavoro in un'istanza abilitata per la lettura ottimizzata. Le letture ottimizzate sono disponibili anche per impostazione predefinita su tutte le classi di istanza supportate. Se il carico di lavoro viene eseguito su istanze db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, e X2iedn, si sta già beneficiando delle letture ottimizzate.

È consigliabile utilizzare l'integrazione Zero-ETL di HAQM RDS per MySQL con HAQM Redshift quando si vuole eliminare la necessità di creare e gestire pipeline di dati complesse. Una volta che i dati sono in HAQM Redshift, è possibile accedere a funzionalità di analisi e machine learning (ML) quasi in tempo reale sui dati transazionali da RDS per MySQL.

L'integrazione Zero-ETL di RDS per MySQL con HAQM Redshift è disponibile per le versioni di MySQL 8.0.32 e successive nelle regioni AWS supportate.

L'integrazione Zero-ETL di RDS per MySQL con HAQM Redshift consente l'analisi e il machine learning (ML) quasi in tempo reale su petabyte di dati transazionali ed elimina la necessità di creare e gestire pipeline di dati complesse. Entro pochi secondi dalla scrittura su RDS per MySQL, i dati vengono replicati su HAQM Redshift. È possibile consolidare i dati da più database e tabelle da RDS per MySQL ad HAQM Redshift. In base alle esigenze di analisi, il filtraggio dei dati di database e tabelle specifici consente di inserire selettivamente i dati in HAQM Redshift.

Si paga per le risorse RDS per MySQL e HAQM Redshift esistenti utilizzate per creare ed elaborare i dati di modifica creati nell'ambito di un'integrazione Zero-ETL. Queste risorse includono i costi di esportazione degli snapshot di HAQM RDS per il seeding e la risincronizzazione dei data warehouse HAQM Redshift, i costi di trasferimento dei dati di Change Data Capture (CDC) per la replica continua delle modifiche ai dati da origine a destinazione, I/O e archiviazione RDS regolari utilizzati per elaborare i dati di modifica e i costi regolari per archiviazione e calcolo di HAQM Redshift per i dati replicati. Per ulteriori informazioni, consulta la pagina dei prezzi di RDS per MySQL.

Ad esempio: hai un database RDS per MySQL 8.0.32 e un data warehouse HAQM Redshift in esecuzione nella regione Stati Uniti orientali (Virginia settentrionale). Attualmente, questa istanza del database RDS per MySQL utilizza 50 GB di capacità di archiviazione SSD per uso generico (gp3) che include gli IOPS di base forniti, ha i backup automatici abilitati e la registrazione binaria MySQL attiva.

Creando un'integrazione Zero-ETL con HAQM Redshift per l'istanza del database RDS per MySQL, viene creato ed esportato uno snapshot dei dati (50 GB) per avviare un data warehouse HAQM Redshift. Il giorno successivo, modifichi la chiave primaria di una tabella nell'istanza del database RDS per MySQL, con conseguente risincronizzazione dell'esportazione dello snapshot su HAQM Redshift. Nell'arco di 30 giorni, il database elabora 5 GB di modifiche ai dati.

In questo esempio, il costo per utilizzare l'integrazione Zero-ETL di RDS per MySQL con HAQM Redshift negli Stati Uniti orientali (Virginia settentrionale) nei 30 giorni è di 50 GB x (0,10 USD/GB) di esportazione iniziale più 50 GB x (0,10 USD/GB) di costi di risincronizzazione più 5 GB x (2,00 USD/GB) di trasferimento dei dati CDC, per un totale di 20,00 USD. Oltre a questi costi per l'integrazione Zero-ETL, sei responsabile degli addebiti derivanti dal normale utilizzo di HAQM RDS e HAQM Redshift per l'elaborazione dei dati replicati, come i costi di I/O, archiviazione e calcolo.

Sì, per ridurre il consumo di risorse sull'istanza primaria, è possibile utilizzare una replica di lettura HAQM RDS come istanza HAQM RDS di origine per un'integrazione Zero-ETL con HAQM Redshift.

Sì, È possibile usare AWS CloudFormation per gestire e automatizzare la configurazione e l'implementazione delle risorse necessarie per un'integrazione Zero-ETL di RDS per MySQL con HAQM Redshift. Per ulteriori informazioni, consulta la guida per l'utente di AWS CloudFormation.

L'integrazione Zero-ETL di RDS per MySQL con HAQM Redshift replica atomicamente le transazioni per garantire la coerenza dei dati tra il database RDS per MySQL di origine e il cluster HAQM Redshift di destinazione.

Ecco alcuni punti chiave sull'atomicità delle transazioni con questa integrazione:

• Solo le transazioni eseguite in RDS per MySQL vengono replicate su HAQM Redshift. Le transazioni non eseguite o annullate non vengono applicate.
• L'integrazione utilizza un processo di esecuzione in due fasi per applicare atomicamente ogni transazione ad HAQM Redshift. Vengono applicate tutte le modifiche ai dati nella transazione oppure, in caso di errore, non ne viene applicata nessuna.
• La coerenza delle transazioni viene mantenuta tra l'origine e la destinazione. Dopo la replica, i dati per una determinata transazione saranno coerenti sia in RDS per MySQL che in HAQM Redshift.
• Anche le modifiche allo schema tramite DDL o DML vengono applicate atomicamente per mantenere l'integrità.
• L'applicazione atomica delle transazioni garantisce che non possano verificarsi transazioni parziali o stati di dati incoerenti tra i database.

L'integrazione Zero-ETL di RDS per MySQL con HAQM Redshift mantiene la piena coerenza transazionale tra il database RDS per MySQL di origine e il cluster HAQM Redshift di destinazione.

Ecco alcuni punti chiave su come vengono gestite le modifiche allo schema:

• Le istruzioni DDL come CREATE TABLE, ALTER TABLE, DROP TABLE e così via vengono replicate automaticamente da RDS per MySQL ad HAQM Redshift.
• L'integrazione effettua i controlli e le regolazioni necessarie nelle tabelle di HAQM Redshift per le modifiche replicate allo schema. Ad esempio, l'aggiunta di una colonna in RDS per MySQL aggiungerà la colonna in HAQM Redshift.
• La replica e la sincronizzazione dello schema avvengono automaticamente quasi in tempo reale con un ritardo minimo tra i database di origine e di destinazione.
• La coerenza dello schema viene mantenuta anche se le modifiche DML avvengono parallelamente alle modifiche DDL.