• [^] # Re: Recovery_target

    Posté par (site web personnel) . En réponse au journal PostgreSQL 9.4 en beta. É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 ?