Désactiver local_monitor

Categories: Non classé
Tags: No Tags
Comments: No Comments
Published on: 19 janvier 2015

Bonjour,

depuis la version slony2.1 il existe un process local.monitor, qui monitor comme son nom l’indique la réplication.
Et bien je vous conseille de la désactiver car je n’ai pas trouver l’utilité, je trouve que ça fait de la redondance par rapport à l’écriture de la log.
Bien-sûr ça permet de connaitre l’état quasi temps réel sans lire un fichier texte, mais il suffit d’avoir une grosse réplication avec plusieurs noeuds, plusieurs sets, plusieurs clusters pour que la charge induite par cette outils deviennent vraiment problématique.
2 process par cluster, une mise à jour constante de la vue sl_components ( dans mon cas en quelques mois j’ai eu 4Millions d’ update sur la vue d’un cluster par exemple ).

Donc j’aurais tendance à dire que pour les grosses réplications il est conseillé de le désactiver, dans mon cas j’ai préféré l’enlever.

pour info pour l’enlever vous devrez obligatoirement passer par un -f au lancement du slon, avec un monitor_threads=OFF

Postgresql chez Amazon RDS

Categories: Hébergeur, Postgresql
Tags: No Tags
Comments: No Comments
Published on: 15 mai 2014

Bonjour,

Je viens de me rendre compte qu’ Amazon RDS (amazon web services) permet en béta de monter des bases postgresql dans leur cloud.
Postgres rejoint donc mysql, oracle et sql server.

De ce que j’ai remarqué les serveurs sont localisés en Irlande, comme par hasard ^^

pour ceux que ça intéressent de tester : https://aws.amazon.com/fr/rds/postgresql/
Pour info il faut créer un compte et mettre la CB (même si elle ne doit pas servir de suite).

Changer l’ IP du serveur sous Slony

Categories: Postgresql, slony
Comments: No Comments
Published on: 14 décembre 2012

Bonjour,

Changer l’ip d’un serveur est loin d’être courant et cela engendre souvent bien des problèmes…

Slony ne sera pas si compliqué à gérer pour ce genre de problème, connaître cette technique est utile si vos serveurs sont dans un Wan (changement FAI, contrat,etc…).

Il y a 2 solutions :

  • Delete de la réplication -> nouvelle réplication
  • Modification du catalogue de la réplication

et c’est cette dernière que je vais décrire brièvement.

Il suffira de se connecter sur les 2 catalogues (maitre et esclave), on ouvre la table sl_path, vous y trouverez quelques chose de ce type dans le champ « pa_conninfo » :

dbname=madb host=192.168.0.10 port=5432 user=slony password=abc

il suffit de changer l’ host par la nouvelle ip, faites cette manipulation sur les 2 serveurs.

On kill les 2 daemons slon et on les relance.

Pensez bien à modifier le .pgpass (si vous l’utilisez)et le pg_hba.

Je fais tout à partir de pgadmin, faisable sans problème en psql depuis le terminal.

Slony 2.0.1 pg 9.1

Problem solved

Slony en WAN ?

Categories: slony
Comments: No Comments
Published on: 2 octobre 2012

Il est peu recommandé d’utiliser Slony sur un réseau étendu ( wan ).
Pourtant ça marche très bien mais sous certaines conditions.

Déjà la stabilité de la réplication dépendra de la ligne, j’ai constaté une grosse différence de stabilité entre le même opérateur.

Ensuite le choix du placement des Daemons slons est primordial.

Sur une infrastructure Lan vous pouvez lancer tous les slons sur le même serveur Maitre pour faire une sorte de gestion administrée, les Slony-ctl fonctionnent comme ça, et dans la plus part des cas c’est très bien.

Mais pourquoi ne pas le faire en Wan ?

2 raisons :

– Si vous avez trop de noeuds, il y aura trop de process sur le Maitre, imaginez 6 serveurs, chacun avec 2 réplications, on est a 12 *2 process sur la machine, on rajoute à ça une gestion des logs par réplication, ça fait beaucoup trop de travail pour le serveur qui doit en plus gérer sa base Postgresql.
En lançant les slons en local, on réparti donc les process et leur travail, et la gestion des logs peut etre affinée.

- Avoir les slons en local permet une meilleure stabilitée, et pas qu’un peu, pour info un serveur avec une ligne adsl moyenne, avec un slon distant plante une fois par jour avec état de zombie et ne se rattrape pas seul ! un redémarrage est obligatoire !
Si le slon est démarré en local, ce même serveur plante une fois par semaine environ (la durée moyenne pour se rattrapper dans mon cas se situe aux alentours de 20min), et se rattrape tout seul !!

Par contre pour démarrer un slon en local n’oubliez pas que le host est le 127.0.0.1 ! et oui car sur un wan c’est l’ip publique que vous voyez ! (hors vpn)

