Come ottimizzare la replica logica di PostgreSQL

La replica logica o Pglogical è un meccanismo di replica basato su WAL a livello di tabella che replica i dati di tabelle specifiche tra due istanze PostgreSQL. Sembra esserci una confusione tra “pglogical” e “Logical Replication”. Entrambi forniscono lo stesso tipo di meccanismo di replica con alcune differenze in termini di funzionalità e capacità. La replica logica è introdotta in PostgreSQL-10 come funzionalità integrata a differenza di pglogical che è un'estensione. "Pglogical" con continui sviluppi continui, rimane l'unica opzione per implementare la replica logica per quegli ambienti che utilizzano versioni di PostgreSQL precedenti alla 10. Alla fine, tutte le funzionalità di pglogical faranno parte della replica logica. In altre parole, pglogical (estensione) è diventato Replicazione logica (funzionalità integrata). Il vantaggio di base della replica logica è che non necessita di alcuna estensione da installare/creare, il che a sua volta è vantaggioso per quegli ambienti in cui l'installazione di estensioni è limitata.

Questo blog si concentrerà sull'ottimizzazione della replica logica. Ciò significa che i suggerimenti e le tecniche di ottimizzazione evidenziati in questo blog si applicheranno sia alla replica pglogica che alla replica logica.

La replica logica è una replica basata su WAL che è la prima nel suo genere. Come DBA, questo sarebbe un meccanismo di replica molto più affidabile e performante rispetto ad altre soluzioni di replica basate su trigger. Le modifiche apportate alle tabelle che fanno parte della replica pglogica vengono replicate in tempo reale tramite record WAL che la rendono altamente efficiente e non complessa. Tutti gli altri meccanismi di replica sul mercato sono basati su trigger che possono porre problemi di prestazioni e manutenzione. Con l'arrivo della replica logica, la dipendenza dalla replica basata su trigger è quasi scomparsa.

Ci sono altri blog che spiegano come configurare la replica logica in modo abbastanza dettagliato.

In questo blog, il focus sarà su come ottimizzare la replica logica.

Ottimizzazione della replica logica

Per cominciare, il comportamento di "Replica logica" è abbastanza simile a "Replica in streaming", l'unica differenza è che la replica in streaming replica l'intero database mentre la replica logica replica solo singole tabelle. Quando si scelgono singole tabelle specifiche da replicare, ci sono fattori/sfide da prevedere.

Diamo un'occhiata ai fattori che influenzano la replica logica.

Fattori che influenzano le prestazioni della replica logica

L'ottimizzazione della replica logica è importante per garantire che i dati vengano replicati senza interruzioni, senza interruzioni. Ci sono fattori da prevedere prima di configurarlo. Diamo un'occhiata a loro:

• Il tipo di dati archiviati nelle Tabelle da replicare
• Quanto sono attive a livello transazionale le tabelle (parte della replica)
• Deve essere prevista la capacità dell'infrastruttura
• La configurazione dei parametri deve essere eseguita in modo ottimale

Tutti i suddetti fattori influenzano maggiormente la replica logica. Vediamoli nel dettaglio.

Tipi di dati di replica logica PostgreSQL

È importante comprendere il tipo di dati archiviati nella tabella. Se la parte tabellare della replica archivia testo di grandi dimensioni o oggetti binari e rileva un numero elevato di transazioni, la replica potrebbe rallentare a causa dell'utilizzo elevato delle risorse dell'infrastruttura. La capacità dell'infrastruttura deve essere adeguata a gestire repliche di dati così complesse e di grandi dimensioni.

In che modo le tabelle attive sono parte transazionale della replica

Quando si replicano tabelle altamente attive a livello transazionale, la replica potrebbe rimanere indietro nella sincronizzazione a causa di problemi di prestazioni di I/O, deadlock e così via, che devono essere presi in considerazione. Ciò potrebbe non rendere gli ambienti di database di produzione più sani. Se il numero di tabelle da replicare è elevato e i dati vengono replicati su più siti, potrebbe esserci un elevato utilizzo della CPU e potrebbe essere necessario un numero maggiore di CPU (o core CPU).

Capacità dell'infrastruttura

Prima di considerare la replica logica come una soluzione, è importante assicurarsi che la capacità dell'infrastruttura dei server di database sia sufficientemente adeguata. Se viene replicato un numero elevato di tabelle, è necessario disporre di CPU sufficienti per eseguire il processo di replica.

Quando si replica un numero elevato di tabelle, considerare la possibilità di dividerle in gruppi e di replicarle in parallelo. Anche in questo caso, sarà necessario che più CPU siano disponibili per la replica. Se le modifiche dei dati alle tabelle da replicare sono frequenti e elevate, ciò potrebbe influire anche sulle prestazioni di replica.

