PostgreSQL 9.4 Multi Master Replication (MMR)
Par Nicolas HAHN le dimanche 9 août 2015, 09:09 - Technologies - Lien permanent
Une fois n'est pas coutume, j'ai envie aujourd'hui de vous parler d'une base de données que j'adore et que j'utilise depuis 1999 (plus de 15 ans déjà!), notamment dans mes propres projets Open Source comme X-Itools ELSE, et aussi pour mes clients en hosting de bases de données. Il s'agit de PostgreSQL, dans sa version 9.4, et on va voir ensemble comment utiliser cette base très professionnelle - souvent comparée à Oracle - dans un contexte MMR, c'est à dire en Multi Master Replication.
Depuis longtemps, PostgreSQL bénéficie d'outils annexes permettant de gérer la réplication entre plusieurs noeuds, comme Slony-I ou encore Bucardo par exemple. Puis des possibilités de réplication ont été intégrées directement au niveau du moteur de la base, toujours plus complètes et performantes. Ces différents systèmes de réplication logique ou physique ont tous leurs avantages et leurs contraintes ou inconvénients.
Ainsi, le fait d'utiliser des outils externes imposant plus de contraintes de gestion pouvait rendre l'administration du système de données plus compliquée. Ces outils pouvaient aussi imposer plus de stress sur la base de données, de par l'utilisation de triggers, impactant le taux d'écriture sur les bases puisque les multipliant par un facteur 4.
Les efforts de développement sur PostgreSQL lui-même ont apporté la réplication maitre-esclave, le Hot-Standby, puis la réplication en cascade, l'inconvénient principal étant qu'à un instant T, un seul membre du système global fonctionne en lecture-écriture, tous les autres, les esclaves, fonctionnant au mieux en lecture seule.
Ce que tous ces différents systèmes ont en commun, c'est qu'ils n'ont jamais apporté de capacités de Multi Master Replication (MMR) performantes, réelles et sérieuses. C'est à dire la possibilité d'écrire et de lire sur tous les noeuds en même temps.
Depuis la branche de version 9.X de PostgreSQL, surtout depuis la version 9.4 d'ailleurs, ceci a changé, sous l'impulsion de la société 2ndQuadrant, dont ses membres sont de forts contributeurs au code source de PostgreSQL. 2ndQuadrant travaille beaucoup sur les projets UDR (Uni-Directionnal Replication) et BDR (Bi-Directionnal Replication). Ces projets sont des extensions de PostgreSQL. Et BDR est l'extension qui nous intéresse ici aujourd'hui car c'est celle qui permet enfin le MMR performant pour PostgreSQL.
Je vous propose de m'accompagner dans la découverte et l'installation d'une infrastructure PostgreSQL MMR, sous la forme d'un petit lab ou POC (Proof Of Concept), dans la suite de cet article.
PostgreSQL 9.4 MMR: architecture du LAB.
Le but du lab est d'installer deux noeuds PostgreSQL 9.4 en MMR sur deux serveurs distincts. Pour cela, si vous êtes un geek fou comme moi, vous aurez surement dans votre bureau, à côté de votre lit cela va sans dire, une pile de serveurs disponibles sur lesquels on va installer tout ce qu'il nous faut, comme montré ci-dessous :-)
Les caractéristiques techniques du lab:
- Tous les serveurs fonctionnent sous Linux CentOS 7 x86_64
- Réseau: 192.168.178.0/24
- Serveur 1: utilisé en tant que station cliente - 16 Go RAM, 8 CPU cores. IP: 192.168.178.21/24
- Serveur 2: 1er noeud PostgreSQL 9.4 BDR - 2 Go RAM, 2 CPU cores. IP: 192.168.178.29/24
- Serveur 3: 2ème noeud PostgreSQL 9.4 BDR - 2 Go RAM, 2 CPU cores. IP: 192.168.178.30/24
Notez que vous pouvez tout à fait réaliser ce lab sur une seule machine physique, avec des machines virtuelles. Dans ce cas, le Serveur 1 est le serveur hôte, et les deux noeuds PostgreSQL sont deux machines virtuelles, par exemple.
Voilà ce que cela donne au niveau architecture type Visio:
Etapes préliminaires à l'installation des serveurs.
Notez que dans le respect d'un principe de clarté, je vais reproduire ta totalité des sorties écran pour chaque commande utilisée, dans les sections de code de mon article. Les commandes à entrer sont en noir pour qu'elles soient mieux visibles dans tout le flot de texte, qui lui est en marron.
Comme on a pas du tout envie d'être embêté par SELinux ou par FirewallD sur CentOS 7 dans le cadre de ce lab, on va déjà commencer par désactiver tout ça. A ne pas faire en PROD bien entendu! Pour ce faire, sur chaque serveur, effectuez les actions suivantes:
Commencez par éditer le fichier /etc/sysconfig/selinux pour qu'il ressemble à celui représenté ci-dessous. La ligne qui nous intéresse est SELINUX=permissive (ou disabled). Une fois ceci fait, rebootez vos serveurs:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# minimum - Modification of targeted policy. Only selected processes are protected.
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
Ensuite pour désactiver FirewallD définitivement, par exemple sur Serveur1:
[root@serveur1 ~]# systemctl stop firewalld
[root@serveur1 ~]# systemctl disable firewalld
Maintenant, nous avons besoin pour l'installation, sur chacun de nos serveurs, de dépôts YUM spécifiques tels que:
- le dépôt EPEL
- le dépôt PostgreSQL officiel
- le dépôt 2ndQuadrant
Voici comment installer ces dépôts:
[root@serveur1 ~]# yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
Modules complémentaires chargés : fastestmirror
epel-release-latest-7.noarch.rpm | 14 kB 00:00:00
Examen de /var/tmp/yum-root-P5ogTu/epel-release-latest-7.noarch.rpm : epel-release-7-5.noarch
Sélection de /var/tmp/yum-root-P5ogTu/epel-release-latest-7.noarch.rpm pour installation
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet epel-release.noarch 0:7-5 sera installé
--> Résolution des dépendances terminée
Dépendances résolues
======================================================================================================================
Package Architecture Version Dépôt Taille
======================================================================================================================
Installation :
epel-release noarch 7-5 /epel-release-latest-7.noarch 24 k
Résumé de la transaction
======================================================================================================================
Installation 1 Paquet
Taille totale : 24 k
Taille d'installation : 24 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installation : epel-release-7-5.noarch 1/1
Vérification : epel-release-7-5.noarch 1/1
Installé :
epel-release.noarch 0:7-5
Terminé !
[root@serveur1 ~]# yum -y install http://yum.postgresql.org/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-1.noarch.rpm
Modules complémentaires chargés : fastestmirror
pgdg-centos94-9.4-1.noarch.rpm | 5.2 kB 00:00:00
Examen de /var/tmp/yum-root-P5ogTu/pgdg-centos94-9.4-1.noarch.rpm : pgdg-centos94-9.4-1.noarch
Sélection de /var/tmp/yum-root-P5ogTu/pgdg-centos94-9.4-1.noarch.rpm pour installation
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet pgdg-centos94.noarch 0:9.4-1 sera installé
--> Résolution des dépendances terminée
Dépendances résolues
======================================================================================================================
Package Architecture Version Dépôt Taille
======================================================================================================================
Installation :
pgdg-centos94 noarch 9.4-1 /pgdg-centos94-9.4-1.noarch 2.1 k
Résumé de la transaction
======================================================================================================================
Installation 1 Paquet
Taille totale : 2.1 k
Taille d'installation : 2.1 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installation : pgdg-centos94-9.4-1.noarch 1/1
Vérification : pgdg-centos94-9.4-1.noarch 1/1
Installé :
pgdg-centos94.noarch 0:9.4-1
Terminé !
[root@serveur1 ~]# yum -y install http://packages.2ndquadrant.com/postgresql-bdr94-2ndquadrant/yum-repo-rpms/postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch.rpm
Modules complémentaires chargés : fastestmirror
postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch.rpm | 4.5 kB 00:00:00
Examen de /var/tmp/yum-root-P5ogTu/postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch.rpm : postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch
Sélection de /var/tmp/yum-root-P5ogTu/postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch.rpm pour installation
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet postgresql-bdr94-2ndquadrant-redhat.noarch 0:1.0-2 sera installé
--> Résolution des dépendances terminée
Dépendances résolues
======================================================================================================================
Package Architecture
Version Dépôt Taille
======================================================================================================================
Installation :
postgresql-bdr94-2ndquadrant-redhat noarch 1.0-2 /postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch 2.2 k
Résumé de la transaction
======================================================================================================================
Installation 1 Paquet
Taille totale : 2.2 k
Taille d'installation : 2.2 k
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installation : postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch 1/1
Vérification : postgresql-bdr94-2ndquadrant-redhat-1.0-2.noarch 1/1
Installé :
postgresql-bdr94-2ndquadrant-redhat.noarch 0:1.0-2
Terminé !
[root@serveur1 ~]#
Installation des deux noeuds PostgreSQL
Maintenant que nos dépôts sont configurés sur nos serveurs, nous allons pouvoir installer les packages RPM de PostgreSQL 9.4, ceux spécifiquement conçus par 2ndquadrant et qui contiennent l'extension BDR.
Pour cela, sur Serveur2 et Serveur3, effectuez les étapes suivantes:
[root@serveur2 ~]# yum check-update
Modules complémentaires chargés : fastestmirror
epel/x86_64/metalink | 23 kB 00:00:00
epel | 4.4 kB 00:00:00
pgdg94 | 3.6 kB 00:00:00
postgresql-bdr94-2ndquadrant-redhat | 3.0 kB 00:00:00
(1/5): postgresql-bdr94-2ndquadrant-redhat/7/x86_64/primary_db | 40 kB 00:00:00
(2/5): epel/x86_64/group_gz | 169 kB 00:00:00
(3/5): pgdg94/7/x86_64/group_gz | 331 B 00:00:00
(4/5): pgdg94/7/x86_64/primary_db | 155 kB 00:00:01
(5/5): epel/x86_64/primary_db | 3.7 MB 00:00:01
(1/2): epel/x86_64/updateinfo | 454 kB 00:00:00
(2/2): epel/x86_64/pkgtags | 1.6 MB 00:00:00
Loading mirror speeds from cached hostfile
* base: mirror.dclux.com
* epel: ftp.nluug.nl
* extras: mirror.dclux.com
* updates: mirror.dclux.com
[root@serveur2 ~]# yum -y install postgresql-bdr94-bdr
Modules complémentaires chargés : fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.dclux.com
* epel: mirror.nl.leaseweb.net
* extras: mirror.dclux.com
* updates: mirror.dclux.com
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet postgresql-bdr94-bdr.x86_64 0:0.9.2-1_2ndQuadrant.el7.centos sera installé
--> Traitement de la dépendance : postgresql-bdr94(x86-64) >= 9.4.4_bdr1 pour le paquet : postgresql-bdr94-bdr-0.9.2-1_2ndQuadrant.el7.centos.x86_64
--> Traitement de la dépendance : postgresql-bdr94-contrib(x86-64) >= 9.4.4_bdr1 pour le paquet : postgresql-bdr94-bdr-0.9.2-1_2ndQuadrant.el7.centos.x86_64
--> Traitement de la dépendance : postgresql-bdr94-server(x86-64) >= 9.4.4_bdr1 pour le paquet : postgresql-bdr94-bdr-0.9.2-1_2ndQuadrant.el7.centos.x86_64
--> Traitement de la dépendance : libpq.so.5()(64bit) pour le paquet : postgresql-bdr94-bdr-0.9.2-1_2ndQuadrant.el7.centos.x86_64
--> Lancement de la transaction de test
---> Le paquet postgresql-bdr94.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos sera installé
---> Le paquet postgresql-bdr94-contrib.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos sera installé
--> Traitement de la dépendance : libxslt.so.1(LIBXML2_1.0.11)(64bit) pour le paquet : postgresql-bdr94-contrib-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64
--> Traitement de la dépendance : libxslt.so.1(LIBXML2_1.0.18)(64bit) pour le paquet : postgresql-bdr94-contrib-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64
--> Traitement de la dépendance : libxslt.so.1(LIBXML2_1.0.22)(64bit) pour le paquet : postgresql-bdr94-contrib-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64
--> Traitement de la dépendance : libxslt.so.1()(64bit) pour le paquet : postgresql-bdr94-contrib-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64
---> Le paquet postgresql-bdr94-libs.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos sera installé
---> Le paquet postgresql-bdr94-server.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos sera installé
--> Lancement de la transaction de test
---> Le paquet libxslt.x86_64 0:1.1.28-5.el7 sera installé
--> Résolution des dépendances terminée
Dépendances résolues
======================================================================================================================
Package Architecture
Version Dépôt Taille
======================================================================================================================
Installation :
postgresql-bdr94-bdr x86_64 0.9.2-1_2ndQuadrant.el7.centos postgresql-bdr94-2ndquadrant-redhat 255 k
Installation pour dépendances :
libxslt x86_64 1.1.28-5.el7 base 242 k
postgresql-bdr94 x86_64 9.4.4_bdr1-1_2ndQuadrant.el7.centos postgresql-bdr94-2ndquadrant-redhat 1.0 M
postgresql-bdr94-contrib x86_64 9.4.4_bdr1-1_2ndQuadrant.el7.centos postgresql-bdr94-2ndquadrant-redhat 607 k
postgresql-bdr94-libs x86_64 9.4.4_bdr1-1_2ndQuadrant.el7.centos postgresql-bdr94-2ndquadrant-redhat 204 k
postgresql-bdr94-server x86_64 9.4.4_bdr1-1_2ndQuadrant.el7.centos postgresql-bdr94-2ndquadrant-redhat 4.0 M
Résumé de la transaction
======================================================================================================================
Installation 1 Paquet (+5 Paquets en dépendance)
Taille totale des téléchargements : 6.3 M
Taille d'installation : 27 M
Downloading packages:
(1/6): postgresql-bdr94-bdr-0.9.2-1_2ndQuadrant.el7.centos.x86_64.rpm | 255 kB 00:00:00
(2/6): postgresql-bdr94-contrib-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64.rpm | 607 kB 00:00:00
(3/6): postgresql-bdr94-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64.rpm | 1.0 MB 00:00:00
(4/6): postgresql-bdr94-libs-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64.rpm | 204 kB 00:00:00
(5/6): postgresql-bdr94-server-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64.rpm | 4.0 MB 00:00:01
(6/6): libxslt-1.1.28-5.el7.x86_64.rpm | 242 kB 00:00:05
----------------------------------------------------------------------------------------------------------------------
Total 1.2 MB/s | 6.3 MB 00:00:05
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installation : postgresql-bdr94-libs-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 1/6
Installation : postgresql-bdr94-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 2/6
Installation : postgresql-bdr94-server-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 3/6
Installation : libxslt-1.1.28-5.el7.x86_64 4/6
Installation : postgresql-bdr94-contrib-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 5/6
Installation : postgresql-bdr94-bdr-0.9.2-1_2ndQuadrant.el7.centos.x86_64 6/6
Vérification : postgresql-bdr94-bdr-0.9.2-1_2ndQuadrant.el7.centos.x86_64 1/6
Vérification : postgresql-bdr94-server-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 2/6
Vérification : postgresql-bdr94-contrib-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 3/6
Vérification : libxslt-1.1.28-5.el7.x86_64 4/6
Vérification : postgresql-bdr94-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 5/6
Vérification : postgresql-bdr94-libs-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 6/6
Installé :
postgresql-bdr94-bdr.x86_64 0:0.9.2-1_2ndQuadrant.el7.centos
Dépendances installées :
libxslt.x86_64 0:1.1.28-5.el7
postgresql-bdr94.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos
postgresql-bdr94-contrib.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos
postgresql-bdr94-libs.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos
postgresql-bdr94-server.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos
Terminé !
[root@serveur2 ~]#
Installation de notre client
Nous allons utiliser le Serveur1 en tant que client. Nous considérons que celui-ci a été installé avec l'intreface graphique KDE au préalable. On va donc installer sur ce dernier, uniquement le client PSQL ainsi que l'interface d'administration graphique pour PostgreSQL: PGAdmin3.
Entrez les commandes suivantes sur Serveur1:
[root@serveur1 ~]# yum -y install postgresql-bdr94 pgadmin3_94
Modules complémentaires chargés : fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: mirror.dclux.com
* epel: ftp.nluug.nl
* extras: mirror.dclux.com
* updates: mirror.dclux.com
Résolution des dépendances
--> Lancement de la transaction de test
---> Le paquet pgadmin3_94.x86_64 0:1.20.0-3.rhel7 sera installé
--> Traitement de la dépendance : wxGTK pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_xrc-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_stc-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_html-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_core-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_aui-2.8.so.0(WXU_2.8.5)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_aui-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_adv-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_baseu_xml-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_baseu_net-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_baseu-2.8.so.0(WXU_2.8.5)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_baseu-2.8.so.0(WXU_2.8)(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_xrc-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_stc-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_html-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_core-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_aui-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_gtk2u_adv-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_baseu_xml-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_baseu_net-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libwx_baseu-2.8.so.0()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
--> Traitement de la dépendance : libpq.so.5()(64bit) pour le paquet : pgadmin3_94-1.20.0-3.rhel7.x86_64
---> Le paquet postgresql-bdr94.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos sera installé
--> Lancement de la transaction de test
---> Le paquet postgresql-bdr94-libs.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos sera installé
---> Le paquet wxBase.x86_64 0:2.8.12-13.el7 sera installé
---> Le paquet wxGTK.x86_64 0:2.8.12-13.el7 sera installé
--> Résolution des dépendances terminée
Dépendances résolues
======================================================================================================================
Package Architecture
Version Dépôt Taille
======================================================================================================================
Installation :
pgadmin3_94 x86_64 1.20.0-3.rhel7 pgdg94 3.2 M
postgresql-bdr94 x86_64 9.4.4_bdr1-1_2ndQuadrant.el7.centos postgresql-bdr94-2ndquadrant-redhat 1.0 M
Installation pour dépendances :
postgresql-bdr94-libs x86_64 9.4.4_bdr1-1_2ndQuadrant.el7.centos postgresql-bdr94-2ndquadrant-redhat 204 k
wxBase x86_64 2.8.12-13.el7 epel 587 k
wxGTK x86_64 2.8.12-13.el7 epel 3.0 M
Résumé de la transaction
======================================================================================================================
Installation 2 Paquets (+3 Paquets en dépendance)
Taille totale des téléchargements : 8.0 M
Taille d'installation : 33 M
Downloading packages:
(1/5): postgresql-bdr94-libs-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64.rpm | 204 kB 00:00:00
(2/5): postgresql-bdr94-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64.rpm | 1.0 MB 00:00:00
(3/5): wxBase-2.8.12-13.el7.x86_64.rpm | 587 kB 00:00:00
(4/5): wxGTK-2.8.12-13.el7.x86_64.rpm | 3.0 MB 00:00:00
(5/5): pgadmin3_94-1.20.0-3.rhel7.x86_64.rpm | 3.2 MB 00:00:03
----------------------------------------------------------------------------------------------------------------------
Total 2.2 MB/s | 8.0 MB 00:00:03
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installation : postgresql-bdr94-libs-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 1/5
Installation : wxBase-2.8.12-13.el7.x86_64 2/5
Installation : wxGTK-2.8.12-13.el7.x86_64 3/5
Installation : pgadmin3_94-1.20.0-3.rhel7.x86_64 4/5
Installation : postgresql-bdr94-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 5/5
Vérification : wxBase-2.8.12-13.el7.x86_64 1/5
Vérification : postgresql-bdr94-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 2/5
Vérification : wxGTK-2.8.12-13.el7.x86_64 3/5
Vérification : pgadmin3_94-1.20.0-3.rhel7.x86_64 4/5
Vérification : postgresql-bdr94-libs-9.4.4_bdr1-1_2ndQuadrant.el7.centos.x86_64 5/5
Installé :
pgadmin3_94.x86_64 0:1.20.0-3.rhel7 postgresql-bdr94.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos
Dépendances installées :
postgresql-bdr94-libs.x86_64 0:9.4.4_bdr1-1_2ndQuadrant.el7.centos wxBase.x86_64 0:2.8.12-13.el7
wxGTK.x86_64 0:2.8.12-13.el7
Terminé !
[root@serveur1 ~]#
Initialisation des deux noeuds PostgreSQL
Tout est installé, on va donc pouvoir commencer la configuration de notre architecture PostgreSQL MMR. Pour pouvoir commencer à mettre à jour les fichiers de configuration de PostgreSQL, il faut d'abord initialiser PostgreSQL sur chaque noeud, ce qui aura pour effet de créer l'arborescence de fichiers de base, ainsi que les fichiers de configuration par défaut.
Sur Serveur2 et Serveur3, veuillez entrer la commande suivante:
[root@serveur2 ~]# /usr/pgsql-9.4/bin/postgresql94-setup initdb
Initializing database ... OK
[root@serveur2 ~]#
Configuration des deux noeuds pour fonctionnement avec BDR MMR
Même si on installe les packages 2ndQuadrant de PostgreSQL pour bénéficier du MMR en lieu et place des packages PostgreSQL officiels, PostgreSQL ne fonctionnera pas par défaut avec les capacités MMR, mais comme si il était une version de PostgreSQL "normale", sans support MMR.
Pour pouvoir activer l'extension MMR, il va nous falloir mettre à jour deux fichiers de configuration qui sont pg_hba.conf et postgresql.conf.
Pour cela, on va se connecter en tant que l'utilisateur postgres:
[root@Serveur2 ~]# su - postgres
-bash-4.2$ ls
9.4-bdr
-bash-4.2$ cd 9.4-bdr/
-bash-4.2$ ls
backups data initdb.log
-bash-4.2$ cd data
-bash-4.2$ ls
base pg_committs pg_ident.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf
global pg_dynshmem pg_log pg_notify pg_snapshots pg_subtrans PG_VERSION postgresql.conf
pg_clog pg_hba.conf pg_logical pg_replslot pg_stat pg_tblspc pg_xlog
-bash-4.2$
Ensutie on va utiliser notre éditeur vi adoré pour modifier le fichier pg_hba.conf comme représenté ci-dessous. Seule la fin de ce fichier est montrée ci-dessous, le début ne contenant que des commentaires:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
#host all all 127.0.0.1/32 ident
host all all 127.0.0.1/32 md5
host all postgres 192.168.178.0/24 trust
host all all 192.168.178.0/24 md5
# IPv6 local connections:
host all all ::1/128 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local replication postgres peer
#host replication postgres 127.0.0.1/32 ident
#host replication postgres ::1/128 ident
# BDR replication
local replication postgres trust
host replication postgres 127.0.0.1/32 trust
host replication postgres ::1/128 trust
host replication postgres 192.168.178.0/24 trust
Dans le fichier ci-dessus, une ligne en particulier est assez importante, c'est celle-ci:
host all postgres 192.168.178.0/24 trust
En effet, dans la documentation de BDR sur le site web de 2ndQuadrant, ils réalisent une installation de deux noeuds PostgreSQL mais sur le même serveur, c'est à dire qu'il y a deux instances de PostgreSQL qui tournent chacune sur un numéro de port différent. Nous sommes dans un cadre plus proche de "la réalité", dans le sens où nos deux instances tournent chacune sur un serveur dédié. Dans ce cas, il nous faut explicitement indiquer que toute connection à PostgreSQL qui serait faite à partir d'une machine dans notre réseau 192.168.178.0/24 en tant qu'utilisateur postgres (le super-admin de la base) est acceptée de fait. Si ceci n'était pas configuré, alors il serait impossible d'ajouter nos noeuds au moteur BDR: il nous serait impossible de les ajouter à une configuration en réplication multi-master. Nous aurions des erreurs relatives, par exemple, à une demande de mot de passe pour se connecter lors de l'ajout de chaque noeud à notre "cluster" SQL (à ne pas confondre avec le sens donné au terme Cluster dans la sémantique officielle PostgreSQL), parce que les méthodes SQL BDR utilisées pour configurer nos noeuds en MMR ne supportent pas l'indication d'un utilisateur et d'un mot de passe, mais seulement un nom d'hôte (ou adresse IP), un numéro de port, et un nom de base de données.
Pour ce qui concerne le fichier postgresql.conf, veillez à modifier ou insérer les paramètres ci-dessous. Vous pouvez vous reporter au Quick Start Guide de BDR pour vérifier ces paramètres, et j'y ai ajouté des paramètres dont nous avons aussi besoin, notamment pour que PostgreSQL écoute sur le réseau et sur le port 5432:
listen_addresses = '*' # what IP address(es) to listen on;
port = 5432
shared_buffers = 256MB # min 128kB
enable_seqscan = off
log_line_prefix = '%m: ' # special values:
shared_preload_libraries = 'bdr'
wal_level = 'logical'
track_commit_timestamp = on
max_connections = 200
max_wal_senders = 10
max_replication_slots = 10
# Make sure there are enough background worker slots for BDR to run
max_worker_processes = 10
# These aren't required, but are useful for diagnosing problems
#log_error_verbosity = verbose
#log_min_messages = debug1
#log_line_prefix = 'd=%d p=%p a=%a%q '
# Useful options for playing with conflicts
bdr.default_apply_delay=2000 # milliseconds
bdr.log_conflicts_to_table=on
Mise en route de nos noeuds et création d'une base de données en MMR
Mise en route
Maintenant que nous avons tout configuré au niveau "système", nous allons pouvoir mettre en route nos deux noeuds PostgreSQL et configurer une base de données en MMR.
Ayez bien présent à l'esprit qu'à tout moment, vous pouvez (et devez) jeter un oeil au fichier de log de vos instances PostgreSQL qui se situent par défaut dans ~/9.4-bdr/data/pg_log/
Pour démarrer PostgreSQL sur Serveur2 et Serveur3:
[root@serveur2 ~]# systemctl start postgresql-9.4
[root@serveur2 ~]#
Pour vérifier que la base de données est bien démarrée, vérifiez en particulier que bgworker: bdr supervisor est bien là:
[root@serveur2 ~]# ps auxwww | grep postgres
postgres 24997 0.5 2.6 491964 26528 ? S 13:12 0:00 /usr/pgsql-9.4/bin/postgres -D /var/lib/pgsql/9.4-bdr/data
postgres 24998 0.0 0.1 201816 1460 ? Ss 13:12 0:00 postgres: logger process
postgres 25000 0.0 0.4 492232 4432 ? Ss 13:12 0:00 postgres: checkpointer process
postgres 25001 0.0 0.1 492096 1824 ? Ss 13:12 0:00 postgres: writer process
postgres 25002 0.0 0.1 492096 1576 ? Ss 13:12 0:00 postgres: wal writer process
postgres 25003 0.0 0.2 492516 2700 ? Ss 13:12 0:00 postgres: autovacuum launcher process
postgres 25004 0.0 0.1 204040 1840 ? Ss 13:12 0:00 postgres: stats collector process
postgres 25007 0.0 0.4 493796 4296 ? Ss 13:12 0:00 postgres: bgworker: bdr supervisor
root 25009 0.0 0.0 112660 968 pts/0 S+ 13:12 0:00 grep --color=auto postgres
Création d'une base de données de test
Nous allons maintenant créer une base de données de test, appelée bdrdemo (comme dans la documentation 2ndQuadrant officielle). L'opération de création de la base doit être réalisée sur les deux noeuds, donc sur Serveur2 et Serveur3, en tant qu'utilisateur postgres, veuillez entrer la commande ci-dessous:
-bash-4.2$ createdb bdrdemo
-bash-4.2$
Configuration de la base sur chaque noeud pour le MMR
Il nous faut activer les extensions BDR pour notre base de données bdrdemo sur chaque noeud. Nous allons utiliser sur Serveur2 et sur Serveur3 le client SQL en ligne de commande: psql
Donc à faire sur Serveur2 et sur Serveur3:
-bash-4.2$ psql bdrdemo
psql (9.4.4)
Saisissez « help » pour l'aide.
bdrdemo=# CREATE EXTENSION btree_gist;
CREATE EXTENSION
bdrdemo=# CREATE EXTENSION bdr;
CREATE EXTENSION
bdrdemo=#
Maintenant, nous devons configurer Serveur2 pour lui indiquer que notre base bdrdemo est un membre avec MMR de notre cluster. Donc, à faire uniquement sur Serveur2:
bdrdemo=# SELECT bdr.bdr_group_create(local_node_name := 'node1', node_external_dsn := 'host=192.168.178.29 port=5432 dbname=bdrdemo');
bdr_group_create
------------------
(1 row)
bdrdemo=# SELECT bdr.bdr_node_join_wait_for_ready();
bdr_node_join_wait_for_ready
------------------------------
(1 row)
bdrdemo=#
Et enfin, on ajoute Serveur3 en tant que membre MMR pour la base de données bdrdemo. Donc, à faire uniquement sur Serveur3:
bdrdemo=# SELECT bdr.bdr_group_join(local_node_name := 'node2', node_external_dsn := 'host=192.168.178.30 port=5432 dbname=bdrdemo', join_using_dsn := 'host=192.168.178.29 port=5432 dbname=bdrdemo');
bdr_group_join
----------------
(1 row)
bdrdemo=# SELECT bdr.bdr_node_join_wait_for_ready();
bdr_node_join_wait_for_ready
------------------------------
(1 row)
bdrdemo=#
Maintenant, sur n'importe quel noeud de notre cluster, nous devrions pouvoir vérifier le status de chaque noeud en allant fouiller dans les tables de gestion BDR, par exemple comme ci-dessous, où l'on constate bien que les deux noeuds ont un status Ready (la colonne node_status contient r):
bdrdemo=# select * from bdr.bdr_nodes;
node_sysid | node_timeline | node_dboid | node_status | node_name | node_local_dsn | node_init_from_dsn
---------------------+---------------+------------+-------------+-----------+----------------------------------------------+----------------------------------------------
6180981339662698762 | 1 | 16385 | r | node1 | host=192.168.178.29 port=5432 dbname=bdrdemo |
6180981332572710593 | 1 | 16385 | r | node2 | host=192.168.178.30 port=5432 dbname=bdrdemo | host=192.168.178.29 port=5432 dbname=bdrdemo
(2 rows)
bdrdemo=#
Test de nos deux noeuds PostgreSQL MMR
On peut donc commencer à créer nos tables et à les remplir de données.
Par exemple sur Serveur2:
bdrdemo=# BEGIN;
BEGIN
bdrdemo=# SET LOCAL default_sequenceam = 'bdr';
SET
bdrdemo=# CREATE TABLE users(uid serial primary key, firstname varchar(128) not null, lastname varchar(128) not null);
CREATE TABLE
bdrdemo=# COMMIT;
COMMIT
bdrdemo=# INSERT INTO users (firstname, lastname) values ('Captain', 'America');
INSERT 0 1
bdrdemo=#
Qu'est ce que l'on vient de faire ci-dessus?
- Tout d'abord, on a démarré une transaction
- dans laquelle on spécifie que les séquences seront basées sur le moteur bdr
- Cela signifie que à chaque fois que l'on utilisera un SMALLSERIAL, SERIAL ou BIGSERIAL quelque part (et dans le cadre de notre transaction), on utilisera pas les séquences standards de PostgreSQL, mais les séquences globales de l'extension BDR. Ces séquences, comme leur nom l'indique, sont globales à tous les noeuds membres du groupe MMR. Autrement dit, cela nous donne la garantie que, quelque soit le noeud sur lequel des données seront écrites dans une table ayant pour clé primaire une séquence, le numéro de séquence sera absolument unique. C'est un moyen puissant d'éviter que des noeuds différents insèrent des données conflictuelles dans une même table.
- On crée justement notre table "users" avec un SERIAL (séquence globale donc) qui plus est PRIMARY KEY
- et on valide la transaction avec un COMMIT
- Puis on insère une première ligne de données dans notre table
Maintenant, si l'on regarde ce que cela donne sur le Serveur3, on peut déjà confirmer que notre table "users" est bien existante:
bdrdemo=# \dt
List of relations
Schema | Name | Type | Owner
--------+-------+-------+----------
public | users | table | postgres
(1 row)
bdrdemo=#
Puis on peut vérifier que notre ligne de données insérée par le Serveur2 est bien là sur le Serveur3:
bdrdemo=# select * from users;
uid | firstname | lastname
------+-----------+----------
5001 | Captain | America
(1 row)
bdrdemo=#
En passant, vous pourrez constater que le tout premier numéro de notre séquence globale est à 5001. Cela permet de constater qu'en réalité, BDR alloue des tranches de nombres à chaque noeud en MMR. Une fois une tranche consommée sur un noeud, une autre tranche est allouée et ainsi de suite.
Maintenant, insérons d'autres lignes de données dans notre table cette fois-ci sur le Serveur3:
bdrdemo=# insert into users (firstname, lastname) values ('Loïs', 'Lane'),('Clark', 'Kent'),('Elon','Musk');
INSERT 0 3
bdrdemo=#
Et constatons qu'elles ont bien été répliquées sur notre Serveur2:
bdrdemo=# select * from users;
uid | firstname | lastname
------+-----------+----------
5001 | Captain | America
2 | Loïs | Lane
3 | Clark | Kent
4 | Elon | Musk
(4 rows)
bdrdemo=#
Ce qui une fois de plus nous confirme que le Serveur3 est en train d'utiliser une tranche de numéros de séquence qui va de 1 à 5000, et de 5001 à 10000 pour le Serveur2.
Pour conclure
- Avec BDR, on dispose d'une réplication MMR très performante au sein même de PostgreSQL, bien plus performante que toutes les solutions "externes" utilisées jusque là
- BDR permet le MMR entre 48 noeuds PostgreSQL maximum (pour le moment), c'est déjà très confortable, par exemple dans le cadre d'une base de données dont les noeuds seraient répartis un peu partout sur la planète
- BDR étant intégré au moteur PostgreSQL, il n'y a pas besoin de démon annexe: c'est plus simple
- Les séquences globales étant par conséquent elles aussi intégrées au coeur de PostgreSQL, on a vraiment la garantie que les numéros générés sont uniques, quel que soit le noeud PostgreSQL considéré. En tout état de cause, cela permettra d'éliminer fortement, pour ne pas dire entièrement, les problèmes de conflits entre les noeuds.
- PostgreSQL 9.4 BDR, c'est le commencement. PostgreSQL 9.5 permettra une intégration de BDR encore plus simple et plus optimisée. A terme, il n'y aura plus besoin de produire des packages PostgreSQL "maison" comme le fait 2ndQuadrant. Les packages officiels suffiront pour bénéficier du MMR.
- MySQL? C'est quoi ça??? Arrêtez avec MySQL! :-D
Commentaires
article intéressant et très instructif