Voilà pour mon petit constat sur slony 2.0.7 en wan ( et oui toujours pas en 2.1 ^^ )

Postgresql dans le monde du mmo ?

Categories: job, Postgresql
Comments: No Comments
Published on: 26 juin 2012

Bonjour,

La société Zenimax a cherché ou cherche un database administrator pour le futur mmo ElderScroll Online, j’aimerais bien savoir si c’est pour le backoffice ou pour réellement gérer le jeu.

Sachant qu’ils cherchent une brute on peut penser que c’est pour le jeu :p

L’annonce en question : jobs.zenimax

Je sais que Bioware pour Swtor utilisait Oracle, ça serait je crois une première pour Postgresql d’être la base de donnée d’un MMO.

Avis sur Postgresql Gestion des performances

Categories: Livre, Postgresql
Comments: No Comments
Published on: 28 mars 2012

Bonjour,

ça fait longtemps qu’il est sorti mais je me devais de faire une critique sur ce livre, qui pour moi est une référence.
Un administrateur en base de données se doit d’avoir au moins lu ce livre, et un administrateur système devrais y jeter un coup d’ oeil au minimum.
Comme beaucoup je suis les deux, souvent les petites entreprises n’ont pas les moyens d’avoir un dba et un admin système, ce livre devient donc une vraie mine d’or (pour pas cher :p).
On y retrouve vraiment tout, on passe du matériel à l’optimisation de requêtes en passant par le monitoring et la maintenance…

Alors biensûr ce livre n’est pas fait pour les débutants, rien que la partie sur le matériel est loin d’être anodine, ça va loin et c’est bien, souvent ce genre de livre n’en parle pas ou survole… ici on a le droit a un bon gros chapitre bien complexe.

Certains chapitres m’ont beaucoup plus, comme l’optimisation des requêtes qui restent complexes mais très passionnants, et qui nous invitent à faire beaucoup de tests et de recherches pour comprendre toutes les subtilités de l’explain.
Le chapitre sur la maintenance est aussi très intéressant tout comme celui parlant des statistiques.

Pour conclure ce livre est une vraie bible, enfin surtout la mienne ! Ce livre vous incite à comprendre ce que vous faites, ce n’est pas qu’un listing de scripts, de requêtes ou de formules, si vous désirez comprendre ce que vous faites ce livre vous y aidera.
Ce livre est un formidable allié pour ceux qui désire se lancer dans l’aventure postgresql et qui désire aller plus loin.

Merci à Gregory Smith et nos 2 traducteurs ( Guillaume Lelarge et Thomas Reiss )

couverture

Lien pour l’acheter chez pearson.fr

Install postgresql avec yum et modif de port !

Categories: Postgresql
Tags: No Tags
Comments: 2 Comments
Published on: 7 novembre 2011

Bonjour,

J’ ai constaté une petite coquille avec l’installation de postgresql 9.0.x avec Yum sur Centos (par exemple).
On a beau changer de port au niveau du postgresql.conf ça ne change en aucun cas le port d’écoute :)
Il faut aller dans le /etc/init.d/postresql-9.0 et modifier le PGPORT à la main.

Et il ne faut pas oublier qu’en cas de mise à jour le port par défaut (5432) reviendra dans le fichier de démarrage, donc à remodifier.

Voilà je voulais juste le signaler ^^

edit suite a un commentaire fort intéressant que je recopie ici pour plus de visibilité :

j’en profite pour noter une petite astuce à base de variables d’environnement, avec les paquets PG ( http://yum.postgresql.org/ )

Il suffit de linker le script dans /etc/init.d, et de créer le fichier de config correspondant dans /etc/sysconfig/pgsql/

Article détaillé sur le blog de 2nd Quadrant :
http://blog.2ndquadrant.com/en/2010/05/install-multiple-postgresql-servers-redhat-linux.html
Et quelques infos sur le wiki :
http://wiki.postgresql.org/wiki/PostgreSQL_on_RedHat_Linux

Htaccess en postgresql !

Categories: apache, Postgresql
Comments: No Comments
Published on: 26 septembre 2011

Bonjour à tous,

Qui n’a jamais eu besoin de protéger un dossier ou une partie de son site rapidement et facilement ?? moi en tout cas ^^ et franchement la méthode la plus rapide est bien le htaccess ! et je vais donc vous expliquer comment faire !! mais là vous vous dites ouai super c’est pas comme ci il y avait 36 000 tutos de ce types… :s et bien non pas avec un accès postgresql :)

Alors déjà pourquoi et quel intérêt ?

