AlexandreVaquembergue < Stages

Tags: , view all tags

Stage d'Alexandre Van Waquembergue - DUT Charlemagne - [10/04/17 au 16/06/17]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter Gilles, Anais

Anais : anais.oberto@astro.unistra.fr (Batiment Sud, tél : 52493)

Stage d'Alexandre Van Waquembergue - DUT Charlemagne - [10/04/17 au 16/06/17]
Note Bucardo
Greenplum
Tableau comparatif bucardo/Replication intégré de postgresql
Stage d'Alexandre Van Waquembergue - DUT Charlemagne - [10/04/17 au 16/06/17]
Travail post stage éventuel
- - Liste des améliorations à envisager
  - Bugs connus
- Documentation
Travail post stage éventuel
- - Liste des améliorations à envisager
  - Bugs connus

Sujet

Proposition de stage

(voir les options disponibles à partir de la version 9.6 de PostgreSQL : https://wiki.postgresql.org/wiki/Apt)

Stage (Avril - juin 2017)

Points à explorer pour éviter des "locks" : https://www.postgresql.org/docs/9.6/static/view-pg-locks.html

(Simbad : transaction en mode Read Committed)

- replication (config) master-master (slonny/pgLogical)

- parallélisation

- load-balancing

- amélioration de la gestion du cache

- désynchronisation de l'administration sur une copie (pendant un réindex)

- Volumétrie

- Pool de connections : PgBouncer/PgPool

Indexations : (voir l'utilisation des colonnes et des index en place dans la table pg_stats)

- tester les index GIN / BRIN / GEQO

Remanipulation des schemas (si le temps le permet à la fin) :

- Simbad : faire un programme pour créer une gigantesque vue (ou copie) et comparer la vitesse

- Vizier : refaire l'organisation des schémas viz1-viz2-viz3 en J-AJ-ApJ ...

Avril

10, arrivée
10, présentation des métiers et services
10 -14 prise en main de Postgres + lecture des docs sur les problématiques du stage
17 -26 tester les différentes solutions sur les locks (principalement replication)
30 : fin de test de replications et mettre en place pour de la production

Mai

1-15 Autres problématiques à explorer (pool / load balancing)
15-30 : index et parallélisation, administration non blocante

Juin

Nouveaux schémas à refaire

Liens

Versions de Simbad à télécharger pour l'installer dans postgres

(format compressé à installer avec pg_restore)

http://simbad.u-strasbg.fr/Files/simdump

Logs d'utilisations :

(attention les

Note Bucardo

Installation

Voici les étapes que j'ai effectué pour installer bucardo:

Télécharger le fichier compresser sur le site officiel
Décompresser le fichier
Installer le language postgresql-plperl => apt-get install postgresql-plperl-9.6
Ensuite installé le module boolean => apt-get install libboolean-perl => sudo cpan boolean
Créer le dossier bucardo dans /var/log , et dans ce dossier (/var/log/bucardo) créer un fichier appelé log.bucardo (c'est ici que seront stocker les fichiers de log)
Enfin dans le fichier décompressé => perl Makefile.PL => make => sudo make install

Maintenant que bucardo est installé, voici la marche a suivre pour installer des bases sur bucardo (la création de la base est incluse ici mais il est parfaitement possible de partir d'une base déjà existante)

En premier lieu il faut créer un utilisateur bucardo avec les droits de superuser, c'est l'utilisateur que va utiliser bucardo pour ces opérations
createdb <nom de la db>
Dans le cadre des tests en Master-Slave j'ai remplie mes bases avec un bench => pgbench -i <nom de la base>. Car il est a noté qu'il faut avant de synchronisé que les bases possèdent toutes les tables que l'on souhaite synchronisé, il faut donc dans le cadre d'une mise en prodution faire un dump des tables que l'on souhaite synchronisé pour les exporté vers les différents slave
Puis pour toutes les bases que l'on veut synchronisé => bucardo add db <nom de la db> dbname="<nomdeladb>" host="localhost" port="5432" user="bucardo" pass="bucardo"
-Ajouter les tables de la bases a bucardo => bucardo add all tables db=<nom de la db> (-T pgbench_history)<optionnel> --herd=alpha --verbose
(Note: le -T pgbench_history signifie que la table pgbench_history n'est pas copié, ici cela est fait car elle ne possède pas de clé primaire, de plus alpha est le nom donner au "groupe" de table à synchronisé
On peut aussi ajouter les table une par une avec => bucardo add table <nom_table> db=<nom_db> , puis créer le herd et ajouter les tables dedans => bucardo add herd <nom_herd> <list_tables>
Au final il fait ajouter les tables à bucardo et lui dire qui est le(s) slave(s) et qui est le(s) master(s) => bucardo add sync <nom de la sync> herd=alpha dbs=<db1>:source(master),<db2>:target(slave) ;

Les deux bases sont maintenant synchronisés sur les tables du groupe alpha.

Information complémentaire

Pour modifié les paramètres d'un objet de bucardo (herd,dbgroup,database,table....) il faut utiliser la commande bucardo update [type objet] [nom objet] paramètre=valeur

Pour savoir quelles paramètres on peut modifié et avoir des information dessus => bucardo list [type objet] [nom objet] -vv

Pour avoir toutes les informations, base,table,synchro... que contient bucardo, allez sur la base du système bucardo que vous avez créer pendant l'installation.

Les log de bucardo se situe à /var/log/bucardo.log

Test

Master-Slave

Ici test1 est le master et test2 est le slave

(Note: l'installation faite précédement est une replication master-slave, le master-master est expliqué juste après)

Update sur test1 : la modification est bien repliqué sur test2
Update sur test2 : la requête fonctionne mais celle-ci n'est pas répliqué sur test1
Update même ligne que précédement mais sur le master et avec des valeurs différentes : la replication s'effectue correctement, la modification effectué sur le slave est écrasé par celle faite sur le master
Création d'un index sur le master: l'index ne se replique pas sur le slave
Insertion de donnée sur le master, avec index: la replication est normal
Création d'un cluster sur le master: le cluster ne se replique pas sur le slave
Insertion et update sur le master, avec le cluster: la replication s'effectue normalement
Modification d'une table, ajout d'une colonne sur le master: la modification n'est pas repliqué sur le slave
Insertion dans le master avec une valeur dans cette nouvelle colonne: la replication ne fonctionne pas
Insertion dans le master sans valeur dans la nouvelle colonne: la replication ne fonctionne pas ici non plus
Ajout de la colonne "manquante" au slave et insert sur le master : la ligne n'a pas été ajouté
Suppression dans les deux tables de la colonne et insertion sur le master: la replication s'est effectuer correctement, de plus le slave a repris sont retard sur le master, c'est à dire qu'il a copier les lignes ajouter pendant la phase avec la "nouvelle colonne"
Pose d'un lock acces exclusif sur le master: le master est bloquer mais le slave lui ne l'ai pas
Ajout d'une colonne dans le slave et pas dans le master puis insertion d'une ligne dans le master: la replication se fait normalement

Mise à jour:

Master-Master

Pour créer la synchronisation en master-master, les commandes sont les même en se qui concerne la création et l'ajout des bases et des tables à bucardo, seul la création de la synchronisation change

bucardo add sync <nom de la sync1> herd=<nom du groupe de table créé> dbs=<base1>,<base2>

bucardo add sync <nom de la sync2> herd=<nom du groupe de table créé> dbs=<base2>,<base1>

(Note: le même herd doit être utilisé pour les deux syn; par défaut dans dbs, la première base est source et les autres targets )

Dans mes tests <base1> = test3 et <base2> = test4

Donc ici il y a une sync qui a pour source test3 et comme target test4
Et une sync qui a pour source test4 et comme target test3

(Note: à chaque ajout de sync il faut restart bucardo)

Insertion sur test3: la replication fonctionne, la ligne apparait sur test4
Insertion sur test4: la ligne apparait sur test3
update sur test3: la modification est présente sur test4
update sur test4: la modification est présente sur test3
Ajout d'une colonne sur test3 puis ajout d'une ligne: la colonne n'est pas repliqué et l'insertion non plus
Ajout de la même colonne sur test4 puis insertion: l'insertion n'est pas repliqué
Supression de la colonne rajouté sur test4: test3 a repris les lignes ajouté pendant la présence de la colonne qui viens d'être supprimé
Ajout de ligne sur test4 sans la colonne "bonus" alors que test3 la possède encore: la ligne est bien ajouter a test3
Supression de la colonne "bonus" sur test3: test4 a rattrappé son retard
Ajout d'une colonne sur test4, puis ajout d'une ligne avec une valeur sur cette colonne, puis update de cette ligne, et enfin supression de la colonne: après la suppression de la colonne, test3 reprend toute les modifications effectuées
Ajout d'un index sur test4: il n'est pas présent sur test3
Update "simultané" sur les deux bases sur la même ligne (test fais à la main, donc la différence entre les deux update est environ de 1 seconde) : les deux update ont créé deux lignes différentes, voici les résultat du test
Avant update:
2 | 3 | 6
1 | 2 | 5
3 | 4 | 7
4 | 5 | 7
5 | 6 | 9
7 | 8 | 9
8 | 9 | 10
6 | 7 | 8
9 | 10 | 11
11 | 11 | 12
13 | 14 | 15
(11 lignes)

Après update

(Note: il y a eu une tentative avant donc voici la modification à ne pas prendre ne compte: update truc set id=id+4 where id=6 et update truc set id=id+45 where id=7)

voici les modification de ce test:

update truc set id = id+45 where id=8;
update truc set id = id+12 where id=8;

id | toto | tata
----+------+------
2 | 3 | 6
1 | 2 | 5
3 | 4 | 7
4 | 5 | 7
5 | 6 | 9
9 | 10 | 11
11 | 11 | 12
13 | 14 | 15
10 | 7 | 8
52 | 8 | 9
20 | 9 | 10 <--------------- Ligne rajouter par le update
53 | 9 | 10 <---------------
(12 lignes)

(AUCUN INSERT N'A ETE EFFECTUER ENTRE LES DEUX CAPTURE)

13. Arrêt de bucardo, puis insertion dans les deux master d'une ligne avec clé primaire différente puis redemarrage de bucardo: les deux masters reprenne les lignes insérer ou modifié après le redémarrage

14. Arrêt de bucardo, puis insertion dans les deux master d'une ligne avec la même clé primaire puis redémarrage de bucardo: c'est la ligne qui a été créé sur test3 qui a été recopié et qui a écrasé la ligne sur test4

(Note: Ce test a été effectué en commençant par insérer sur test3 en premier et en commençant par test4, le résultat ne changeait pas)

Greenplum

Fonctionnement du système

Greenplum est logiciel de base de données conçu pour faire de la parallélisation des données au sein de bases massives.
Le fonctionnement de greenplum est assez complexe, je vais commencer par le traitement des requêtes.

Quand le client envoie ça requête sur la base, il l'envoie en réalité à un "master" c'est lui qui va ensuite traiter la requête, établir un plan, coordonnée tous les processus, rassemblé et présenté le résultat final de la requête.
A chaque requête le master fait un query plan qui va ensuite selon le type de requête distribué à ce qu'on appelle les segments.
Au moment de la création de la base, les table des utilisateurs et leurs index ont été distribuée à travers tous les segments disponibles. Chaque segment contient une portion distincte de données. Ces segments sont ensuite rassemblés dans des serveurs appelés "segment host". Ces segments host peuvent contenir de deux à 8 segments. Tous les segments host ont la même config.
La liaison entre le master et les segments host se fait par l'interconnection, celle-ci utilise le protocol UDP par défaut.
Comme dit précédemment les requête sont partagées par type, les targeted et les parallel.
Les parallel sont toutes les requêtes qui affectent plusieurs lignes en même temps; le plan de ce type de requête est distribué à tous les segments (exemple: scan, jointure, aggrégation, trie).
Les targeted sont quand à eux toutes les requêtes qui n'affectent qu'une seule ligne.

Le master s'occupe comme je l'ai dit du query plan, c'est lui qui va ensuite être donnée aux segments et qui va leur dire quoi faire.
Ce plan va contenir toutes les opérations courantes que peut demander un client comme des jointures, des insertions... Mais ici il va contenir aussi une nouvelle opération le motion. Cela consiste à faire bouger les tuples entre les segments pendant les requêtes.
Ce plan va ensuite être divisé en slice. Un slice est une portion de plan qu'un segment peut travailler indépendamment. Un plan est "sliced" à chaque une opération motion dans le plan.
A noter qu'à la fin de chaque plan qui renvoie des données il y une opération gather motion qui à renvoyer des données au master.

Greenplum crée un certain nombre de processus pour gérer le travaille sur une requête. Sur le master ce processus s'appelle le "query dispacher". C'est lui qui est responsable de la création et de la distribution du plan d'exécution. Il permet aussi le rassemblé et de présenter le résultat final.
Dans les segments ces processus sont appelés les "query executor". Ils sont responsables de la complétion de la partie de requête donnée par le plan et envoient le résultat au master.
Un processus est également assigné à chaque slice du plan. Et tous ces segments travaillent en parallèle sur une requête.

Les processus qui travaillent sur le même slice mais dans des segments différents sont appelés "gangs". Quand une portion est finie, les tuples passent au gang suivant.

Maintenant je vais aborder la redondance dans greenplum.

Il est en effet possible de configurer un segment secondaire à chaque segment princiapal, ils sont alors appelés segments miroir. Ces segments sont une copie des segments principaux, et ils prennent leur place quand ceux-ci ne sont plus disponibles.
Il y a deux configurations différentes pour les segments miroir. Par défaut c'est le group mirroring, tous les segments miroirs sont placés sur un hôte différent de leur segment principal dans le cluster.
L'autre est le spread mirroring, ici les segments miroirs sur les hôtes où il reste de la place, avec donc d'autres segments principaux (différents de leurs segments principaux). Cela necessite donc que les hôtes soit assez gros pour accueillir ces segments miroirs.
Si aucun miroir n'est en place et qu'un segment n'est plus disponible le système entier s'arrête et il faut réparer tous les segments endommagés pour pouvoir relancer le système.

Le master aussi peut bénéficier du miroir, ici cela agit comme un warn standby, c'est-à-dire qu'il y a un serveur slave qui reçoit les données par replication et qui ne sert qu'à remplacer le master si celui-ci venait à tomber.

Aspect pratique de la partition dans greenplum

Source:http://greenplum.org/docs/admin_guide/ddl/ddl-partition.html

Dans greenplum, pour permettre la division d'une table dans les différents segments,les tables peuvent être partitionné et même sous-partitionné.
Pendant un CREATE TABLE il faut utiliser l'option PARTITION BY et/ou (si on veut une sous-partition) SUBPARTITION BY. Cela crée une table parent avec une ou plusieurs sous table les enfants.
La relation entre le parent ces enfants est similaire à la clause INHERITS dans postgres.

Il y a trois type de partition:

D'abord, date range:

Permet partitionner en jour,mois ,année... en utilisant les colonne de type date ou timestamp.
GP peut générer automatiquement des partitions en lui donnant les valeurs START, END, et une clause EVERY qui définie le pas de l'incrémentation (Par défaut, START est toujours inclusif et END est toujours exclusif)
Voici un exemple de commande:
CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date)
( START (date '2008-01-01') INCLUSIVE
END (date '2009-01-01') EXCLUSIVE
EVERY (INTERVAL '1 day') );
La partition commence à la date 2008-01-01 inclu et se fini à la date 2009-01-01 exclu avec une partition par jourde l'interval
On peut aussi déclaré manuellement les partition.
Exemple:
CREATE TABLE sales (id int, date date, amt decimal(10,2))
DISTRIBUTED BY (id)
PARTITION BY RANGE (date)
( PARTITION Jan08 START (date '2008-01-01') INCLUSIVE ,
PARTITION Feb08 START (date '2008-02-01') INCLUSIVE ,
PARTITION Mar08 START (date '2008-03-01') INCLUSIVE ,
PARTITION Apr08 START (date '2008-04-01') INCLUSIVE ,
PARTITION May08 START (date '2008-05-01') INCLUSIVE ,
PARTITION Jun08 START (date '2008-06-01') INCLUSIVE ,
PARTITION Jul08 START (date '2008-07-01') INCLUSIVE ,
PARTITION Aug08 START (date '2008-08-01') INCLUSIVE ,
PARTITION Sep08 START (date '2008-09-01') INCLUSIVE ,
PARTITION Oct08 START (date '2008-10-01') INCLUSIVE ,
PARTITION Nov08 START (date '2008-11-01') INCLUSIVE ,
PARTITION Dec08 START (date '2008-12-01') INCLUSIVE
END (date '2009-01-01') EXCLUSIVE );
Notez qu'il y a pas à déclarer de END sauf à la dernière partition.

Ensuite numeric range:

Permet de partitionner par ensemble de nombre

Ici on donne une valeur de départ START et et valeur d'arrivé END ainsi que le pas d'incrémentation EVERY
Exemple:

CREATE TABLE rank (id int, rank int, year int, gender
char(1), count int)
DISTRIBUTED BY (id)
PARTITION BY RANGE (year)
( START (2001) END (2008) EVERY (1),
DEFAULT PARTITION extra );

(Note: je parlerai du "DEFAULT PARTITION extra" plus tard dans ces explications)

Et enfin list of values:
Permet de partitionner par ensemble de valeur de type quelconque

Exemple:

CREATE TABLE rank (id int, rank int, year int, gender
char(1), count int )
DISTRIBUTED BY (id)
PARTITION BY LIST (gender)
( PARTITION girls VALUES ('F'),
PARTITION boys VALUES ('M'),
DEFAULT PARTITION other );

Comme je l'ai dit plus tôt Greenplum permet aussi de faire des sous-partitions.

Voici un exemple de table avec 2 niveau de partition:

CREATE TABLE sales (trans_id int, date date, amount
decimal(9,2), region text)
DISTRIBUTED BY (trans_id)
PARTITION BY RANGE (date)
SUBPARTITION BY LIST (region)
SUBPARTITION TEMPLATE
( SUBPARTITION usa VALUES ('usa'),
SUBPARTITION asia VALUES ('asia'),
SUBPARTITION europe VALUES ('europe'),
DEFAULT SUBPARTITION other_regions)
(START (date '2011-01-01') INCLUSIVE
END (date '2012-01-01') EXCLUSIVE
EVERY (INTERVAL '1 month'),
DEFAULT PARTITION outlying_dates );

D'abord il y a la table parent qui est partitionner en date (PARTITION BY RANGE (date) ), cette partition commence le 2011-01-01 et fini le 2012-01-01 et il y a une partition par tranche de 1 mois. Ensuite le deuxième niveau de partition se fait par région. On a défini trois partition avec comme valeur de réparition usa,europe,asia.

Voici une figure de la table et de ces partitions:

Attention toutefois à ne pas faire trop de niveau de partion car le nombre de sous-partition peut facilement explosé.

Alors on voit dans cette exemple la clause DEFAULT PARTITION à trois reprise. En effet cette clause est obligatoire si il y a plusieurs niveau de partition. Celle-ci permet quand le système interroge les différentes partitions, que si la valeur de la requête n'appartient à aucun interval, de ne pas avoir la reqête rejeté. Donc les données qui ne corresponde à aucune partition sont inséré dans la partition par défaut.

Il est a noté également que on ne peut pas accèder aux différentes partition, celle-ci sont bloqué à l'accès =>ERROR: failed to acquire resources on one or more segments .

Pour finir, On ne peut pas partitionner une table existante, on ne peut créer les partition que au moment de sa création.

Test efficacité

Rsultat_GreenPlum.ods

Tableau comparatif bucardo/Replication intégré de postgresql

(Ici je vais seulement comparé la replication master-slave)

	Postgresql	Bucardo
Fonctionnement	Fonctionne sur une base d'un demon qui lit les fichiers wal du master pour les lancer sur le slave, tout les modification sont donc prise en compte. De plus de base le slave est en mode lecture seulement. Toute la base est en replication, donc l'ajout de table est pris en compte et est répliqué.	Fonctionne sur une base de triggers qui s'installe sur les tables qui sont répliqué, ici la replication ne s'effectue que sur des tables données au moment de la création de la synchronisation, donc si l'on veut rajouter une table il faut la mettre sur le(s) slave(s) et le(s) master(s) et l'ajouter à la synchronisation. De plus de base le(s) slave(s) ne sont pas en lecture seul.
Type d'usage	Très utile quand on a une base où la structure est souvent modifié (ajout d'index,de table, de colonne,de cluster...) le problème étant que les grosses opération bloque toutes les bases étant donnée que tout est répliqué	Par contre ici si l'on possède une base plus fixe avec peu d'ajout de nouvelle table mais avec beaucoup de donnée ajouter, et un grand nombre de lecture cette solution est meilleur, car la lecture n'est jamais bloqué par un lock et donc toujours disponible. Le problème étant qu'à chaque modification de la structure des tables il faut faire cette modification sur chaque slaves et masters
Gestion des locks	Tous les locks génèré par le master sont repliqué sur tous les slaves. Ce qui peut empêché la lecture en cas de grosse opération.	Les locks ne sont pas répliqué, donc si le master effectue une grosse opération, la lecture est encore possible sur les slaves
Type de synchronisation	On peut faire du synchrone ou de l'asynchrone	Ici on ne peut faire que de l'asynchrone
Desynchronisation	En case de désynchronisation, on peut utlisé un failover pour rattrapé et passer un slave en master	En master-slave la désynchronisation semble peu problable car si le slave est éteint pendant un temps quand il se rallume et que la sync est allumé, il rattrape tout son retard, de plus quand une ligne est inséré sur le slave et sur le master avec la même clé primaire, un principe de priorité s'effectue et la ligne du master remplace celle du slave, c'est la même chose entre deux master, un des deux à la priotité sur l'autre. En effet la gestion des conflits sur bucardo se fait de trois manières différentes, soit il est paramètré en bucardo_latest (par défaut) et il résoudra les conflits automatiquement en comprarant les dernières modification sur les tables. Sinon on peut, au moment de la création de la synchronisation, donner une liste de base de la plus "prioritaire" à la moins "prioritaire". Je m'explique, prenont comme exemple une liste de trois base , test1,test2 et test3 (donner dans cette ordre au moment de la création de la synchronisation avec le paramètre conflict). Si un conflit intervient entre test1 et test2 sur une ou plusieurs ligne c'est TOUJOURS les lignes de test1 qui vont "remporter" le conflit et qui vont être repliquer dans les autres bases, car test1 a la priorité sur test2. En revanche si un conflit intervient entre test2 et test3 c'est test2 qui a la priorité et qui va remporter le conflit. Une dernière manière de gerer les conflits est de créer un (ou plusieurs qui seront exécuté à la suite) script en Perl qui va définir les règles de priorité sur les bases. Un moyen de désynchronisé les bases est de créer une nouvelle colonne sur un master, dans ce cas plus aucune replication se fait et la synchronisation est désactiver. Pour ajouter des colonnes (ou tout autre modification sur la table alter table..) il faut faire la même modification sur TOUTES les bases de la réplication, puis lancer la commande bucardo reload sync [nom de la synchro] ce qui va permettre de mettre à jour la synchronisation (A noter que durant cette opération la base est disponible). A noté que cette commade est très rapide même avec une grosse table de quelque million de ligne. Fait pas encore expliquer, les bases ne reprenent pas tout de suite leur retard, et semble le reprend au moment d'une nouvelle écriture. https://bucardo.org/wiki/Bucardo/Conflict_Handling
Paramétrage	Beaucoup de chose sont paramétrable, comme le delai de synchronisation, la replication en streaming, le temps que met le master a mettre a jour les wal...	Ici aussi c'est très paramètrable, on peut donner un email pour ce connecter vis celui-ci, on peut paramètrer le temps de la synchronisation, il est possible de donner une raison a chaque start/stop/restart qui seront stocker dans un fichier log,...
Documentation	Très très bien faite et à jour ET disponible en français	Je ne vais pas évoquer la doc de bucardo, je n'ai pas envie d'être vulgaire, disons qu'elle est encore à la version 4.0 alors que bucardo est à la version 5.4 (sauf quelques pages),et il manque des choses dans l'installation. Par contre le man est à jour ce qui remplace la documentation sur le wiki, qui est le seul site à proposer des choses sur bucardo
Popularité	L'outil est directement lié à postgres qui est très utilisé de nos jours	Bucardo est souvent sité dans les doc postgres, et pendant un temps était vraiment populaire, car il venait d'être créé et c'était le seul a proposé du master-master mais depuis quelque année(2011) je ne trouve plus de forum en qui en parle. je n'ai pas trouver d'information concernant des entreprise qui utilise bucardo