Questa pagina fornisce una panoramica dell'estensione pglogical
, dei relativi vantaggi e limitazioni.
Panoramica
L'estensione pglogical
è uno strumento di replica logica robusto e flessibile progettato per PostgreSQL e supporta anche l'alta disponibilità (HA) e il ripristino di emergenza (RE).
La replica binaria tradizionale, nota comunemente come replica fisica, esegue la replica delle modifiche a livello di file system e blocco, generando un mirror fisico nel sistema di destinazione. Anche se la replica fisica è solida e protegge l'intero cluster di database, è solo unidirezionale e richiede l'accesso al file di dati del database sottostante e ai file WAL (log di scrittura anticipata).
L'estensione pglogical
, invece, estrae le modifiche SQL da un database del fornitore, le replica e poi le riproduce in uno o più database degli abbonati. Questa replica è nota come replica logica.
Con l'estensione pglogical
puoi:
- Replica i dati tra più database AlloyDB Omni.
- Replicare i dati tra AlloyDB Omni e Google Cloud AlloyDB.
- Replica i dati tra AlloyDB Omni e altre distribuzioni PostgreSQL che includono molti servizi cloud di terze parti.
Vantaggi
La replica logica con l'estensione pglogical
offre i seguenti vantaggi:
Replica selettiva:offre la flessibilità di impostare filtri e regole per determinare quali dati vuoi replicare e dove. Puoi scegliere quali tabelle includere e come gestire le nuove tabelle, indipendentemente dal fatto che siano incluse o meno. Puoi anche aggiungere filtri per colonne e righe. È possibile aggiungere un valore facoltativo
apply delay
per le situazioni in cui vuoi che l'abbonato rappresenti un punto finale nel tempo del provider.Replica bidirezionale e multi-principale:tutti i database dei membri sono aperti in stato di lettura/scrittura e sono completamente utilizzabili. Ogni database di endpoint funge da fornitore e sottoscrittore, consentendo la creazione di scenari di replica avanzati e la possibilità di aggiornamenti dei dati effettuati in endpoint diversi.
Supporto dei fornitori di servizi cloud: i fornitori di servizi cloud come Google riconoscono il valore dell'estensione
pglogical
e la integrano nei propri servizi cloud, come Google Cloud SQL per PostgreSQL e AlloyDB. Altri cloud provider includono anche l'estensionepglogical
come opzione, consentendo configurazioni multi-cloud o cloud ibride.Replica tra versioni:poiché pglogical replica gli statement SQL effettivi, consente la replica tra le versioni principali di PostgreSQL. Soprattutto quando il database di origine del fornitore è di una versione precedente rispetto al database di destinazione dell'abbonato, la replica tra versioni può essere implementata in modo affidabile.
L'estensione
pglogical
offre supporto per molte versioni precedenti di PostgreSQL, come la versione 9.4 e successive. Ciò lo rende una scelta ottimale per gli scenari in cui hai a che fare con sistemi legacy e vuoi replicare i dati in versioni più moderne di PostgreSQL, come quelle utilizzate in AlloyDB Omni e Google Cloud AlloyDB.
In sintesi, l'estensione pglogical
fornisce una soluzione di replica logica ricca di funzionalità, con compatibilità per le versioni precedenti di PostgreSQL e i servizi gestiti su Cloud che includono Google Cloud SQL per PostgreSQL e AlloyDB.
Limitazioni della replica logica
Tutte le tecnologie di replica logica, incluse quelle utilizzate con altre piattaforme di database relazionali, presentano alcune limitazioni e qualsiasi cattiva gestione può interrompere il processo di replica.
Per un'implementazione affidabile, tieni presente quanto segue:
- Considerazioni su come gestire gli oggetti a livello di database e di cluster che rientrano al di fuori dell'ambito della replica. L'estensione
pglogical
funziona a livello di database e solo su un insieme specificato di tabelle e sequenze. Altri tipi di oggetti, come funzioni e procedure, devono essere replicati utilizzando un altro metodo. - È consigliabile che tutte le tabelle di replica abbiano una chiave primaria.
È possibile utilizzare la funzionalità della tabella
REPLICA IDENTITY
per indicare all'estensionepglogical
quali colonne identificano in modo univoco le righe. Se possibile, questo deve essere evitato. Le tabelle che non hanno chiavi primarie sono di natura statica e non sono maiUPDATED
oDELETED
e supportano soloINSERTS
. Questi tipi di tabelle non richiedono chiavi primarie. - Gestione di trigger e sequenze nei database degli abbonati. Per impostazione predefinita, gli attivatori
vengono definiti come attivatori
ORIGIN
oLOCAL
e non vengono attivati nel database dell'abbonato quando le righe vengono replicate. Tutti gli attivatori devono essere controllati per assicurarsi che l'opzioneREPLICA
sia impostata per qualsiasi attivatore in modo che non venga attivato sul lato dell'abbonato, a meno che non sia necessario. - Gestire la risoluzione dei conflitti manualmente o automaticamente tramite le
who wins
regole. - Replica dei comandi DDL (Data Definition Language) mediante implementazione manuale su tutti gli endpoint o replica automatica del DDL nei database degli abbonati utilizzando la funzione API
pglogical
appropriata nel database del provider. - Assicurati che le tabelle e le sequenze appena create vengano aggiunte manualmente o automaticamente ai set di replica sui database principali.
- Assicurati che esista una rete TCP robusta, performante, affidabile e sicura tra tutti gli endpoint della topologia di replica.
Ulteriori restrizioni e limitazioni dell'estensione pglogical
includono quanto segue:
- Al momento, le autorizzazioni di superutente sono necessarie per la versione 2.4.3 di
pglogical
. - Sebbene la maggior parte delle tabelle e delle sequenze possa essere replicata, altri tipi di oggetti
non vengono replicati dall'estensione
pglogical
e le tabelleTEMPORARY
eUNLOGGED
non vengono replicate. - Per replicare il DDL, è necessario utilizzare la funzione dell'API pglogical. I comandi DDL
nativo non vengono replicati, ad eccezione del comando
TRUNCATE
. - Opera a livello di oggetto per tabella e sequenza e viene implementato per database. Ciò significa che alcuni oggetti, inclusi gli oggetti a livello di cluster come
users
eroles
, sono esclusi dalla replica e devono essere gestiti separatamente.
Passaggi successivi
- Eseguire la replica dei dati tra Google Cloud AlloyDB e AlloyDB Omni
- Eseguire la replica dei dati tra AlloyDB Omni e altri database