Aurora PostgreSQL
4 DBAs
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 PostgreSQL e' uno dei servizi disponibili su Amazon RDS
ed e' l'oggetto di questa breve paginetta.
Questo documento descrive le caratteristiche degli ambienti Aurora PostgreSQL
presentando in modo sintetico e pratico le differenze rispetto
ad un'installazione PostgreSQL on-premise.
Dopo una breve introduzione
(PostgreSQL, RDS, Aurora PostgreSQL),
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 Postgres
o quantomeno per chi PostgreSQL gia' lo conosce ed lo usa...
Per chi non conosce PostgreSQL si consiglia la lettura di
un documento introduttivo su PostgreSQL
come Introduzione a PostgreSQL oppure
Qualcosa in piu' su PostgreSQL
ed infine del documento Statistiche prestazionali in PostgreSQL
che elenca strumenti e tecniche per analizzare le prestazioni in PostgreSQL.
PostgreSQL
PostgreSQL
e' considerato a ragione il piu' completo e robusto RDBMS Open Source.
Le sue prestazioni ed affidabilita' sono paragonabili
a quelle dei piu' diffusi RDBMS commerciali
e su alcune funzionalita' e' il database di riferimento (eg. GIS).
I suoi principali punti di forza sono
una licenza molto aperta per tutti gli utilizzi,
la gestione completa ed efficiente delle transazioni (ACID),
ottime prestazioni ed affidabilita',
un SQL ricco di funzionalita'
(eg. subquery, referential integrity, inheritance, trigger, stored fuctions, 2PC,
full-text, JSON, analytics,
native partitioning, stored procedures, ...),
allineato ai piu' recenti standard ed estensibile (extension),
funzionalita' Object-Relational,
strumenti di amministrazione e gestione completi,
funzionalita' di replicazione/HA/DR incluse nel database.
La gestione delle transazioni in PostgreSQL avviene con la tecnica del MVCC
(Multiversion Concurrency Control)
e la consistenza dei dati su disco e' assicurata con il logging sui WAL
(Write-Ahead Logging).
Un'instanza Postgres contiene piu' database.
All'interno di ogni database viene mantenuto un ricco Catalog
che consente di controllare con query SQL gli oggetti presenti
nella base dati (eg. pg_database, pg_class, pg_tables, ...) e l'andamento delle
attivita' (eg. pg_stat_activity, pg_locks, pg_settings, pg_stats,...).
L'ecosistema di applicazioni ed ambienti compatibili con Postgres e' molto ampio e completo.
RDS
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: PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server ed Aurora (MySQL e PostgreSQL).
In questa paginetta vedremo le caratteristiche del servizio RDS Aurora PostgreSQL!
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 PostgreSQL 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 PostgreSQL
Aurora PostgreSQL e' un'implementazione Amazon di un database compatibile a livello applicativo a PostgreSQL.
Sono disponibili diverse versioni di Aurora Pg corrispondenti a differenti versioni di PostgreSQL
come riportato nella seguente tabella:
(Source: Your database stinks)
| Database |
Version |
First release |
Last release |
Date (from) |
Date (no new) |
Date (no snap.) |
Notes |
| Aurora PostgreSQL | 14 | | 14.3 | | 2027-01 | | Compatible with PostgreSQL 14
|
| 13 | | 13.7 | | 2026-01 | | Compatible with PostgreSQL 13
|
| 4 | 4.0 | 12.11 | | 2025-01 | | Compatible with PostgreSQL 12
|
| 3 | 3.1 | 11.16 | | 2024-01 | | Compatible with PostgreSQL 11
|
| 2 | 2.0 | 10.21 | | 2022-08 | | Compatible with PostgreSQL 10
|
| 1 | 1.0 | 1.11 (9.6.22) | 2017-10 | 2022-01 | | Compatible with PostgreSQL 9.6
|
In generale una versione di Aurora PostgreSQL ha le stesse identiche funzionalita' della corrispondente versione di PostgreSQL.
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 PostgreSQL.
Aurora DB cluster
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 vale per tutti i servizi RDS Aurora ovvero sia per
quelli compatibili PostgreSQL che MySQL.
Curiosi di saperne di piu'? Volte vedere quali sono i nodi che compongono il vostro cluster?
Provate questa query:
select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role,
replica_lag_in_msec as AuroraReplicaLag
from aurora_replica_status();
Deve essere sottolineato che la modalita' di replica di Aurora PostgreSQL Cluster e'
molto diversa dalla replica di PostgreSQL RDS che utilizza
la Streaming Replication nativa di PostgreSQL.
E' invece implementata nello stesso modo la replica di Aurora MySQL Cluster
[NdA per Aurora MySQL la vista di controllo e' information_schema.replica_host_status].
Installazione
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 PostgreSQL-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 PostgreSQL on premise non e' necessaria
una configurazione iniziale.
I principali parametri di tuning sono gia' configurati,
il file pg_hba non deve, e non puo', 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.
Superpoteri
Ricordate che l'utente postgres del sistema operativo ha tutti i poteri
e che l'utente postgres 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 postgres:
al suo posto e' presente l'utente rdsadmin che ha tutti i poteri
ma che e' utilizzabile solo da AWS per attivita' di servizio (eg. monitoring).
Al momento della creazione di un'istanza viene creato un master user
cui viene assegnato il ruolo rds_superuser.
Questo ruolo e' quello del DBA con tutti i privilegi necessari
per amministrare l'istanza.
Cosa non puo' fare un utente rds_superuser?
Non puo' accedere al file system, non ha accesso alla tabella pg_shadow, ...
Tutti gli altri utenti applicativi vengono creati normalmente
da SQL seguendo le best pratices di PostgreSQL.
E' assolutamente consigliato utilizzare per ogni DBA
un accesso IAM (Identity and Access Management).
Configurazione
Ricordate i file postgresql.conf e pg_hba.conf? Dimenticatelo!
Siamo in Cloud ed e' tutto diverso...
Per effettuare la configurazione di Aurora PostgreSQL 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 Postgres
con alcune differenze perche' alcuni parametri vengono calcolati in
automatico a seconda dell'Instance Class scelta.
In Aurora PostgreSQL sono presenti due gruppi di parametri configurabili da interfaccia grafica:
quelli a livello di cluster e quelli a livello di istanza
[NdA con PostgreSQL RDS Single Instance vi e' un solo gruppo di parametri
e su un'installazione tradizionale di PostgreSQL i parametri sono gestiti nel file postgresql.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 PostgreSQL on premise alcuni possono essere
modificati senza eseguire un riavvio (pg_ctl reload) mentre altri richiedono un riavvio.
In generale i parametri che richiedono il riavvio sono gli stessi.
Ad esempio per utilizzare la relativa extension va configurato la libreria
pg_stat_statements nel parametro shared_preload_libraries:
trattandosi di una libreria dinamica da caricare con l'eseguibile e' necessario un riavvio
sia con una versione community on-premises che su Aurora PostgreSQL.
Accessi
Dal punto di vista dell'accesso applicativo alla base dati non presenta differenze
rispetto all'utilizzo di un'istanza on premises:
psql testdb --user=test --host=aws-testdb-01-cluster.cluster-cen6969.eu-central-1.rds.amazonaws.com
Password for user test:
psql (13.3, server 12.7)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
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, che si vede nell'esempio, non e' obbligatoria di default ma e' possibile richiederla con il parametro rds.force_ssl]
Monitoring
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 PostgreSQL
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 PostgreSQL (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 PostgreSQL (eg. pgAdmin) 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:
Gestione
La gestione di un'istanza Aurora PostgreSQL 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.
Anche la modifica dei parametri di configurazione e tuning e' molto semplice
e si effettua dalla console.
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.
Backup/restore
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 PostgreSQL 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.
Varie ed eventuali
Il documento
Your server stinks!
e' sempre aggiornato
sui rilasci delle release
PostgreSQL
e dei
servizi RDS.
Abbiamo accennato alle poche cose in meno presenti in Aurora PostgreSQL...
c'e' anche qualcosa in piu'? Certamente, ad esempio:
SELECT coalesce(sum(used_bytes), 0) FROM aurora_stat_file();
SELECT server_id, durable_lsn, current_read_lsn, last_update_timestamp FROM aurora_replica_status();
Aurora PostgreSQL fornisce la quasi totalita' delle extension core di PostgreSQL ed aggiunge
alcune utili estensioni tra cui Aurora Pg Query Plan Management,
orafce, pg_cron, pgAudit, ...