I servizi AWS PostgreSQL rientrano nell'ombrello di RDS, che è l'offerta DaaS di Amazon per tutti i motori di database noti.
I servizi di database gestiti offrono alcuni vantaggi che attraggono il cliente che cerca l'indipendenza dalla manutenzione dell'infrastruttura e configurazioni ad alta disponibilità. Come sempre, non esiste una soluzione adatta a tutti. Le opzioni attualmente disponibili sono evidenziate di seguito:
Aurora PostgreSQL
La pagina delle domande frequenti su Amazon Aurora fornisce dettagli importanti che devono essere considerati prima di immergersi nel prodotto. Ad esempio, apprendiamo che il livello di archiviazione è virtualizzato e si trova su un sistema di archiviazione virtualizzato proprietario supportato da SSD.
Prezzi
In termini di prezzi, va notato che Aurora PostgreSQL non è disponibile nel piano gratuito di AWS.
Compatibilità
La stessa pagina delle domande frequenti chiarisce che Amazon non rivendica la compatibilità al 100% con PostgreSQL. La maggior parte (il corsivo mio) delle applicazioni andrà bene, ad es. la versione AWS PostgreSQL è compatibile con i cavi con PostgreSQL 9.6. Di conseguenza, Wireshark PostgreSQL Dissector funzionerà perfettamente.
Prestazioni
Le prestazioni sono anche legate al tipo di istanza, ad esempio il numero massimo di connessioni è configurato per impostazione predefinita in base alla dimensione dell'istanza.
Altrettanto importante quando si tratta di compatibilità è la dimensione della pagina che è stata mantenuta a 8 KiB, che è la dimensione della pagina predefinita di PostgreSQL. A proposito di pagine, vale la pena citare le domande frequenti:"A differenza dei tradizionali motori di database, Amazon Aurora non invia mai le pagine di database modificate al livello di archiviazione, con conseguente ulteriore risparmio del consumo di IO. "Ciò è reso possibile perché Amazon ha cambiato il modo in cui viene gestita la cache delle pagine, consentendole di rimanere in memoria in caso di guasto del database. Questa funzione avvantaggia anche il riavvio del database in seguito a un arresto anomalo, consentendo il ripristino molto più veloce rispetto al metodo tradizionale di riproduzione dei registri.
Secondo le domande frequenti sopra citate, Aurora PostgreSQL offre prestazioni tre volte superiori a PostgreSQL sulle operazioni SELECT e UPDATE. Secondo il white paper sul benchmark PostgreSQL di Amazon, gli strumenti utilizzati per misurare le prestazioni erano pgbench e sysbench. Notevole è la dipendenza delle prestazioni dal tipo di istanza, dalla selezione della regione e dalle prestazioni della rete. Ti chiedi perché INSERT non è menzionato? È perché la conformità all'ACID di PostgreSQL (la "C") richiede la creazione di un record aggiornato utilizzando un'eliminazione seguita da un inserimento.
Per sfruttare appieno i miglioramenti delle prestazioni, Amazon consiglia che le applicazioni siano progettate per interagire con il database utilizzando un gran numero di query e transazioni simultanee . Questo importante fattore, viene spesso trascurato portando a scarse prestazioni imputabili all'implementazione.
Limiti
Ci sono alcune limitazioni da considerare quando si pianifica la migrazione:
-
huge_pages non può essere modificato, tuttavia è attivo per impostazione predefinita:
template1=> select aurora_version(); aurora_version ---------------- 1.0.11 (1 row) template1=> show huge_pages ; huge_pages ------------ on (1 row)
- pg_hba non può essere utilizzato poiché richiede il riavvio del server. Come nota a margine, questo deve essere un errore di battitura nella documentazione di Amazon, poiché PostgreSQL deve solo essere ricaricato. Invece di fare affidamento su pg_hba, gli amministratori dovranno utilizzare i gruppi di sicurezza AWS e PostgreSQL GRANT.
- La granularità PITR è di 5 minuti.
- La replica tra regioni non è attualmente disponibile per PostgreSQL.
- La dimensione massima delle tabelle è 64TiB
- Fino a 15 repliche di lettura
Scalabilità
Il ridimensionamento su e giù dell'istanza del database è attualmente un processo manuale, che può essere eseguito tramite la Console AWS o l'interfaccia a riga di comando, sebbene il ridimensionamento automatico sia in lavorazione, tuttavia, secondo le FAQ di Amazon Aurora sarà disponibile solo per MySQL.
Ridimensionamento del registro eventi delle risorse di calcoloPer scalare orizzontalmente le applicazioni devono sfruttare le API dell'SDK AWS, ad esempio per ottenere un failover rapido.
Alta disponibilità
Passando all'alta disponibilità, in caso di guasto del nodo primario, Aurora PostgreSQL fornisce un endpoint del cluster come record DNS A, che viene aggiornato automaticamente internamente per puntare alla replica selezionata per diventare master.
Backup
Vale la pena ricordare che se il database viene eliminato, gli snapshot di backup manuali verranno conservati, mentre gli snapshot automatici verranno rimossi.
Replica
Poiché le repliche condividono lo stesso storage sottostante dell'istanza primaria, il ritardo di replica è, in teoria, dell'ordine dei millisecondi.
Amazon consiglia repliche di lettura per ridurre la durata del failover. Con una replica di lettura in standby, il processo di failover richiede circa 30 secondi, mentre senza una replica sono previsti fino a 15 minuti.
Un'altra buona notizia è che è supportata anche la replica logica, come mostrato a pagina 22.
Sebbene le FAQ di Amazon Aurora non forniscano dettagli sulla replica come per MySQL, le Best Practices di Aurora PostgreSQL forniscono una query utile per verificare lo stato della replica:
select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp from
aurora_replica_status();
La query precedente produce:
-[ RECORD 1 ]--------------+-------------------------------------
server_id | testdb
session_id | 9e268c62-9392-11e8-87fc-a926fa8340fe
highest_lsn_rcvd | 46640889
cur_replay_latency_in_usec | 8830
now | 2018-07-29 20:14:55.434701-07
last_update_timestamp | 2018-07-29 20:14:54-07
-[ RECORD 2 ]--------------+-------------------------------------
server_id | testdb-us-east-1b
session_id | MASTER_SESSION_ID
highest_lsn_rcvd |
cur_replay_latency_in_usec |
now | 2018-07-29 20:14:55.434701-07
last_update_timestamp | 2018-07-29 20:14:55-07
Poiché la replica è un argomento così importante, è valsa la pena impostare il test pgbench come descritto nel white paper benchmark di cui sopra:
[[email protected] ~]$ whoami
ec2-user
[[email protected] ~]$ tail -n 2 .bashrc
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
export PATH=$PATH:/usr/local/pgsql/bin/
[[email protected] ~]$ which pgbench
/usr/local/pgsql/bin/pgbench
[[email protected] ~]$ pgbench --version
pgbench (PostgreSQL) 9.6.8
Suggerimento: Evita la digitazione non necessaria creando un file pgpass ed esportando le variabili di ambiente host, database e utente, ad esempio:
[[email protected] ~]# tail -n 3 ~/.bashrc export
PGUSER=dbadmin
export PGHOST=c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com
export PGDATABASE=template1
[[email protected] ~]# cat ~/.pgpass
*:*:*:dbadmin:password
Esegui il comando di inizializzazione dei dati:
[[email protected] ~]$ pgbench -i --fillfactor=90 --scale=10000 postgres
Mentre l'inizializzazione dei dati è in esecuzione, acquisisci il ritardo di replica utilizzando l'SQL sopra richiamato dallo script seguente:
while : ; do
psql -t -q \
-c 'select server_id, session_id, highest_lsn_rcvd,
cur_replay_latency_in_usec, now(), last_update_timestamp
from aurora_replica_status();' postgres
sleep 1
done
Filtrare l'output dello screenlog tramite il seguente comando:
[[email protected] ~]# awk -F '|' '{print $4,$5,$6}' screenlog.2 | sort -k1,1 -n | tail
513116 2018-07-30 04:30:44.394729+00 2018-07-30 04:30:43+00
529294 2018-07-30 04:20:54.261741+00 2018-07-30 04:20:53+00
544139 2018-07-30 04:41:57.538566+00 2018-07-30 04:41:57+00
1001902 2018-07-30 04:42:54.80136+00 2018-07-30 04:42:53+00
2376951 2018-07-30 04:38:06.621681+00 2018-07-30 04:38:06+00
2376951 2018-07-30 04:38:07.672919+00 2018-07-30 04:38:07+00
5365719 2018-07-30 04:36:51.608983+00 2018-07-30 04:36:50+00
5365719 2018-07-30 04:36:52.912731+00 2018-07-30 04:36:51+00
6308586 2018-07-30 04:45:22.951966+00 2018-07-30 04:45:21+00
8210986 2018-07-30 04:46:14.575385+00 2018-07-30 04:46:13+00
Si scopre che la replica è rimasta indietro di 8 secondi!
In una nota correlata, il parametro AWS CloudWatch AuroraReplicaLagMaximum non è d'accordo con i risultati del comando SQL precedente. Vorrei sapere perché, quindi il feedback è molto apprezzato.
Grafico di ritardo della replica massima di RDS CloudWatchSicurezza
-
La crittografia è disponibile e deve essere abilitata al momento della creazione del database, poiché non può essere modificata in seguito.
Risoluzione dei problemi
Questa breve sezione è un aspetto importante Assicurati che il work_mem di PostgreSQL sia ottimizzato in modo appropriato in modo che le operazioni di ordinamento non scrivano dati su disco.
Configurazione
Segui semplicemente la procedura guidata di configurazione nella Console AWS:
-
Apri Amazon RDS console di gestione.
Console di gestione RDS -
Seleziona Aurora Amazon e PostgreSQL edizione.
Procedura guidata Aurora PostgreSQL -
Specifica i dettagli del database e prendi nota delle limitazioni della password Aurora PostgreSQL:
Dettagli del database della procedura guidata Aurora PostgreSQLMaster Password must be at least eight characters long, as in "mypassword". Can be any printable ASCII character except "/", """, or "@".
-
Configura le opzioni del database:
- Al momento della stesura di questo documento è disponibile solo PostgreSQL 9.6. Usa PostgreSQL su Amazon RDS se hai bisogno di supporto per versioni più recenti, incluse le anteprime beta.
-
Configura la priorità di failover e seleziona il numero di repliche.
Descrizione foto -
Imposta la conservazione del backup (il massimo è 35 giorni).
Conservazione del backup della procedura guidata Aurora PostgreSQL -
Seleziona il programma di manutenzione. Sono disponibili aggiornamenti automatici delle versioni secondarie, tuttavia è importante verificare con il supporto AWS se la pianificazione delle patch può essere accelerata nel caso in cui il progetto PostgreSQL rilasci aggiornamenti urgenti. Ad esempio, AWS ha impiegato più di due mesi per inviare gli aggiornamenti del 10-05-2018.
Programma di manutenzione della procedura guidata Aurora PostgreSQL -
Se il database è stato creato con successo, verrà visualizzato un collegamento alle istruzioni su come connettersi ad esso:
Installazione guidata Aurora PostgreSQL completata
Connessione al database
Esamina le istruzioni dettagliate per le opzioni di connessione disponibili, in base alla configurazione dell'infrastruttura. Nello scenario più semplice la connessione avviene tramite un'istanza EC2 pubblica.
Nota:il client deve essere compatibile con PostgreSQL 9.6.3 o versioni successive.
[[email protected] ~]# psql -U dbadmin -h c1.cluster-ctfirtyhadgr.us-east-1.rds.amazonaws.com template1
Password for user dbadmin:
psql (9.6.8, server 9.6.3)
SSL connection (protocol: TLSv1.2, cipher: DHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
Monitoraggio
Amazon fornisce vari parametri per il monitoraggio del database, di seguito un esempio che mostra i parametri delle istanze:
Metriche dell'istanza RDSScarica il whitepaper oggi PostgreSQL Management &Automation con ClusterControlScopri cosa devi sapere per distribuire, monitorare, gestisci e ridimensiona PostgreSQLScarica il whitepaperRDS per PostgreSQL
Si tratta di un'offerta che consente una maggiore granularità in termini di scelte di configurazione. Ad esempio, contrariamente ad Aurora che utilizza un sistema di storage proprietario, RDS offre storage configurabile utilizzando volumi EBS che possono essere General Purpose SSD (GP2) o Provisioned IOPS o magnetici (non consigliato).
Al fine di supportare installazioni di grandi dimensioni, che richiedono una personalizzazione non disponibile nell'offerta Aurora, Amazon ha recentemente rilasciato i consigli sulle migliori pratiche, disponibili solo per RDS.
La disponibilità elevata deve essere configurata manualmente (o automatizzata utilizzando uno qualsiasi degli strumenti AWS conosciuti) e si consiglia di configurare una distribuzione Multi-AZ.
La replica viene implementata utilizzando la replica nativa di PostgreSQL.
Ci sono alcuni limiti per le istanze database PostgreSQL che devono essere considerati.
Tenendo presente le note precedenti, ecco una procedura dettagliata per la configurazione di un ambiente RDS PostgreSQL Multi-AZ:
-
Dalla Console di gestione di RDS avvia la procedura guidata
Procedura guidata RDS PostgreSQL -
Scegli tra una produzione e una configurazione di sviluppo.
Selezione caso d'uso del database della procedura guidata RDS PostgreSQL -
Inserisci i dettagli sul tuo nuovo cluster di database.
Dettagli DB della procedura guidata RDS PostgreSQL Impostazioni del database della procedura guidata RDS PostgreSQL -
Nella pagina successiva, imposta il programma di rete, sicurezza e manutenzione:
Impostazioni avanzate della procedura guidata RDS PostgreSQL Sicurezza e manutenzione della procedura guidata RDS PostgreSQL
Conclusione
Amazon RDS Services for PostgreSQL include RDS PostgreSQL e Aurora PostgreSQL, entrambi offerte DaaS gestite. Ricchi di molte funzionalità e di un solido storage di back-end, presentano alcune limitazioni rispetto alla configurazione tradizionale, tuttavia, con un'attenta pianificazione queste offerte possono fornire un rapporto costo-funzionalità ben bilanciato. Amazon RDS for PostgreSQL è destinato agli utenti che richiedono più opzioni per la configurazione dei propri ambienti ed è generalmente più costoso. La maggior parte degli utenti trarrà vantaggio dall'avvio con Aurora PostgreSQL e si farà strada in configurazioni più complesse.