L'annonce :
http://www.postgresql.org/about/news/1522/
Le wiki (pas complétement à jour) :
http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.4
La Release Note (pas complètement à jour) :
http://www.postgresql.org/docs/devel/static/release-9-4.html
Les grandes nouveautés :
- Le rafraichissement des vues matérialisée non bloquant : lien
- JSONB : lien
- Une avancée vers la réplication logique : les replication slot : lien
et beaucoup d'autres choses :
- pouvoir retarder l'application des changements sur un standby de N secondes
- ALTER SYSTEM : modifier un paramètre de configuration du serveur en SQL (stockage dans le fichier postgresql.auto.conf en parallèle du postgresql.conf)
- …
Pour les DBA en herbe ou au foin : il faut l'installer et le tester !
# Recovery_target
Posté par apkwa . Évalué à 3.
Bonne nouvelle. Ca avance vraiment très vite ces derniers temps.
Dans la release note, je vois le nouveau paramètre "recovery_target" qui permet de stopper le mode recovery dès qu'on a atteint un état consistant: http://www.postgresql.org/docs/devel/static/recovery-target-settings.html#RECOVERY-TARGET
Mais en pratique, ca sert à quoi?
Soit on est en réplication stream, dans ce cas on a aucun intérêt de stopper la répli (sauf pour un failover par exemple), soit ca signifie que jusqu'à maintenant, on ne pouvait pas faire un recovery consistant. Je ne sais pas trop, si qqun peut m'éclairer?
Sinon, il y a un truc embêtant avec la streaming repl, c'est que si on est en mode synchrone et que le hot_standby crash, alors le maître continue tout de même à attendre sa réponse avant de renvoyer le retour du COMMIT au client. J'avais cru voir qu'une nouvelle option aller apparaître pour permettre d'ajouter un timeout, mais impossible de la retrouver…
En tout cas, la réplication slot est bien sympa!
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . Évalué à 3.
Pour le recovery_target : lien
Pour moi, nous ne sommes pas dans le cas d'une réplication en streaming qui elle ne pose pas de pbs de consistance (je passe régulièrement des slave en master sans aucun problème).
Pour le streaming synchrone (que je n'utilise pas), de mon point de vue : si tu acceptes que ta réplication ne soit pas synchrone, il faut passer en asynchrone. Dans le cas contraire, un crash du slave est une erreur grave qui va nécessiter une intervention. Je ne connais pas beaucoup de monde (voir personne dans mes connaissances) qui utilise la réplication synchrone.
[^] # Re: Recovery_target
Posté par apkwa . Évalué à 1.
Ok, merci pour le lien, j'y vois un peu plus clair même si j'ai toujours un peu de mal à assimiler toutes les notions de recovery et de WAL.
Si tu es en répli synchrone, ca veut dire que potentiellement, tu peux perdre des données non? Genre le serveur maître crashe, et du coup tu perds les WAL qui n'ont pas encore été transférés?
J'avais essayé de simuler ce cas, mais je n'avais pas réussi (comme quoi pg est performant…)
Vu que tu as l'air de bien maîtriser ton sujet, je me permets d'abuser et de te poser une question un peu HS concernant les WAL: Si j'ai bien compris, en cas de perte de mon serveur, je restaure le backup et je rejoue les WAL pour récupérer un max de données jusqu'au crash.
Par contre, si j'ai plusieurs serveurs en réplication (synchrone ou non), est-ce que je dois partager les WAL? Je veux dire, est-ce que je dois mettre en place un 3ème serveur sur lequel je dépose en NFS les WAL du maître pour qu'ils soient pris en compte par le slave, ou bien ca n'a aucun intérêt?
Dans mon cas, chaque serveur archive ses WAL de son côté (et je suis en synchrone), mais je ne sais pas qu'elle est la pratique correcte…
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . Évalué à 3.
Concernant le crash du master en mode synchrone : pour moi, tu vas perdre les transactions en cours (non commitées).
En mode streaming, le transfert de WAL n'est pas obligatoire, les slaves se connectent sur le master directement et demandent eux même les WAL manquants au démarrage. Dans ce cas, il faut que le serveur garde suffisamment de fichiers pour pouvoir servir les slaves en cas de coupure : parametre wal_keep_segments du postgresql.conf
ex : nous avions planifier une coupure réseau d'une journée entre 2 sites, j'ai augmenté ce paramètre suffisamment pour contenir l'ensemble des WAL dont j'avais besoin pour rétablir les stanby. Quand le réseau est revenu : les slaves se sont resynchronisés automatiquement.
Chez moi, si on perd un master, on bascule sur un slave le temps de reconstruire le master. Je ne fais que des backups avec pg_dump, pas de hot-backup avec sauvegarde des WAL. Mais dans ton cas : oui, tu restores ta sauvegarde et tu rejoues tes WAL.
Je ne comprends pas l’intérêt d'avoir un 3ème serveur sur lequel stocker tes WAL pour tes slaves vu que tu les stockes déjà pour ton backup (hot-backup + WAL) : ou alors je rate quelque chose :)
Juste une question : tu as vraiment besoin de réplication synchrone ?
[^] # Re: Recovery_target
Posté par apkwa . Évalué à 1.
D'accord, merci pour toutes ces explications.
Le coup du 3ème serveur, moi non plus je ne vois pas trop l'intérêt :) C'est juste qu'en lisant les docs, je ne savais plus si c'était intéressant dans mon cas ou non. Donc je préférais avoir l'avis d'un expert.
Si mon master crashe, que je sois en synchrone ou non, je pense que de toute façon on va perdre les transactions en cours. Ca ne me gêne pas plus que ca, c'est aux applis de s'adapter et de voir si elles ont réussi le commit ou non.
Est-ce que j'ai besoin du synchrone, je ne sais pas. En fait, je me disais qu'en synchrone, en cas de crash, je suis sûr d'avoir le standby au même niveau et prêt pour un failover ultra rapide.
En asynchrone, selon le type de crash, je vais sûrement perdre la transaction en cours, mais peut-être aussi les transactions précédentes dont les WAL n'ont pas encore été transférés (enfin, c'est comme ca que je l'imagine, je me trompe peut-être).
En tout cas, je veux bien ton avis là-dessus. C'est vraiment l'idée de perdre le moins de transactions qui m'intéresse. Je ne fais pas de rw-splitting.
Merci en tout cas!
[^] # Re: Recovery_target
Posté par barmic . Évalué à 3.
J'ai du mal à voir l'utilité. Je présume qu'en mode synchrone, on a des perf' pourries, si en plus on est en single point of faillure, on a le pire des 2 mondes…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Recovery_target
Posté par claudex . Évalué à 3.
Non, tu es sûr d'avoir des données cohérentes sur disque sur deux points en même temps.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . Évalué à 2.
c'est ça : un choix de vie => données cohérentes et synchrones sur 2 serveurs donc perte de perfs car le master doit valider que le slave a bien validé la transaction avant de valider de son propre côté. Il faut vraiment en avoir besoin pour l'activer.
[^] # Re: Recovery_target
Posté par Bastien Mourgues . Évalué à 1.
Peut être que je me plante, mais pour avoir des données répliquées sur 2 machines, un système basé sur DRBD ne fait-il pas l'affaire ?
[^] # Re: Recovery_target
Posté par arthurr (site web personnel) . Évalué à 1.
L'utilisation de DRBD est possible, mais dans ce cas, le slave ne va pas pouvoir être démarré (et donc pas en lecture seule).
Mais la réplication dans PostgreSQL est si simple à mettre en place, que je ne vois pas l’intérêt de rajouter une couche.
[^] # Re: Recovery_target
Posté par barmic . Évalué à 3.
Ce n'est pas la même granularité, il n'a pas les même garanties de cohérence que le SGBD (DRBD n'a pas conscience des transactions applicatives).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.