PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Partitionnement de réplication logique avec PostgreSQL 13

Chaque version de PostgreSQL s'accompagne de quelques améliorations de fonctionnalités majeures, mais ce qui est tout aussi intéressant, c'est que chaque version améliore également ses fonctionnalités passées.

Puisque la sortie de PostgreSQL 13 est prévue, il est temps de vérifier quelles fonctionnalités et améliorations la communauté nous apporte. L'une de ces améliorations sans bruit est "l'amélioration de la réplication logique pour le partitionnement".

Comprenons cette amélioration de fonctionnalité avec un exemple courant.

Terminologie

Deux termes importants pour comprendre cette fonctionnalité sont :

  • Tables de partition
  • Réplication logique

Tables de partition

Un moyen de diviser une grande table en plusieurs parties physiques pour obtenir des avantages tels que :

  • Amélioration des performances des requêtes
  • Mises à jour plus rapides
  • Charges et suppressions groupées plus rapides
  • Organiser les données rarement utilisées sur des disques lents

Certains de ces avantages sont obtenus par le biais de l'élagage de partition (c'est-à-dire le planificateur de requêtes utilisant la définition de partition pour décider d'analyser ou non une partition) et le fait qu'une partition est plutôt plus facile à tenir dans une mémoire finie par rapport à une immense table.

Une table est partitionnée sur la base de :

  • Liste
  • Hachage
  • Plage

Réplication logique 

Comme son nom l'indique, il s'agit d'une méthode de réplication dans laquelle les données sont répliquées de manière incrémentielle en fonction de leur identité (par exemple, une clé). Ce n'est pas similaire aux méthodes WAL ou de réplication physique où les données sont envoyées octet par octet.

Selon un modèle éditeur-abonné, la source des données doit définir un éditeur tandis que la cible doit être enregistrée en tant qu'abonné. Les cas d'utilisation intéressants pour cela sont :

  • Réplication sélective (seulement une partie de la base de données)
  • Écritures simultanées sur deux instances de base de données où les données sont répliquées
  • Réplication entre différents systèmes d'exploitation (par exemple, Linux et Windows)
  • Sécurité précise de la réplication des données 
  • Déclenche l'exécution lorsque les données arrivent du côté récepteur 

Réplication logique pour les partitions

Avec les avantages de la réplication logique et du partitionnement, il est pratique d'avoir un scénario dans lequel une table partitionnée doit être répliquée sur deux instances PostgreSQL.

Voici les étapes pour établir et mettre en évidence les améliorations apportées à PostgreSQL 13 dans ce contexte.

Configuration

Envisagez une configuration à deux nœuds pour exécuter deux instances différentes contenant une table partitionnée :

Les étapes sur Instance_1 sont comme ci-dessous après la connexion sur 192.168.56.101 en tant qu'utilisateur postgres :

$ initdb -D ${HOME}/pgdata-1

$ echo "listen_addresses = '192.168.56.101'"  >> ${HOME}/pgdata-1/postgresql.conf

$ echo "wal_level = logical"                  >> ${HOME}/pgdata-1/postgresql.conf

$ echo "host postgres all 192.168.56.102/32 md5" >> ${HOME}/pgdata-1/pg_hba.conf

$ pg_ctl -D ${HOME}/pgdata-1 -l logfile start

Le paramètre 'wal_level' est défini spécifiquement sur 'logical' pour indiquer que la réplication logique sera utilisée pour répliquer les données de cette instance. Le fichier de configuration 'pg_hba.conf' a également été modifié pour autoriser les connexions à partir de 192.168.56.102.

# CREATE TABLE stock_sales

( sale_date date not null, unit_sold  int, unit_price int )

  PARTITION BY RANGE ( sale_date );

# CREATE TABLE stock_sales_y2017 PARTITION OF stock_sales

  FOR VALUES FROM ('2017-01-01') TO ('2018-01-01'); 

# CREATE TABLE stock_sales_y2018 PARTITION OF stock_sales

  FOR VALUES FROM ('2018-01-01') TO ('2019-01-01');

# CREATE TABLE stock_sales_default

  PARTITION OF stock_sales DEFAULT;

Bien que le rôle postgres soit créé par défaut sur la base de données Instance_1, un utilisateur distinct doit également être créé avec un accès limité, ce qui restreint la portée uniquement pour une table donnée.

# CREATE ROLE rep_usr WITH REPLICATION LOGIN PASSWORD 'rep_pwd';

# GRANT CONNECT ON DATABASE postgres TO rep_usr;

# GRANT USAGE ON SCHEMA public TO rep_usr;

# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep_usr;