Ottimizzazione dei parametri per la replica logica

I parametri configurati per il funzionamento della replica logica devono essere ottimizzati per garantire che la replica non si interrompa.

Diamo prima un'occhiata ai parametri necessari per configurarlo:

wal_level=’logical’
max_wal_senders=10                     # greater than number of subscribers (or replicas)
max_replication_slots=10              # greater than number of subscribers (or replicas)
max_worker_processes=10           # greater than number of subscribers (or replicas)
max_logical_replication_workers  # greater than number of subscribers (or replicas)
max_sync_workers_per_subscription # depends on number of tables being replicated

Ottimizzazione di max_wal_senders

max_wal_senders deve essere sempre maggiore del numero di repliche. Se i dati vengono replicati su più siti, entrano in gioco più max_wal_senders. Pertanto, è importante assicurarsi che questo parametro sia impostato su un numero ottimale.

Ottimizzazione max_replication_slots

In generale, tutte le modifiche ai dati che si verificano sulle tabelle vengono scritte nei file WAL in pg_xlog / pg_wal che sono definiti record WAL. Il processo del mittente Wal raccoglierà quei record WAL (appartenenti alle tabelle da replicare) e li invierà alle repliche e il processo wal_receiver sul sito di replica applicherà tali modifiche al nodo dell'abbonato.

I file WAL vengono rimossi dalla posizione pg_xlog/pg_wal ogni volta che si verifica il checkpoint. Se i file WAL vengono rimossi anche prima che le modifiche vengano applicate al nodo dell'abbonato, la replica si interromperà e resterà indietro. Nel caso in cui il nodo dell'abbonato sia in ritardo, uno slot di replica assicurerebbe che tutti i file WAL necessari all'abbonato per sincronizzarsi con il provider vengano conservati. Si consiglia di configurare uno slot di replica per ciascun nodo abbonato.

Ottimizzazione di max_worker_processes

È importante avere un numero ottimale di processori di lavoro configurato. Questo dipende dal numero massimo di processi che un server può avere. Questo è possibile solo in ambienti multi-CPU. Max_worker_processes assicurerà che vengano generati più processi per portare a termine il lavoro in modo più rapido utilizzando più core della CPU. Quando si replicano i dati utilizzando la replica logica, questo parametro può aiutare a generare più processi di lavoro per replicare i dati più velocemente. Esiste un parametro specifico chiamato max_logical_worker_processes che garantirà l'utilizzo di più processi per copiare i dati.

Ottimizzazione di max_logical_worker_processes

Questo parametro specifica il numero massimo di processi di lavoro logici necessari per eseguire la replica e la sincronizzazione dei dati delle tabelle. Questo valore è preso da max_worker_processes che dovrebbe essere maggiore del valore di questo parametro. Questo parametro è molto utile quando si replicano i dati su più siti in ambienti con più CPU. Il valore predefinito è 4. Il valore massimo dipende dal numero di processi di lavoro supportati dal sistema.

Ottimizzazione di max_sync_workers_per_subscription

Questo parametro specifica il numero massimo di processi di sincronizzazione richiesti per sottoscrizione. Il processo di sincronizzazione avviene durante la sincronizzazione iniziale dei dati e per garantire che ciò avvenga più velocemente è possibile utilizzare questo parametro. Attualmente, è possibile configurare un solo processo di sincronizzazione per tabella, il che significa che è possibile sincronizzare più tabelle inizialmente in parallelo. Il valore predefinito è 2. Questo valore viene prelevato dal valore max_logical_worker_processes.

Questi sono i parametri che devono essere regolati per garantire che la replica logica sia efficiente e veloce. Gli altri parametri che influiscono anche sulla replica logica sono i seguenti.

wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval.

Questi parametri non hanno alcun effetto sul nodo del provider.

Conclusione

Le tabelle specifiche per la replica sono un requisito comune che si verifica nei sistemi di database grandi e complessi. Questo potrebbe essere per scopi di reportistica aziendale o di Data Warehousing. In qualità di DBA, credo che la replica logica soddisfi ampiamente tali scopi grazie alla sua facile implementazione con meno complessità. Configurazione e ottimizzazione della replica logica richiede una buona quantità di pianificazione, architettura e test. La quantità di dati replicati in tempo reale deve essere valutata per garantire che sia attivo un sistema di replica efficiente e privo di apparenza. Per concludere, i database in esecuzione in PostgreSQL-10, la replica logica è la strada da percorrere e per quei database in esecuzione nelle versioni di PostgreSQL <10, pglogical è l'opzione.