Replicació lògica PostgreSQL

De HLV Wiki
La revisió el 21:43, 27 març 2019 per Roger (discussió | contribucions) (Bibliografia)
(dif) ← Versió més antiga | Versió actual (dif) | Versió més nova → (dif)
Salta a: navegació, cerca

Introducció

La replicació lògica és un mecanisme que permet tenir dues o més rèpliques d'una mateixa base de dades, possiblement en servidors diferents, de manera que els canvis que es fan en una d'aquestes base de dades es propaga en les altres. Habitualment existeix una base de dades anomenade "mestre" que és on es fan les modificacions, mentre que les altres són les que van rebent els canvis fets en la base de dades mestre. Un dels avantatges que té utilitzar bases de dades replicades és el fet que si cau el servidor on hi ha la bse de dades mestre, un dels servidors que té rèpliques pot esdevenir la base de dades mestre i el sistema pot continuar funcionant. No obstant, aquesta no és la única avantatge ni la única configuració possible, podent per exemple tenir una base de dades global que tingui una rèplica de les dades de diverses bases de dades locals en les quals s'hi van fent modificacions. D'aquesta manera podriem utilitzar la base de dades global per a treure estadístiques, sense afectar a l'operativa de les bases de dades locals.


El cas de postgreSQL

PostgreSQL soporta de manera nativa la replicació lògica a partir de la versió 10 (en el moment d'escriure aquest PAD la última versió de postgreSQL és la 11.2

PostgreSQL utilitza el mètode de publicadors i subscriptors per realitzar replicacions lògiques. Aquest sistema és bastant flexible, i permet definir quins nodes són els que envien els canvis que s'hi realitzin (publicadors) i quins nodes reben els canvis dels publicadors (subscriptors). D'aquesta manera, un subscriptor es subscriu a les publicacions que realitza un publicador, per tal d'anar actualitzant la seva informació a partir dels canvis que es facin en el node publicador. Aquests canvis s'envien com si fossin comandes SQL (INSERT, UPDATE, DELETE), d'aquí el nom de replicació lògica. No es tracta, doncs, d'una replicació byte a byte, sinó que els canvis lògics es propaguen com si els comandes SQL que els han provocat s'executessin també en el node subscriptor.

Cal que l'esquema de la base de dades del subscriptor sigui compatible amb l'esquema de la base de dades del publicador. Això significa que la base de dades del subscriptor ha de tenir creades les taules del node publicador (o si més no, ha de tenir les taules de les dades que el publicador publica), i també ha de tenir els mateixos camps (amb els mateixos noms i tipus de dades), o si més no un superconjunt d'aquests (és a dir, la taula en el subscriptor pot tenir algun camp extra, però ha de tenir com a mínim tots els camps de la taula del publicador).

Es pot donar el cas que una base de dades publiqui unes dades, i a la vegada estigui subscrita a unes altres. Així doncs, un servidor podria consumir dades d'un altre servidor i a la vegada enviar dades a un tercer servidor.

Conflictes

Degut a que el publicador envia comandes al subscriptor, poden aparèixer conflictes en aquestes instruccions, a l'igual que passaria si s'executessin manualment aquestes instruccions. Per exemple, si en el subscriptor existeix un registre que el publicador no tenia, per exemple perquè s'ha insertat manualment, i després aquest mateix registre fos inserit en el publicador, en propagar-se donaria un error de clau duplicada. Per aquest motiu, acostuma a ser convenient restringir a l'usuari per tal que no pugui fer modificacions en la base de dades que és subscriptora. Aquesta restricció es pot imposar per exemple donant a l'usuari només permís per a consultar dades.

En cas de tenir un subscriptor a diferents bases de dades, per exemple perquè el subscriptor conté les dades universals que és la unió d'un conjunt de dades locals, existeix el risc de que dues bases de dades locals puguin tenir registres amb els mateixos identificadors. Això passa especialment quan es fan servir camps de tipus serial. En aquests casos convindria utilitzar camps de tipus UUID en comptes de serial per tal de garantir que els identificadors no es repeteixin mai. Es pot trobar més informació sobre UUID en el manual de Postgres: [1] https://www.postgresql.org/docs/9.1/datatype-uuid.html

Paràmetres de configuració

Cal editar el fitxer postgresql.conf per tal de modificar aquests paràmetres:

wal_level: cal configurar-lo amb el valor 'logical'

La resta dels paràmetres normalment ja estaran configurats correctament amb la configuració per defecte, no obstant, pot ser bona idea revisar-ho i posar-los segons el que s'explica a: [2] https://www.postgresql.org/docs/10/logical-replication-config.html

Configuració en el subscriptor

Configuració en el publicador

Cal editar el fitxer pg_hba.conf del publicador per tal d'autoritzar que el subscriptor s'hi connecti. Per a fer-ho, cal afegir la següent línia:

host     all                  all                   192.168.1.25/32       trust

on 192.168.1.25 és la IP del subscriptor que es pot connectar. En cas de voler diversos subscriptors, es pot afegir diverses línies, o bé afegir tot un rang d'IPs en notació CIDR (pe rexemple, 192.168.1.0/24)

Cal tenir en compte que qualsevol modificació que es faci en els fitxers de configuració, pot requerir que calgui reiniciar el servidor de postgresql per tal que aquesta faci efecte.

Crear publicacions

Utilitzarem la instrucció CREATE PUBLICATION per crear publicacions: [3] https://www.postgresql.org/docs/10/sql-createpublication.html

Exemple:

CREATE PUBLICATION publ_total FOR ALL TABLES;

Aquest exemple crearia una publicació anomenada publ_total que contindria la informació de totes les taules.

Crear subscripcions

Utilitzarem la instrucció CREATE SUBSCRIPTION per crear subscripcions: [4] https://www.postgresql.org/docs/10/sql-createsubscription.html Exemple:

CREATE SUBSCRIPTION subs_bd1    CONNECTION 'postgresql://[postgres/mypassword@192.168.1.22:5432/myDb'    PUBLICATION publ_total;

Aquest exemple es subscriuria a la publicació publ_total que hi ha a la base de dades myDb del servidor amb IP 192.168.1.22, al port 5432; i ho faria utilitzant l'usuari postgres i la contrasenya mypassword. En executar aquesta comanda, es crearà un snapshot de les taules publicades i s'ompliran les taules del subscriptor amb aquesta informació. Posteriorment la informació s'anirà sincronitzant automàticament del publicador al subscriptor.

Bibliografia

[5] https://www.postgresql.org/docs/10/logical-replication.html