Journal PostgreSQL 9.4 en beta

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
20
15
mai
2014

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  . É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  (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  . É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  (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.

          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.

          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  . É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  . Évalué à 3.

        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.

        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  . Évalué à 3.

          on a le pire des 2 mondes…

          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  (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  . É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  (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  . É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.