MySQL
e' DBMS relazionale Open Source piu' diffuso per le applicazioni web
e la sua semplicita' di gestione e di utilizzo e' il suo principale punto di forza.
Amazon fornisce un'impressionante numero di servizi in Cloud.
La concorrenza sul servizi in Cloud e' molto forte ma non c'e' dubbio che l'offerta di Amazon AWS
sia la piu' completa ed innovativa su molteplici tecnologie.
Tra i molti servizi offerti vi sono anche quelli relativi alle basi di dati.
Oltre alla possibilita' di installare DB su sistemi in Cloud o di utilizzare servizi verticali dedicati
viene offerto con Amazon RDS (Relational Database Service) un ampio ventaglio di RDBMS.
Aurora MySQL e' uno dei servizi disponibili su Amazon RDS
ed e' l'oggetto di questa breve paginetta.
Questo documento descrive le caratteristiche degli ambienti Aurora MySQL
presentando in modo sintetico e pratico le differenze rispetto
ad un'installazione MySQL on-premise.
Dopo una breve introduzione (MySQL, RDS, Aurora MySQL), si entra nell'architettura di Aurora vedendo il DB cluster, l'installazione, i superpoteri dell'amministratore, e la configurazione. Si passa quindi all'utilizzo con gli accessi, il monitoring, la gestione, il backup/restore.
Per ovvie ragioni di spazio questo documento e' stato scritto per DBA MySQL
o quantomeno per chi MySQL gia' lo conosce ed lo usa...
Per chi non conosce MySQL si consiglia la lettura di
un documento introduttivo su MySQL
come Introduzione a MySQL oppure
Qualcosa in piu' su MySQL
ed infine del documento Statistiche prestazionali in MySQL
che elenca strumenti e tecniche per analizzare le prestazioni in MySQL.
MySQL
e' DBMS relazionale Open Source piu' diffuso per le applicazioni web
e la sua semplicita' di gestione e di utilizzo e' il suo principale punto di forza.
L'architettura di MySQL e' semplicissima:
vi e' un solo processo che utilizza al suo interno un thread per ogni connessione!
Gli utenti si collegano a MySQL utilizzando una connessione TCP-IP
sulla porta socket 3306.
Il processo mysqld e' in LISTEN su tale porta e quando arriva una nuova
richiesta di connessione effettua l'attivazione del thread corrispondente.
I database MySQL contengono le tabelle che possono essere
gestite da Engine differenti anche se quello piu' utilizzato
ora e' l'InnoDB.
L'ecosistema di applicazioni ed ambienti compatibili con MySQL ed i suoi fork e' molto ampio e completo.
Amazon Web Services (AWS) è la piattaforma cloud più completa e utilizzata del mondo. Tra i molteplici servizi offerti Amazon RDS (Relational Database Service) semplifica l'impostazione, il funzionamento e il dimensionamento di database relazionali nel cloud.
Le basi dati RDS sono facilmente scalabili ed automatizzano alcune attivita' di amministrazione del database (eg. upgrade, backup, monitoring). Tutte le basi dati vengono gestite da console grafica oppure con la CLI AWS oppure con le API RDS in modo semplice e consistente.
Amazon RDS rende disponibili diverse classi di istanza database con Engine: MySQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server ed Amazon Aurora (MySQL e MySQL). In questa paginetta vedremo le caratteristiche del servizio RDS Aurora MySQL!
Come come i servizi EC2 anche i servizi RDS vengono erogati nelle diverse Region
disponibili su AWS (eg.
us-east-1 in Virginia, us-west-2 in Oregon,
eu-south-1 in Italia a Milano).
In ogni Region sono generalmente presenti piu' Availability Zones (AZs)
che sono implementate con alimentazioni, reti, strutture indipendenti
per garantire un'elevata alta affidabilita'.
I tipi di istanza AWS comprendono una combinazione di diverse capacità di CPU, memoria, storage e rete per semplificare la configurazione mantenendo il massimo della flessibilita'. Amazon RDS supporta tre tipi di classi di istanza: standard, ottimizzate per la memoria e a prestazioni espandibili. Tra queste Aurora utilizza solo quelle ottimizzate per la memoria (db.r*) e a prestazioni espandibili (db.t*). Le istanze Aurora MySQL saranno quindi da scegliere tra queste due classi: si parte da 2 CPU e si arriva fino a 128 CPU e 1TB di RAM con 40Gb di banda.
Infine lo storage... senza entrare nei dettagli dell'architettura Aurora utilizza storage SSD GP (General Purpose) e cresce automaticamente di 10GB fino a 128TiB: c'e' spazio sufficiente per qualsiasi database... o quasi!
Aurora MySQL e' un'implementazione Amazon di un database compatibile a livello applicativo a MySQL.
Sono disponibili diverse versioni di Aurora corrispondenti a differenti versioni di MySQL
come riportato nella seguente tabella:
(Source: Your database stinks)
| |
|
|
|
|
|
|
|
| Aurora MySQL | 3 | 3.0 | 3.04.0 | 2021-11 | Compatible with MySQL 8.0 | ||
| 2 | 2.0 | 2.12.0 | 2018-02 | 2024-02 | Compatible with MySQL 5.7 | ||
| 1 | 1.1 | 1.23.4 | 2014-11 | 2023-02 | Compatible with MySQL 5.6 |
In generale una versione di Aurora MySQL ha le stesse identiche funzionalita' della corrispondente versione di MySQL.
Questo e' vero dal punto di vista delle applicazioni ma vi sono pero' importanti differenze nell'architettura.
Le differenze si rendono evidenti nella gestione e nell'amministrazione
e nel seguito cercheremo di vedere tutte le particolarita' di Aurora MySQL.
Quando si attiva un'istanza Aurora in realta' viene attivato un DB Cluster.
In un DB cluster e' sempre presente un'istanza DB principale in lettura/scrittura
e possono essere attive fino a 15 ulteriori istanze in sola lettura.
Le istanze in sola lettura possono essere utilizzate per ridurre il carico in lettura
ed e' disponibile un punto di accesso bilanciato tra le istanze in lettura.
La scalabilita' in lettura di Aurora e' quindi molto elevata: fino a 15 nodi.
Dal punto di vista dello storage questo e' comune a tutte le istanze DB, e viene replicato sei volte su tre diverse Availability Zones. E' sempre costituito da dischi SSD (di tipo GP). Le repliche sono sincrone e, con la tripla replica, garantiscono un'elevata HA. Lo storage e' indipendente dal numero di instanze DB ed e' sempre configurato come un cluster. Il motore del database e' ottimizzato per operare in cloud e si integra in modo completo con il particolare meccanismo dello storage.
Non e' necessario preallocare o definire la dimensione dello storage. Aurora cresce dinamicamente allocando 10GB alla volta fino ad una dimensione di 128TB.
Sia le istanze DB che lo storage sono ospitate nella stessa Region.
Con Aurora e' anche possibile definire un Global Cluster. Un Global Database Cluster e' composto da diversi DB Cluster, ciascuno in una Region differente. Il DB Cluster principale e' l'unico che accetta le scritture e possono essere presenti fino a 5 DB Cluster secondari. Ogni DB Cluster utilizza uno Storage allocato nella stessa Region e gli storage vengono replicati tra loro in modo asincrono con un sistema di replica dedicato a bassa latenza.
Quanto riportato in questo paragrafo vale per tutti i servizi RDS Aurora ovvero sia per
quelli compatibili MySQL che PostgreSQL.
Curiosi di saperne di piu'? Volte vedere quali sono i nodi che compongono il vostro cluster?
Provate questa query:
select * from information_schema.replica_host_status;
Deve essere sottolineato che la modalita' di replica di Aurora MySQL Cluster e'
molto diversa dalla replica di
MySQL RDS che utilizza
la Replica nativa di MySQL sia nella modalita' sincrona che asincrona.
E' invece implementata nello stesso modo la replica di Aurora PostgreSQL Cluster
[NdA per Aurora PostgreSQL la vista di controllo e' aurora_replica_status()].
Ricordate i comandi rpm o apt del sistema operativo per installare i pacchetti PosgreSQL? Dimenticatelo! Siamo in Cloud ed e' tutto diverso...
L'installazione di Aurora MySQL-compatible non richiede alcuna competenza tecnica specifica e si effettua solo con qualche click. Anche la configurazione iniziale della base dati, che tipicamente richiede competenze specifiche sul motore, e' molto semplificata. Infatti RDS imposta in automatico i principali parametri di tuning in modo ottimizzato.
A differenza di un'installazione MySQL on premise non e' necessaria
una configurazione iniziale.
I principali parametri di tuning sono gia' configurati,
il file my.cnf non puo', e non deve, essere impostato.
A volte e' opportuna qualche configurazione specifica ma questa
verra' impostata con i DBParameter Group o i Cluster Parameter Group
come vederemo nel seguito.
Ricordate che l'utente MySQL mysql del sistema operativo puo' eseguire tutte le configurazioni e che l'utente MySQL root del database ha tutti i poteri? Dimenticatelo! Siamo in Cloud ed e' tutto diverso...
Non c'e' alcun accesso al sistema operativo:
i file di configurazione non si utilizzano e vengono utilizzati i Parameter Group,
i file di log sono accessibili da console o da CLI.
Non esiste l'utente root MySQL!
In un DB cluster Aurora MySQL version 2,
vengono creati gli utenti admin ed rdsadmin.
In un DB cluster Aurora MySQL version 3 (che e' compatibile con MySQL 8.0 e quindi dispone dei
ruoli),
vengono creati gli utenti admin, rdsadmin e viene creato il ruolo rds_superuser_role.
L'utente rdsadmin che ha tutti i poteri
ma e' utilizzabile solo da AWS per attivita' di servizio (eg. monitoring).
Tutti gli altri utenti applicativi vengono creati normalmente
da SQL seguendo le best pratices di MySQL.
E' assolutamente consigliato utilizzare per ogni DBA un accesso IAM (Identity and Access Management).
Ricordate il file my.cnf? Dimenticatelo! Siamo in Cloud ed e' tutto diverso...
Per effettuare la configurazione di Aurora MySQL non e' necessario
modificare alcun file. Le configurazioni si effettuano sui Parameter Group.
I Parameter Group possono essere a livello di singolo database o dell'intero cluster
a seconda che il parametro sia per un singolo database o comune a tutte le istanze,
vengono quindi chiamati DB Parameter Group o Cluster Parameter Group.
I parametri disponibili sono quasi tutti quelli presenti in MySQL
con alcune differenze perche' alcuni parametri vengono calcolati in
automatico a seconda dell'Instance Class scelta.
In Aurora MySQL sono presenti due gruppi di parametri configurabili da interfaccia grafica: quelli a livello di cluster e quelli a livello di istanza [NdA con MySQL RDS Single Instance vi e' un solo gruppo di parametri e su un'installazione tradizionale di MySQL i parametri sono gestiti nel file MySQL.conf].
Creazione di un nuovo DB Cluster Parameter Group:
Creazione di un nuovo DB Parameter Group:
Impostazione dei parametri:
Una volta preparate le configurazioni va assegnato il DB [Cluster] Parameter Group all'istanza:
E' possibile eseguire le modifiche nella finistra di manutenzione o applicarle immediatamente:
Cosi' come avviene per i parametri di MySQL on premise alcuni possono essere
modificati senza eseguire un riavvio mentre altri richiedono un riavvio.
In generale i parametri che richiedono il riavvio sono gli stessi
per MySQL Community, per MySQL RDS o per Aurora MySQL.
Dal punto di vista dell'accesso applicativo alla base dati non presenta differenze rispetto all'utilizzo di un'istanza on premises:
mysql --host=aws-aurora-01-cluster.cluster-cen6969.eu-central-1.rds.amazonaws.com -P 3306 -u admin -p Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 69 Server version: 8.0.33 Source distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql>
In pratica e' sufficiente utilizzare l'endopoint dell'istanza come host nella stringa di connessione.
Deve essere ricordato che con Aurora sono disponibili piu' endpoint per l'accesso in lettura/scrittura
e per l'accesso in sola lettura.
[NdA La connessione via SSL, non e' obbligatoria di default ma e' possibile richiederla con il parametro cluster require_secure_transport]
Sono molteplici le possibilita' di monitoraggio dei servizi RDS:
l'instance status fornisce alcune infomrazioni riassuntive,
le recommendations forniscono suggerimenti (eg. un aggiornamento di minor release),
l'Enhanced Monitoring riporta le statistiche del sistema ospite (eg. uso di CPU, memoria)
i database logs riportano il contenuto dei log la cui configurazione e' analoga a quella dei sistemi
on-premise, ...
Lo strumento piu' ricco di informazioni e' sicuramente il Performance Insights.
Performance Insights raccoglie e mantiene, per il periodo indicato, una serie di metriche
relative al database ed al sistema ospite.
La dashboard riporta fino a 10 differenti metriche che vengono scelte tra quelle piu' significative.
La maggioranza delle metriche del database sono
specifiche di MySQL
ma sono disponibili anche alcune metriche non native ovvero aggiunte da Amazon a quelle standard del database.
L'abilitazione di Performance Insights e' molto semplice e si effettua da console.
Dal punto di vista "tecnico" l'utente rdsadmin eseguira' una serie di query a tempo
sulle viste di sistema di MySQL (eg. pg_stat_statement).
Per completezza va infine ricordato che sono disponibili ulteriori strumenti di
monitoraggio come: CloudWatch, EventBridge, CloudTrail, ...
E' naturalmente sempre possibile utilizzare strumenti di terze parti per il monitoraggio sia legacy MySQL (eg. phpMyAdmin) che specifici per AWS. Da questo punto di vista l'unica limitazione sarebbero le autorizzazioni ma in realta' anche gli strumenti piu' datati funzionano perfettamente.
La gestione di un'istanza Aurora MySQL e' differente rispetto a quella di un'istanza on-premises ma e' anche terribilmente semplice!
Per avviare un'istanza dalla console di gestione: scegliere Databases quindi scegliere l'istanza di interesse e da Actions scegliere Start.
La console permette di effettuare tutte le normali attivita' di gestione compresa
la modifica di un'istanza e l'ugrade di una minor release.
Quando la modifica richiede un riavvio e' possibile eseguirlo immediatamente
oppure farlo eseguire automaticamente alla successiva finestra di manutenzione.
Le stesse funzionalita' sono richiamabili anche da AWS CLI ed RDS API.
I backup dei database RDS vengono effettuati automaticamente durante la
Backup window e mantenuti per il periodo di ritenzione prescelto
[NdA se la ritenzione e' 0 non vengono effettuati backup].
I backup contengono l'intera istanza DB in tutte le sue parti.
Nel caso di Aurora MySQL sono quindi presenti tutti i database
e gli oggetti comuni ai database (eg. roles).
Non e' possibile impostare backup parziali.
I restore vengono effettuati con la modalita' PITR (Point In Time Recovery)
e comportano la creazione di una nuova istanza.
Con un restore e' possibile associare parameter group, security group ed option group
differenti rispetto all'istanza di partenza. Va pero' posta attenzione che i nuovi parametri
permettano di operare correttamente... e' quindi consigliato mantenere i default
che riportano le definizioni precedenti.
Una seconda possibilita' e' quella di eseguire un salvataggio manuale chiamato Snapshot. Anche con il restore da snapshot viene creata una nuova istanza di database.
Sono presenti ulteriori funzionalita' sui backup (eg. export su S3, utilizzare Region differenti, ...) per maggiori dettagli consultare la documentazione ufficiale.
Il documento Your server stinks! e' sempre aggiornato sui rilasci delle release MySQL e dei servizi RDS.
Abbiamo accennato alle poche cose in meno presenti in Aurora MySQL... c'e' anche qualcosa in piu'? Certamente: Fast Insert, Parallel Query, ... ad esempio:
show global status like 'Aurora_fast_insert%';
Titolo: Aurora 4 MySQL DBA
Livello: Avanzato
Data:
14 Febbraio 2020
Versione: 1.0.2 - 14 Febbraio 2023 ❤️
Autore: mail [AT] meo.bogliolo.name