Informazioni sull'estensione pglogical

Seleziona una versione della documentazione:

Questa pagina fornisce una panoramica dell'estensione pglogical, dei suoi vantaggi e delle sue limitazioni.

Panoramica

L'estensione pglogical è uno strumento di replica logica robusto e flessibile progettato per PostgreSQL e supporta anche l'alta affidabilità (HA) e il ripristino di emergenza (RE).

La replica binaria tradizionale, comunemente nota come replica fisica, replica le modifiche a livello di file system e blocchi, con conseguente mirror fisico nel sistema di destinazione. Anche se la replica fisica è robusta e protegge l'intero cluster di database, è unidirezionale e richiede l'accesso al file di dati del database sottostante e ai file di log write-ahead (WAL).

L'estensione pglogical estrae le modifiche SQL da un database del provider, le replica e le riproduce in uno o più database degli abbonati. Questa replica è nota come replica logica.

Utilizzando l'estensione pglogical, puoi:

  • Replicare i dati tra più database AlloyDB Omni.
  • Replicare i dati tra AlloyDB Omni e Google Cloud AlloyDB.
  • Replicare i dati tra AlloyDB Omni e altre distribuzioni PostgreSQL, tra cui molte nei 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 replicare e dove. Puoi scegliere le tabelle da includere e come gestire le nuove tabelle, se includerle o meno. Puoi anche aggiungere filtri per colonne e righe. Puoi aggiungere un apply delay facoltativo per le situazioni in cui vuoi che l'abbonato rappresenti un punto nel tempo successivo a quello del provider.

  • Replica bidirezionale e multi-primaria: tutti i database membri sono aperti in uno stato di lettura/scrittura e sono completamente utilizzabili. Ogni database endpoint funge sia da provider che da abbonato, consentendo la creazione di scenari di replica avanzati e la possibilità di aggiornamenti dei dati eseguiti su endpoint diversi.

  • Supporto dei provider cloud: i provider cloud come Google riconoscono il valore dell'estensione pglogical e la integrano nei loro servizi cloud, come Google Cloud SQL per PostgreSQL e AlloyDB. Anche altri provider cloud includono l'estensione pglogical come opzione, consentendo configurazioni multi-cloud o cloud ibrido.

  • Replica tra versioni: poiché pglogical replica le istruzioni SQL effettive, consente la replica tra le versioni principali di PostgreSQL. Soprattutto quando il database di origine del provider è una versione precedente rispetto al database di destinazione dell'abbonato, la replica tra versioni può essere implementata con affidabilità.

    L'estensione pglogical offre il supporto per molte versioni precedenti di PostgreSQL, come la versione 9.4 e successive. Ciò la 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 dal cloud, tra cui 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 gestione errata può interrompere il processo di replica.

Tieni presente i seguenti punti per un'implementazione affidabile:

  • Considera come gestire gli oggetti con ambito database e ambito cluster che non rientrano nell'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.
  • Ti consigliamo che tutte le tabelle di replica abbiano una chiave primaria. È possibile utilizzare la funzionalità REPLICA IDENTITY della tabella per informare l'estensione pglogical su quali colonne identificano in modo univoco le righe. Se possibile, evita questa operazione. Le tabelle che non hanno chiavi primarie sono statiche per natura e non vengono mai UPDATED o DELETED e supportano solo INSERTS. Questi tipi di tabelle non richiedono chiavi primarie.
  • Gestione di trigger e sequenze nei database degli abbonati. Per impostazione predefinita, i trigger sono definiti come trigger ORIGIN o LOCAL e non vengono attivati nel database degli abbonati quando le righe vengono replicate. È necessario controllare tutti i trigger per assicurarsi che l'opzione REPLICA sia impostata per qualsiasi trigger in modo che non venga attivato sull'abbonato, a meno che non sia necessario.
  • Gestione della risoluzione dei conflitti manualmente o automaticamente tramite le regole who wins.
  • Replica dei comandi Data Definition Language (DDL) implementandoli manualmente su tutti gli endpoint o replicando automaticamente il 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 nei database primari.
  • Assicurati che esista una rete TCP robusta, efficiente, affidabile e sicura tra tutti gli endpoint nella topologia di replica.

Altre restrizioni e limitazioni dell'estensione pglogical includono le seguenti:

  • Sono richieste autorizzazioni di superutente per pglogical versione 2.4.3.
  • Anche se la maggior parte delle tabelle e delle sequenze può essere replicata, altri tipi di oggetti non vengono replicati dall'estensione pglogical e le tabelle TEMPORARY e UNLOGGED non vengono replicate.
  • Per replicare il DDL, è necessario utilizzare la funzione API pglogical. I comandi DDL nativi non vengono replicati, ad eccezione del comando TRUNCATE.
  • Opera a livello di oggetto per tabella e per sequenza e viene eseguito il deployment per database. Ciò significa che alcuni oggetti, inclusi gli oggetti con ambito cluster come users e roles, vengono esclusi dalla replica e devono essere gestiti separatamente.

Passaggi successivi