Un accès sécurisé avec un htaccess à priori n’est pas super sécurisé dans sa « forme primaire » ( .htaccess et .htpasswd ), il faut passer en mode md5 pour rendre le truc un peu plus sécur !
Et en cherchant j’ai trouvé qu’on pouvait faire une connexion mysql et là je me suis dis bah y a bien un type qui à fait l’équivalent en postgresql !! et bingo effectivement :)
donc mon intérêt c’est de bosser sur du postgresql et sécuriser réellement mon dossier.

Donc premièrement on va commencer par installer le module supplémentaire requis par apache, j’utilise toujours centos donc un coup de yum :

yum install mod_auth_pgsql.x86_64

Maintenant on peut paramétrer le ficher .htaccess, je ne mettrais que les options que j’ai décidé de mettre :


AuthName "authentification sous postgresql"
AuthType basic
Auth_PG_host 127.0.0.1
Auth_PG_port 5432
Auth_PG_user postgres
Auth_PG_database admin
Auth_PG_pwd_table public.admin
Auth_PG_uid_field public.admin.user
Auth_PG_pwd_field password
Auth_PG_encrypted on
Auth_PG_hash_type MD5
require user bigboss

Pour ceux ayant déjà fait des htaccess les 2 premières lignes ne devraient pas vous étonner, c’est le type d’authentification « basic » et le nom du popup ouvert pas le navigateur.

Auth_PG(_host,_port,_user) la connexion connue type psql (il est possible de rajouter un argument password pour l’ utilisateur postgres ou autre, n’aimant pas avoir de password écris dans des fichiers textes je préfère rester avec l’utilisateur qui utilise une connexion Ident).

Auth_PG_database précise la base de donnée où se situe la table d’accès.

Auth_PG_table précise la table utilisée, on remarquera que je précise le nom de schéma devant.

Auth_PG_uid_field précise le champ avec le nom de l’utilisateur (son login), j’ai du pour faire fonctionner le module préciser le schéma ainsi que la table !

Auth_PG_pwd_field précise le champ du password, cette fois je n’ai pas eu besoin de préciser autant que le champ user.

Auth_PG_encrypted et Auth_PG_hash_type sont relié entre eux puisque c’est ce qui me permet de mettre mon champ password en md5.

La derniere ligne commune à tous les .htaccess précise la personne qui a les accès, on peut mettre valid-user ou spécifier des noms en particulier ce que j’ai choisi.

Dernière étape les petites modif au niveau d’apache, dans votre virtual host il vous faudra rajouter 2 lignes :


AuthType Basic
AllowOverride All

Vous mettez les mêmes lignes pour un htaccess simple donc rien à dire de plus à ce sujet.

Il est possible de rajouter des champs pour notamment loguer les connexions, on peut aussi rajouter un champ de « score » qui permet de faire des gestions de droits un peu plus complexe avec l’option Auth_PG_pwd_whereclause.

Voici biensur le site du dev en question avec toutes les options possibles et l’ explication qui va bien. mod_auth_pg site dev

Biensur l’interet c’est de faire une authentification de son site en peu de temps et quand ça reste simple !
J’aurais tendance à mettre du ssl sur le site pour protéger un peu plus notamment la demande de connexion.

Voilà j’espère que ça aidera d’autres personnes qui comme moi n’avaient jamais entendu parlé de ce module.

testé avec pgsql 9.0.4 et apache 2.2

Petit retour sur Slony 2.0.7

Categories: Postgresql, slony
Comments: 2 Comments
Published on: 6 septembre 2011

A priori je suis content… :)

Mon bug était :

Après un arrêt réseau coté maître ou esclave ma réplication reprenait correctement mais pourtant mon écart continuais de monter… donc mon monitoring continuait de crier au secours… un peu relou avec un mail toutes les 10mins…

Et maintenant j’ai testé un arrêt coté slave et une coupure réseau coté maître et tout est revenu nickel après :D

Problème sloved !

Par contre je voudrais dire un grand merci à la personne qui gère www.pgrpms.org, c’est tellement simple de faire un :

yum update slony1-90
/love :p

Et conjugué aux outils slony-ctl c’est du pure bonheur merci à eux.
Après une simple yum sur toutes les machines utilsant la réplication il suffit d’ utiliser le script 42 avec comme argument le nom de la répli et son set :)

Testé et approuvé

Slony passe en 2.0.7

Categories: Postgresql, slony
Comments: No Comments
Published on: 2 août 2011

bonjour,

Juste pour vous informer que slony passe en 2.0.7 et c’est pas plus mal j’espère qu’ils ont réparé le bug qui me tracassait depuis longtemps, à savoir qu’après une coupure la réplication revenait bien mais slony considérait toujours le slave comme hs… bug chiant mais pas préocupant :p

j’éditerais après l’avoir mis en fonction.

Merci aux devs ;)

lien de la release notes

page 1 of 2»

Welcome , today is Dimanche, 25 septembre 2016