L’impostazione della replica tra due database offre una tolleranza ai guasti contro gli imprevisti. \u00c8 considerata la migliore strategia per ottenere un’alta disponibilit\u00e0 durante i disastri.<\/p>\n
In questo articolo, approfondiremo le diverse strategie che possono essere implementate dagli sviluppatori di backend<\/a> per una replica PostgreSQL senza soluzione di continuit\u00e0.<\/p>\n La replica PostgreSQL \u00e8 definita come il processo di copia dei dati da un server di database PostgreSQL<\/a> a un altro server. Il server del database di origine \u00e8 noto anche come server “primario”, mentre il server del database che riceve i dati copiati \u00e8 noto come server “di replica”.<\/p>\n Il database PostgreSQL segue un modello di replica semplice, in cui tutte le scritture vengono inviate a un nodo primario. Il nodo primario pu\u00f2 quindi applicare le modifiche e trasmetterle ai nodi secondari.<\/p>\n Il failover \u00e8 un metodo per recuperare i dati se il server primario<\/a> cede per qualsiasi motivo. Se avete configurato PostreSQL per gestire la replica dello streaming fisico, voi e i vostri utenti sarete protetti dai tempi di inattivit\u00e0 dovuti a un guasto del server primario.<\/p>\n Il processo di failover pu\u00f2 richiedere un po’ di tempo per essere configurato e avviato. In PostgreSQL non esistono strumenti integrati per il monitoraggio e l’analisi dei guasti del server, quindi \u00e8 necessario essere creativi.<\/p>\n Non dovete dipendere da PostgreSQL per il failover. Esistono strumenti dedicati che consentono il failover automatico e il passaggio automatico allo standby, riducendo i tempi di inattivit\u00e0 del database<\/a>.<\/p>\n Impostando la replica di failover, garantite l’alta disponibilit\u00e0 e vi assicurate che gli standby siano disponibili se il server primario dovesse crollare.<\/p>\n Ecco alcuni vantaggi chiave dell’utilizzo della replica di PostgreSQL:<\/p>\n In genere, si pensa che quando ci si diletta con un’architettura primaria e secondaria, ci sia un solo modo per impostare i backup<\/a> e la replica. Le implementazioni di PostgreSQL, invece, possono seguire uno qualsiasi di questi tre metodi<\/a>:<\/p>\n La replica in streaming di PostgreSQL, nota anche come replica WAL, pu\u00f2 essere impostata senza problemi dopo aver installato PostgreSQL su tutti i server. Questo approccio alla replica si basa sullo spostamento dei file WAL dal database primario a quello di destinazione.<\/p>\n Potete implementare la replica in streaming di PostgreSQL usando una configurazione primaria-secondaria. Il server primario \u00e8 l’istanza principale che gestisce il database primario e tutte le sue operazioni. Il server secondario agisce come istanza supplementare ed esegue tutte le modifiche apportate al database primario su se stesso, generando una copia identica nel processo. Il server primario \u00e8 un server di lettura\/scrittura, mentre il server secondario \u00e8 di sola lettura.<\/p>\n Per questo metodo, \u00e8 necessario configurare sia il nodo primario che il nodo standby. Le sezioni seguenti illustrano i passaggi necessari per configurarli con facilit\u00e0.<\/p>\n Potete configurare il nodo primario per la replica in streaming eseguendo i seguenti passaggi:<\/p>\n Per inizializzare il database<\/a>, potete usare il comando L’utente dovr\u00e0 fornire una password e un nome utente per la query indicata. La parola chiave replica viene utilizzata per dare all’utente i privilegi richiesti. Un esempio di query potrebbe essere il seguente:<\/p>\n Successivamente, potete configurare le propriet\u00e0 dello streaming con il file di configurazione di PostgreSQL (postgresql.conf<\/strong>) che pu\u00f2 essere modificato come segue:<\/p>\n Ecco un po’ di informazioni sui parametri usati nel frammento precedente:<\/p>\n Dopo aver modificato i parametri nel file postgresql.conf<\/strong>, una nuova voce di replica nel file pg_hba.conf<\/strong> pu\u00f2 consentire ai server di stabilire una connessione reciproca per la replica.<\/p>\n Di solito questo file si trova nella directory dei dati di PostgreSQL. Per farlo, potete usare il seguente snippet di codice:<\/p>\n Una volta eseguito lo snippet di codice, il server primario permette a un utente chiamato Per configurare il nodo standby per la replica in streaming, seguite i seguenti passaggi:<\/p>\n Per configurare il nodo standby, usate l’utility I parametri usati nella sintassi di cui sopra sono i seguenti:<\/p>\n Successivamente, dovete verificare se il file di configurazione della replica esiste. Se non esiste, potete generare il file di configurazione della replica come recovery.conf<\/strong>.<\/p>\n Dovete creare questo file nella directory dei dati dell’installazione di PostgreSQL. Potte generarlo automaticamente usando l’opzione Il file recovery.conf<\/strong> deve contenere i seguenti comandi:<\/p>\n I parametri utilizzati nei suddetti comandi sono i seguenti:<\/p>\n Per impostare una connessione, dovete fornire il nome utente, l’indirizzo IP e la password come valori del parametro primary_conninfo. Per esempio:<\/p>\n Infine, potete riavviare il server secondario per completare il processo di configurazione.<\/p>\n Tuttavia, la replica in streaming comporta diverse sfide, come per esempio:<\/p>\n L’metodo del dispositivo a blocchi replicato dipende dal mirroring del disco (noto anche come replica del volume). In questo approccio, le modifiche vengono scritte su un volume persistente che viene sincronizzato con un altro volume.<\/p>\n Il vantaggio di questo metodo \u00e8 la compatibilit\u00e0 e la durata dei dati in ambienti cloud con tutti i database relazionali, tra cui PostgreSQL, MySQL e SQL Server<\/a>, per citarne alcuni.<\/p>\n Tuttavia, l’metodo alla replica di PostgreSQL basato sul mirroring del disco richiede la replica sia dei log WAL che dei dati delle tabelle. Dal momento che ogni scrittura sul database deve passare attraverso la rete in modo sincrono, non potete permettervi di perdere nemmeno un byte, perch\u00e9 questo potrebbe lasciare il vostro database in uno stato corrotto.<\/p>\n Questo approccio viene normalmente utilizzato con Azure PostgreSQL e Amazon RDS.<\/p>\n Il WAL consiste in file di segmenti (16 MB per impostazione predefinita). Ogni segmento contiene uno o pi\u00f9 record. Un record di sequenza di log (LSN) \u00e8 un puntatore a un record nel WAL, che consente di conoscere la posizione\/localit\u00e0 in cui il record \u00e8 stato salvato nel file di log.<\/p>\n Un server standby sfrutta i segmenti WAL – noti anche come XLOGS nella terminologia di PostgreSQL – per replicare continuamente le modifiche dal server primario. Potete usare il write-ahead logging per garantire la durabilit\u00e0 e l’atomicit\u00e0 di un DBMS serializzando pezzi di dati byte-array (ognuno con un LSN univoco) in uno storage stabile prima che vengano applicati al database.<\/p>\n L’applicazione di una mutazione a un database pu\u00f2 portare a diverse operazioni sul file system. Una domanda pertinente che sorge spontanea \u00e8 come un database possa garantire l’atomicit\u00e0 in caso di guasto del server dovuto a un’interruzione di corrente mentre \u00e8 nel bel mezzo di un aggiornamento del file system. Quando un database si avvia, inizia un processo di avvio o replay che pu\u00f2 leggere i segmenti WAL disponibili e confrontarli con l’LSN memorizzato su ogni pagina di dati (ogni pagina di dati \u00e8 contrassegnata con l’LSN dell’ultimo record WAL che riguarda la pagina).<\/p>\n La replica in streaming perfeziona il processo di spedizione dei log. Invece di aspettare il passaggio al WAL, i record vengono inviati man mano che vengono creati, riducendo cos\u00ec il ritardo della replica.<\/p>\n La replica in streaming supera anche il log shipping perch\u00e9 il server standby si collega al server primario attraverso la rete sfruttando un protocollo di replica. Il server primario pu\u00f2 quindi inviare i record WAL direttamente attraverso questa connessione senza dover dipendere dagli script forniti dall’utente finale.<\/p>\n Il log shipping \u00e8 definito come la copia dei file di log su un altro server PostgreSQL per generare un altro server di standby riproducendo i file WAL. Questo server \u00e8 configurato per funzionare in modalit\u00e0 di recupero e il suo unico scopo \u00e8 quello di applicare i nuovi file WAL non appena si presentano.<\/p>\n Questo server secondario diventa quindi un backup a caldo del server PostgreSQL primario. Pu\u00f2 anche essere configurato per essere una replica di lettura, dove pu\u00f2 offrire query di sola lettura, anche detta hot standby.<\/p>\n La duplicazione dei file WAL man mano che vengono creati in una posizione diversa dalla sottodirectory Lo script pu\u00f2 sfruttare il comando Altre configurazioni basate sui log includono:<\/p>\n Un processo noto come ricevitore WAL, in esecuzione sul server standby, sfrutta i dettagli della connessione forniti nel parametro Per avviare la replica in streaming, il frontend pu\u00f2 inviare il parametro di replica nel messaggio di avvio. Un valore booleano di true, yes, 1 o ON fa capire al backend<\/a> che deve passare alla modalit\u00e0 walsender di replica fisica.<\/p>\n Il WAL sender \u00e8 un altro processo che viene eseguito sul server primario e ha il compito di inviare i record WAL al server standby quando vengono generati. Il ricevitore WAL salva i record WAL nel WAL come se fossero stati creati dall’attivit\u00e0 dei client connessi localmente.<\/p>\n Una volta che i record WAL raggiungono i file di segmento WAL, il server standby continua a riprodurre costantemente il WAL in modo che il server primario e quello standby siano aggiornati.<\/p>\n In questa sezione, potete approfondire la conoscenza dei modelli comunemente utilizzati (replica single-master e multi-master), dei tipi (replica fisica e logica) e delle modalit\u00e0 (sincrona e asincrona) della replica PostgreSQL.<\/p>\n Scalabilit\u00e0 significa aggiungere altre risorse\/ hardware ai nodi esistenti per migliorare la capacit\u00e0 del database di memorizzare ed elaborare pi\u00f9 dati, il che pu\u00f2 essere ottenuto in modo orizzontale e verticale. La replica di PostgreSQL \u00e8 un esempio di scalabilit\u00e0 orizzontale che \u00e8 molto pi\u00f9 difficile da implementare rispetto alla scalabilit\u00e0 verticale. La scalabilit\u00e0 orizzontale pu\u00f2 essere ottenuta principalmente tramite la replica single-master (SMR) e la replica multi-master (MMR).<\/p>\n La replica single-master consente di modificare i dati solo su un singolo nodo e di replicare le modifiche su uno o pi\u00f9 nodi. Le tabelle replicate nel database di replica non possono accettare alcuna modifica, tranne quelle provenienti dal server primario. Anche se lo fanno, le modifiche non vengono replicate al server primario.<\/p>\n Nella maggior parte dei casi, la SMR \u00e8 sufficiente per l’applicazione perch\u00e9 \u00e8 meno complicata da configurare e gestire, oltre a non avere possibilit\u00e0 di conflitti. La replica single-master \u00e8 anche unidirezionale, in quanto i dati di replica fluiscono principalmente in una direzione, dal database primario a quello di replica.<\/p>\n In alcuni casi, la sola SMR potrebbe non essere sufficiente e potrebbe essere necessario implementare la MMR. L’MMR permette a pi\u00f9 di un nodo di agire come nodo primario. Le modifiche alle righe delle tabelle in pi\u00f9 di un database primario designato vengono replicate alle tabelle corrispondenti in ogni altro database primario. In questo modello, spesso si usano schemi di risoluzione dei conflitti per evitare problemi come la duplicazione delle chiavi primarie.<\/p>\n L’utilizzo dell’MMR presenta alcuni vantaggi, tra cui:<\/p>\n Tuttavia, l’aspetto negativo dell’implementazione dell’MMR \u00e8 la complessit\u00e0 e la difficolt\u00e0 di risolvere i conflitti.<\/p>\n Diversi rami e applicazioni forniscono soluzioni MMR, dato che PostgreSQL non lo supporta in modo nativo. Queste soluzioni possono essere open-source<\/a>, gratuite o a pagamento. Una di queste \u00e8 la replica bidirezionale (BDR)<\/a> che \u00e8 asincrona e si basa sulla funzione di decodifica logica di PostgreSQL.<\/p>\n Poich\u00e9 l’applicazione BDR riproduce le transazioni su altri nodi, l’operazione di replay pu\u00f2 fallire se c’\u00e8 un conflitto tra la transazione applicata e quella impegnata sul nodo ricevente.<\/p>\n Esistono due tipi di replica PostgreSQL: la replica logica e quella fisica.<\/p>\n Una semplice operazione logica<\/em> La replica fisica di solito si occupa di file e directory. Non sa cosa rappresentino questi file e directory. Questi metodi sono utilizzati per mantenere una copia completa di tutti i dati di un singolo cluster, in genere su un’altra macchina, e vengono eseguiti a livello di file system o di disco e usano indirizzi di blocco esatti.<\/p>\n La replica logica \u00e8 un modo per riprodurre le entit\u00e0 di dati e le loro modifiche, basandosi sulla loro identit\u00e0 di replica (di solito una chiave primaria). A differenza della replica fisica, si occupa di database, tabelle e operazioni DML e avviene a livello di cluster di database. Usa un modello publish<\/em> e subscribe<\/em> in cui uno o pi\u00f9 sottoscrittori<\/em> sono abbonati a una o pi\u00f9 pubblicazioni<\/em> su un nodo editore<\/em>.<\/p>\n Il processo di replica inizia con l’acquisizione di un’istantanea dei dati sul database dell’editore e la successiva copia sul sottoscrittore. Gli abbonati estraggono i dati dalle pubblicazioni a cui si abbonano e possono ripubblicare i dati in un secondo momento per consentire la replica a cascata o configurazioni pi\u00f9 complesse. L’abbonato applica i dati nello stesso ordine dell’editore in modo da garantire la coerenza transazionale delle pubblicazioni all’interno di un singolo abbonamento, nota anche come replica transazionale.<\/p>\n I casi d’uso tipici della replica logica sono:<\/p>\n Il database sottoscrittore si comporta come qualsiasi altra istanza di PostgreSQL e pu\u00f2 essere utilizzato come editore per altri database definendo le sue pubblicazioni.<\/p>\n Se il subscriber \u00e8 trattato come di sola lettura dall’applicazione, non ci saranno conflitti da una singola sottoscrizione. D’altra parte, se ci sono altre scritture effettuate da un’applicazione o da altri sottoscrittori sullo stesso insieme di tabelle, possono sorgere dei conflitti.<\/p>\n PostgreSQL supporta entrambi i meccanismi contemporaneamente. La replica logica consente un controllo a grana fine sia sulla replica dei dati che sulla sicurezza.<\/p>\n Le modalit\u00e0 di replica di PostgreSQL sono principalmente due: sincrona e asincrona. La replica sincrona permette di scrivere i dati contemporaneamente sul server primario e su quello secondario, mentre la replica asincrona garantisce che i dati vengano prima scritti sull’host e poi copiati sul server secondario.<\/p>\n Nella replica in modalit\u00e0 sincrona, le transazioni sul database primario sono considerate complete solo quando le modifiche sono state replicate a tutte le repliche. I server di replica devono essere tutti sempre disponibili affinch\u00e9 le transazioni sul primario siano completate. La modalit\u00e0 di replica sincrona viene utilizzata in ambienti transazionali di alto livello con requisiti di failover immediato.<\/p>\n In modalit\u00e0 asincrona, le transazioni sul server primario possono essere dichiarate completate quando le modifiche sono state effettuate solo sul server primario. Queste modifiche vengono poi replicate nelle repliche in un secondo momento. I server di replica possono rimanere non sincronizzati per un certo periodo di tempo, chiamato ritardo di replica. In caso di crash, si pu\u00f2 verificare una perdita di dati, ma l’overhead fornito dalla replica asincrona \u00e8 ridotto, quindi \u00e8 accettabile nella maggior parte dei casi (non sovraccarica l’host). Il failover dal database primario a quello secondario richiede pi\u00f9 tempo rispetto alla replica sincrona.<\/p>\n In questa sezione vi mostreremo come impostare il processo di replica di PostgreSQL su un sistema operativo Linux. In questo caso, utilizzeremo Ubuntu 18.04 LTS e PostgreSQL 10.<\/p>\nCos’\u00c8 la Replica PostgreSQL?<\/h2>\n
![\"Illustrazione](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/PostgreSQL-Replication-Illustration.png\")
Cos’\u00e8 il Failover Automatico?<\/h3>\n
Vantaggi dell\u2019Uso della Replica PostgreSQL<\/h2>\n
\n
Come Funziona la Replica PostgreSQL<\/h2>\n
\n
Metodo 1: Streaming<\/h3>\n
Configurazione del Nodo Primario<\/h4>\n
Passo 1: Inizializzare il Database<\/h5>\n
initidb<\/code> utility. Successivamente, potete creare un nuovo utente con privilegi di replica utilizzando il seguente comando:<\/p>\nCREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';<\/code><\/pre>\nCREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';<\/code><\/pre>\nPasso 2: Configurare le Propriet\u00e0 di Streaming<\/h5>\n
wal_level = logical\nwal_log_hints = on\nmax_wal_senders = 8\nmax_wal_size = 1GB\nhot_standby = on<\/code><\/pre>\n\n
wal_log_hints<\/code>:<\/strong> Questo parametro \u00e8 necessario per la funzionalit\u00e0 pg_rewind<\/code> che si rivela utile quando il server standby non \u00e8 sincronizzato con il server principale.<\/li>\nwal_level<\/code>:<\/strong> Potete usare questo parametro per abilitare la replica in streaming di PostgreSQL, con valori possibili come minimal<\/code>, replica<\/code>, o logical<\/code>.<\/li>\nmax_wal_size<\/code>:<\/strong> Questo parametro pu\u00f2 essere usato per specificare la dimensione dei file WAL che possono essere conservati nei file di log.<\/li>\nhot_standby<\/code>:<\/strong> Potete sfruttare questo parametro per una connessione in lettura con il secondario quando \u00e8 impostato su ON.<\/li>\nmax_wal_senders<\/code>:<\/strong> Potete usare max_wal_senders<\/code> per specificare il numero massimo di connessioni contemporanee che possono essere stabilite con i server standby.<\/li>\n<\/ul>\nPasso 3: Creare una Nuova Voce<\/h5>\n
host replication rep_user IPaddress md5<\/code><\/pre>\nrep_user<\/code> di connettersi e di agire come server standby utilizzando l’IP specificato per la replica. Per esempio:<\/p>\n host replication rep_user 192.168.0.22\/32 md5<\/code><\/pre>\nConfigurazione del Nodo Standby<\/h4>\n
Passo 1: Backup del Nodo Primario<\/h5>\n
pg_basebackup<\/code> per generare un backup del nodo primario. Questo servir\u00e0 come punto di partenza per il nodo standby. Potete usare questa utility con la seguente sintassi:<\/p>\npg_basebackp -D -h -X stream -c fast -U rep_user -W<\/code><\/pre>\n\n
-h<\/code>:<\/strong> Potete usare questo parametro per menzionare l’host primario.<\/li>\n-D<\/code>:<\/strong> Questo parametro indica la directory su cui state lavorando.<\/li>\n-C<\/code>:<\/strong> Potete usare questo parametro per impostare i checkpoint.<\/li>\n-X<\/code>:<\/strong> Questo parametro pu\u00f2 essere usato per includere i file di log transazionali necessari.<\/li>\n-W<\/code>:<\/strong> Potete usare questo parametro per richiedere all’utente una password prima di collegarsi al database.<\/li>\n<\/ul>\nPasso 2: Impostare il File di Configurazione della Replica<\/h5>\n
-R<\/code> dell’utility pg_basebackup<\/code>.<\/p>\nstandby_mode = 'on'<\/code><\/p>\nprimary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name=\"host_name\"'
\n<\/code><\/p>\nrecovery_target_timeline = 'latest'<\/code><\/p>\n\n
primary_conninfo<\/code>:<\/strong> Potete usare questo parametro per creare una connessione tra il server primario e quello secondario sfruttando una stringa di connessione.<\/li>\nstandby_mode<\/code>:<\/strong> Questo parametro pu\u00f2 far s\u00ec che il server primario parta come standby quando viene acceso.<\/li>\nrecovery_target_timeline<\/code>:<\/strong> Potete usare questo parametro per impostare il tempo di ripristino.<\/li>\n<\/ul>\nprimary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'<\/code><\/pre>\nPasso 3: Riavviare il Server Secondario<\/h5>\n
\n
Metodo 2: Dispositivo a Blocchi Replicato<\/h3>\n
Metodo 3: WAL<\/h3>\n
Replica Basata sul Log Shipping (Livello di Blocco)<\/h4>\n
Replica Basata sul Log Shipping (Livello File)<\/h4>\n
Archiviazione WAL Continua<\/h4>\n
pg_wal<\/code> per archiviarli \u00e8 nota come archiviazione WAL. PostgreSQL richiama uno script fornito dall’utente per l’archiviazione, ogni volta che viene creato un file WAL.<\/p>\nscp<\/code> per duplicare il file in una o pi\u00f9 posizioni, come per esempio un mount NFS. Una volta archiviati, i file WAL possono essere utilizzati per recuperare il database in qualsiasi momento.<\/p>\n\n
Dettagli del Protocollo di Streaming WAL<\/h4>\n
primary_conninfo<\/code> di recovery.conf<\/strong> e si connette al server primario sfruttando una connessione TCP\/IP.<\/p>\n![\"Un](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/WAL-Streaming-Protocol-Details.png\")
Elementi di Replica PostgreSQL<\/h2>\n
Modelli di Replica dei Database PostgreSQL<\/h3>\n
\n
Tipi di Replica PostgreSQL<\/h3>\n
initdb<\/code>\u00a0esegue l’operazione fisica di creazione di una directory di base per un cluster. Allo stesso modo, una semplice operazione logica<\/em> CREATE DATABASE<\/code>\u00a0eseguir\u00e0 l’operazione fisica<\/em> di creazione di una sottodirectory nella directory di base.<\/p>\n\n
Modalit\u00e0 di Replica<\/h3>\n
Come Impostare la Replica di PostgreSQL<\/h2>\n