Une configuration presque similaire est requise sur Instance_2

$ initdb -D ${HOME}/pgdata-2

$ echo "listen_addresses = '192.168.56.102'"  >> ${HOME}/pgdata-2/postgresql.conf

$ pg_ctl -D ${HOME}/pgdata-2 -l logfile start

Il convient de noter que puisque l'Instance_2 ne sera pas une source de données pour un autre nœud, les paramètres wal_level ainsi que le fichier pg_hba.conf n'ont pas besoin de paramètres supplémentaires. Inutile de dire que pg_hba.conf peut nécessiter une mise à jour selon les besoins de production.

La réplication logique ne prend pas en charge DDL, nous devons également créer une structure de table sur Instance_2. Créez une table partitionnée en utilisant la création de partition ci-dessus pour créer également la même structure de table sur Instance_2.

Configuration de la réplication logique

La configuration de la réplication logique devient beaucoup plus facile avec PostgreSQL 13. Jusqu'à PostgreSQL 12, la structure était comme ci-dessous :

Avec PostgreSQL 13, la publication des partitions devient beaucoup plus facile. Reportez-vous au schéma ci-dessous et comparez avec le schéma précédent :

Avec des configurations faisant rage avec des centaines et des milliers de tables partitionnées - ce petit changement simplifie les choses dans une large mesure.

Dans PostgreSQL 13, les instructions pour créer une telle publication seront :

CREATE PUBLICATION rep_part_pub FOR TABLE stock_sales 

WITH (publish_via_partition_root);

Le paramètre de configuration publish_via_partition_root est nouveau dans PostgreSQL 13, ce qui permet au nœud destinataire d'avoir une hiérarchie feuille légèrement différente. La simple création de publication sur des tables partitionnées dans PostgreSQL 12 renverra des déclarations d'erreur comme ci-dessous :

ERROR:  "stock_sales" is a partitioned table

DETAIL:  Adding partitioned tables to publications is not supported.

HINT:  You can add the table partitions individually.

En ignorant les limitations de PostgreSQL 12 et en procédant à la mise en pratique de cette fonctionnalité sur PostgreSQL 13, nous devons établir l'abonné sur Instance_2 avec les instructions suivantes :

CREATE SUBSCRIPTION rep_part_sub CONNECTION 'host=192.168.56.101 port=5432 user=rep_usr password=rep_pwd dbname=postgres' PUBLICATION rep_part_pub;

Vérifier si cela fonctionne vraiment

Nous avons pratiquement terminé l'ensemble de la configuration, mais effectuons quelques tests pour voir si tout fonctionne.

Sur l'instance_1, insérez plusieurs lignes en vous assurant qu'elles apparaissent dans plusieurs partitions :

# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2017-09-20', 12, 151);# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2018-07-01', 22, 176);

# INSERT INTO stock_sales (sale_date, unit_sold, unit_price) VALUES ('2016-02-02', 10, 1721);

Vérifier les données sur Instance_2 :

# SELECT * from stock_sales; 

sale_date  | unit_sold | unit_price

------------+-----------+------------

 2017-09-20 |    12 |    151

 2018-07-01 |    22 |    176

 2016-02-02 |    10 |   1721

Vérifions maintenant si la réplication logique fonctionne même si les nœuds feuilles ne sont pas les mêmes côté destinataire.

Ajouter une autre partition sur Instance_1 et insérer un enregistrement :

# CREATE TABLE stock_sales_y2019

      PARTITION OF stock_sales 

     FOR VALUES FROM ('2019-01-01') to ('2020-01-01');

# INSERT INTO stock_sales VALUES(‘2019-06-01’, 73, 174 );

Vérifier les données sur Instance_2 :

# SELECT * from stock_sales;

 sale_date  | unit_sold | unit_price

------------+-----------+------------

 2017-09-20 |    12 |    151

 2018-07-01 |    22 |    176

 2016-02-02 |    10 |   1721

 2019-06-01 |    73 |   174

Autres fonctionnalités de partitionnement dans PostgreSQL 13

Il existe également d'autres améliorations dans PostgreSQL 13 liées au partitionnement, à savoir :

  1. Améliorations de la jointure entre les tables partitionnées
  2. Les tables partitionnées prennent désormais en charge les déclencheurs au niveau de la ligne AVANT

Conclusion

Je vais certainement vérifier les deux fonctionnalités à venir susmentionnées dans ma prochaine série de blogs. Jusque-là matière à réflexion - avec la puissance combinée du partitionnement et de la réplication logique, PostgreSQL se rapproche-t-il d'une configuration maître-maître ?