Heartbeat DRBD PostgreSQL soucis de base

Support Debian
#1

Bonjour à tous,
Je vous sollicite une fois de plus pour un problème que je ne comprends pas.

Je viens de mettre en place une solution Heartbeat DRBD pour répliquer le tablespace de ma base postgresql entre deux machines virtuelles.

Comprendre comment fonctionne DRBD ( Raid sur IP ) n’est pas primordial pour comprendre mon problème. On associe juste un disque a un dossier. Qui est monté avec en cas d’interruption de service grâce à Heartbeat.

Configuration Heartbeat :

haressource

QST-PostgreSQL IPaddr::192.168.0.110 drbddisk::postgresql Filesystem::/dev/drbd1::/home/pgsql::ext3 postgresql

ha.cf

logfile         /var/log/ha-log
logfacility     local0
keepalive       2
deadtime        45
bcast           eth0
node            QST-PostgreSQL QST-PostgreSQL-Esclave
auto_failback   yes
respawn         hacluster /usr/lib/heartbeat/ipfail
apiauth         ipfail gid=haclient uid=hacluster

(je ne vous met pas le fichier authkeys car il n’a pas d’importance majeure )

Configuration DRBD :

global { usage-count yes; } common { protocol C; } resource postgresql { on QST-PostgreSQL { device /dev/drbd1; disk /dev/sdb1; address 192.168.0.3:7789; meta-disk internal; } on QST-PostgreSQL-Esclave { device /dev/drbd1; disk /dev/sdb1; address 192.168.0.4:7789; meta-disk internal; } }

Le disque se monde des deux côtés sans soucis.
Le FailOver s’exécute normalement. Pas de problème.
Les données sont disponible des deux côtés sans soucis, j’ai effectué un “update-rc.d -f postgresql remove”.

Cependant quand on bascule sur l’esclave pour simulé une coupure du maître; La base de données n’est pas chargé, même si les données présente dans le tablespace sont répliquées.

Comment puis-je résoudre ce soucis ?

Cordialement

#2

Je viens de me rendre compte que les données sont aussi stockées dans /var/lib/postgresql/8.4/main et je ne répliquais pas ce répertoire entre mes esclaves.
Donc mettre la base dans un tablespace /home/pgsql/ ne suffit pas.
J’ai crée un dossier main dans /home/pgsql qui est la partition que je réplique avec DRBD

Si l’on modifie le chemin " à l’arrache " on a une erreur de certificat que l’on comble avec l’enchainement de commande suivant.

(au préalable j’ai copier vulgairement les fichiers de /var/lib/postgresql/8.4/main dans /home/pgsql, il faut juste penser a faire un chmod -R 0700 et un chown -R postgres:postgres car si vous copier tout en root cela ne fonctionnera pas )

On regénére ensuite un certificat ( si vous avez l’erreur au redémarrage de Postgresql ).
Ne faites pas la même erreur que moi, a spammer ENTER, il faut le remplir correctement et mettre la même chose quand il nous repose des questions.

[code]su - postgres
cd /home/pgsql/main
openssl req -new -text -out server.req
openssl rsa -in privkey.pem -out server.key
rm privkey.pem
openssl req -x509 -in server.req -text -key server.key -out server.crt
chmod og-rwx server.key
chown postgres.postgres server.key

(possible que les liens si dessous soient déjà actifs, mais dans le cas contraire)
cd /home/pgsql/main/
ln -s /home/pgsql/main/server.key .
ln -s /home/pgsql/main/server.crt .[/code]

La actuellement j’ai un soucis de 'log".
La base de données se lance avec son nouveau répertoire sur mon Maitre mais pas sur mon Esclave.

Erreur postgresql " Couldn’t read /var/log/postgresql"
Quand on ouvre le fichier de log, il nous dit qu’il n’arrive pas créer le fichier de verrou /var/run/postgres_NUMEROSDUVERROU

J’ai donc rajouté dans ma partition DRBD /home/pgsql un répertoire var

Donc désormais toutes les variables qui se crée au lancement de postgresql dans /var/run/postgresql seront sur /home/pgsql/var et par conséquent sur l’esclave aussi vu qu’il monte le disque en cas de coupure du maître.

En redémarrant mon serveur il me remet la même erreur comme quoi il n’a toujours pas les droits pour créer le PID dans /home/pgsql/var ( initialement /var/run/postgresql ) et la …
Je m’aperçois que :

http://imageshack.us/photo/my-images/31/pgsql.png

DRBD remplacer le groupe et l’utilisateur de tous les fichiers.
Donc un petit chown -R postgres:postgres * et postgreSQL se lance sur l’esclave et le maitre avec les même fichier, et se réplique en création de base de données supplémentaire.

J’ai même essayé avec une restauration d’un dumpall.sql

Cependant lorsque vous redémarré un maître ou un esclave, DRBD se réapproprie les droits sur les fichiers ( pourquoi je ne sais pas c’est la première fois que je vois cela ) .

Donc j’ai rajouté dans le rc.local de mon maitre.

chown -R postgres:postgres /home/pgsql/*
/etc/init.d/postgresql restart

( Oui je sais que c’est pas très cathologique )
Et sur mon esclave comme la partition n’est que très souvent monté et qu’elle n’aura pas les fichiers avec les bon droits …
J’ai fais une crontab avec un script qui fait la même chose qui s’exécute toutes les 30 secondes.

Bien que la plus part du temps la partition ne sera pas monté, donc que le script tournera dans le vent, mais je ne vois pas comment faire.

Bref problem solved.

#3

( à titre indicatif )
Pour les problèmes de droits sur les fichiers il s’agit de Heartbeat et non de DRBD

logfile         /var/log/ha-log
logfacility     local0
keepalive       2
deadtime        10
bcast           eth0
node            nom_serveur1 nom_serveur2
auto_failback   no
respawn         hacluster /usr/lib/heartbeat/ipfail
apiauth         ipfail gid=haclient uid=hacluster

Pour avoir les fichiers avec les bon droits et sortir ma configuration foireuse du rc.local et du batch cité plus haut j’ai modifié le fichier comme ceci.

logfile         /var/log/ha-log
logfacility     local0
keepalive       2
deadtime        10
bcast           eth0
node            nom_serveur1 nom_serveur2
auto_failback   no
respawn         hacluster /usr/lib/heartbeat/ipfail
apiauth         ipfail gid=postgres uid=postgres

Voilà, la réplication d’une base de données de 6 Go via bloc de disque fonctionne.