diff --git a/HowtoPostgreSQL.md b/HowtoPostgreSQL.md index dd51177b..da829c5f 100644 --- a/HowtoPostgreSQL.md +++ b/HowtoPostgreSQL.md @@ -3,7 +3,7 @@ title: Howto PostgreSQL categories: databases ... -* Documentation : +* Documentation : * Rôle Ansible : * The Internals of PostgreSQL : @@ -16,8 +16,8 @@ categories: databases # apt install postgresql -# /usr/lib/postgresql/9.6/bin/postgres -V -postgres (PostgreSQL) 9.6.6 +# /usr/lib/postgresql/11/bin/postgres -V +postgres (PostgreSQL) 11.5 (Debian 11.5-1+deb10u1) # systemctl status postgresql ● postgresql.service - PostgreSQL RDBMS @@ -30,7 +30,7 @@ postgres (PostgreSQL) 9.6.6 # pg_lsclusters Ver Cluster Port Status Owner Data directory Log file -9.6 main 5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log +11 main 5432 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log ~~~ > *Note* : il faut s'assurer d'avoir configuré sa locale système `dpkg-reconfigure locales` avant installation car l'initialisation des bases de données est faite avec la locale du système. @@ -43,31 +43,31 @@ Le dépôt **apt.postgresql.org** permet d'installer des versions différentes d Ajouter le dépôt un fichier `/etc/apt/sources.list.d/postgresql.list` : ~~~ -deb http://apt.postgresql.org/pub/repos/apt/ stretch-pgdg main +deb http://apt.postgresql.org/pub/repos/apt/ buster-pgdg main ~~~ Puis récupérer la clé GPG : ~~~ -# wget --quiet -O - https://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | apt-key add - +# wget https://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc -O /etc/apt/trusted.gpg.d/postgresql-org.asc ~~~ -On peut ainsi installer proprement PostgresSQL 10 - par exemple - en définissant les priorités via `/etc/apt/preferences.d/postgresql` : +On peut ainsi installer proprement PostgresSQL 11 - par exemple - en définissant les priorités via `/etc/apt/preferences.d/postgresql` : ~~~ Package: postgresql postgresql-client-common postgresql-common libpq5 libdbd-pg-perl ptop -Pin: release a=stretch-pgdg +Pin: release a=buster-pgdg Pin-Priority: 999 ~~~ Puis : ~~~ -# apt install postgresql-10 +# apt install postgresql-11 # pg_lsclusters Ver Cluster Port Status Owner Data directory Log file -10 main 5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log +11 main 5432 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log ~~~ ## Administration basique @@ -79,6 +79,7 @@ Ver Cluster Port Status Owner Data directory Log file Ver Cluster Port Status Owner Data directory Log file 9.6 main 5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log 10 main 5433 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log +11 main 5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log ~~~ ### Lister les requêtes actives @@ -1167,20 +1168,26 @@ huge_pages = on Plusieurs solutions de réplication plus ou moins avancées existent avec PostgreSQL : + +* _Streaming Replication_ ou _Physique_ : les données sont transférées immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le réplica. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par réplica sur le maître pour faire tourner le processus _walsender_. En général ce système est couplé à l'envoi des *WAL* car si le réplica est trop en retard par rapport au master, il va lire les *WAL* jusqu'à avoir rattrapé son retard puis basculera tout seul sur la *streaming replication* +* _Logique_ : les données sont répliquées au niveau des objets par un système de publication/abonnement * _PITR_, _Point In Time Recovery_ : copie des logs de transaction (_WAL_) sur un serveur distant pour archivage. Ils peuvent ensuite être rejoués jusqu'à un point précis en cas de perte de données par exemple. * _Warm Standby_ : les _WAL_ sont copiés sous forme d'archive sur un second serveur sur lequel tourne un PostgreSQL en mode _recovery_ constant. Chaque segment reçu est rejoué par PostgreSQL. Il est alors prêt à prendre le relais en cas de panne sur le serveur maître. * _Hot Standby_ : le principe est le même que pour le _Warm Standby_, mais le réplica peut être interrogé en lecture. Il y a néanmois une légère différence perpétuelle entre le master et le réplica car le *WAL* est transféré seulement lorsque l'archive a fini d'être écrite. -* _Streaming Replication_ : les données sont transférées immédiatement par un processus dédié (_walsender_) dans une connexion réseau établie avec le réplica. Contrairement aux autres solutions, cela nécessite une légère charge supplémentaire par réplica sur le maître pour faire tourner le processus _walsender_. En général ce système est couplé à l'envoi des *WAL* car si le réplica est trop en retard par rapport au master, il va lire les *WAL* jusqu'à avoir rattrapé son retard puis basculera tout seul sur la *streaming replication* * _Slony_ : système de réplication basé sur l'ajout de triggers sur chaque table à répliquer. Cela nécessite une gestion assez complexe mais c'était la seule façon d'avoir une réplication immédiate avant l'arrivée de la _Streaming Replication_. Cela reste la seule solution pour avoir une réplication au niveau des tables et non de la base entière (par exemple si vous voulez répliquer une table d'un serveur A vers un serveur B, et répliquer une autre table du serveur B vers A). -Pour plus de détails sur ces solutions, voir ce post sur [dba.stackexange.com](https://dba.stackexchange.com/questions/73812/postgresql-streaming-versus-file-based-replication-in-terms-of-server-behavior). Pour d'autres types de solutions pour avoir de la haute disoponibilite, PostgreSQL a [une page sur cela dans leur documentation](https://www.postgresql.org/docs/current/static/different-replication-solutions.html). +Pour plus de détails sur ces solutions, voir ce post sur [dba.stackexange.com](https://dba.stackexchange.com/questions/73812/postgresql-streaming-versus-file-based-replication-in-terms-of-server-behavior). Pour d'autres types de solutions pour avoir de la haute disponibilité, PostgreSQL a [une page sur cela dans leur documentation](https://www.postgresql.org/docs/current/static/different-replication-solutions.html). > *Note* : l'expédition des logs entre des serveurs pgsql nécessite qu'ils soient à la même version majeure. -### Streaming Replication +### Streaming Réplication -Voir [/HowtoPostgreSQL/Replication](). +Voir [/HowtoPostgreSQL/ReplicationPhysique](). + +### Réplication Logique + +Voir [/HowtoPostgreSQL/ReplicationLogique](). ### Slony diff --git a/HowtoPostgreSQL/ReplicationLogique.md b/HowtoPostgreSQL/ReplicationLogique.md new file mode 100644 index 00000000..8b03cd45 --- /dev/null +++ b/HowtoPostgreSQL/ReplicationLogique.md @@ -0,0 +1,114 @@ +# _Réplication Logique_ avec PostgreSQL + + + +## Mise en place + +Sur le serveur primaire et réplica, on s'assure d'avoir deux bases : + +~~~ +postgres $ createuser -p 5432 -P foo +Enter password for new role: + +postgres $ createdb -p 5432 -O foo foo +~~~ + +Sur le serveur primaire, on modifie la directive `wal_level` : + +~~~ +wal_level = logical +~~~ + +Puis l'on crée un utilisateur `replication` et une publication liée à cette base : + +~~~ +postgres $ createuser -p 5432 -P --replication replication + +postgres $ psql -p 5432 foo + +foo=# GRANT SELECT on ALL TABLES IN SCHEMA public TO replication; +GRANT + +foo=# CREATE PUBLICATION alltables FOR ALL TABLES; +CREATE PUBLICATION +~~~ + +Sur le serveur réplica, on crée une subscription liée à cette base : + +~~~ +postgres $ psql -p 5432 foo + +foo=# CREATE SUBSCRIPTION mysub CONNECTION 'dbname=foo host=192.0.2.1 port=5436 user=replication password=PASSWORD' PUBLICATION alltables; +NOTICE: created replication slot "mysub" on publisher +CREATE SUBSCRIPTION +~~~ + +Attention, contrairement à la réplication physique, rien n'empêche d'écrire sur le serveur réplica. + +Ensuite, il faut créer les tables de façon identique sur les deux bases : + +~~~ +postgres $ psql -U foo -h 127.0.0.1 -p 5432 foo +foo=> CREATE TABLE t (a INT); +~~~ + +Enfin, l'insertion de données sur le serveur primaire, devrait provoquer le transfert de ces données sur le serveur réplica : + +~~~ +LOG: logical replication table synchronization worker for subscription "mysub", table "t" has started +~~~ + +Si besoin, on peut « rafraichir » la subscription sur le serveur replica via la commande : + +~~~ +postgres $ psql -p 5432 foo + +foo=# ALTER SUBSCRIPTION mysub REFRESH PUBLICATION; +~~~ + + +## Administration + +### Ajout / modification d'une table + +Si l'on veut ajouter ou modifier une table, il faut : + +- créer / modifier la table sur les 2 serveurs maître et réplica +- relancer la commande suivante sur le serveur maître : + +~~~ +postgres $ psql -p 5432 foo + +foo=# GRANT SELECT on ALL TABLES IN SCHEMA public TO replication; +GRANT +~~~ + +- relancer la commande suivante sur le serveur réplica : + +~~~ +postgres $ psql -p 5432 foo + +foo=# ALTER SUBSCRIPTION mysub REFRESH PUBLICATION; +~~~ + +On peut ensuite insérer des données sur la nouvelle table qui sera répliquée. + + +## Monitoring + +Sur le serveur replica, on peut surveiller le bon fonctionnement de la réplication ainsi : + +~~~ +postgres=# select * from pg_subscription ; + subdbid | subname | subowner | subenabled | subconninfo | subslotname | subsynccommit | subpublications +---------+---------+----------+------------+----------------------------------------------------------------------------+-------------+---------------+----------------- + 16385 | mysub | 10 | t | dbname=foo host=192.0.2.1 port=5432 user=replication password=PASSWORD | mysub | off | {alltables} +(1 row) + +postgres=# select * from pg_stat_subscription ; + subid | subname | pid | relid | received_lsn | last_msg_send_time | last_msg_receipt_time | latest_end_lsn | latest_end_time +-------+---------+-------+-------+--------------+-------------------------------+-------------------------------+----------------+------------------------------- + 16388 | mysub | 12767 | | 0/16A58D8 | 2019-09-17 21:09:16.512057+00 | 2019-09-17 21:09:16.512241+00 | 0/16A58D8 | 2019-09-17 21:09:16.512057+00 +~~~ + + diff --git a/HowtoPostgreSQL/Replication.md b/HowtoPostgreSQL/ReplicationPhysique.md similarity index 97% rename from HowtoPostgreSQL/Replication.md rename to HowtoPostgreSQL/ReplicationPhysique.md index db938ef5..71122aa9 100644 --- a/HowtoPostgreSQL/Replication.md +++ b/HowtoPostgreSQL/ReplicationPhysique.md @@ -1,6 +1,8 @@ # _Streaming Replication_ avec PostgreSQL -La réplication en flux (_Streaming Replication_) est disponible à partir de la version 9.0 de PostgreSQL. Celle-ci est différente de la réplication logique apparue dans la version 10. + + +La réplication en flux (_Streaming Replication_) est disponible à partir de la version 9.0 de PostgreSQL. Celle-ci est aussi appelée _Réplication Physique_ en opposition à la _Réplication Logique_ apparue dans la version 10. ## Caractéristiques @@ -16,7 +18,7 @@ Par rapport au mode de réplication _Hot Standby_, l'avantage avec la réplicati Pré-requis pour pouvoir mettre en place une infra avec 1 maître et 1 réplicat : -* même architecture (32 bits/64 bits) sur les 2 serveurs ; +* même architecture (32 ou 64 bits) sur les 2 serveurs ; * même version majeure de PostgreSQL sur les 2 serveurs (et même version mineure est conseillé) ; ## Installation de PostgreSQL