Hacker News Reader

Comment by craigkerstiens | Hacker News Reader

At a high-level they're very similar in the problem they solve, both are focused on giving you reliable disaster recovery. At the time Wal-E was written barman didn't exist and S3 was one of the few reliable options to backup to (this was over 5 years ago). Since then Wal-E has expanded to include just about every object store you could want, and at the same time 2Q introduced barman as their take on it.

Wal-E has been used for a number of years to provide disaster recovery for Heroku Postgres, for over a million databases. It enables their follow and fork functionality, and we're using it at Citus as well for Citus Cloud given we have the person that authored it.

As for exact differences I'm less familiar as I've not seriously run barman in production so perhaps someone that's run both can chime in.

View on HN

It enables their follow and fork functionality

Doesn't WAL replication only let you restore a full cluster, not a single DB? How do they get around that?

Correct, fork and follow isn't enabled on the multi-tenant level. Well, sort of, for some of the production level plans that are multi-tenant there is still a single Postgres cluster running but multiple of those on a node. Wal-E in those cases running for each one.

It's a shame, though. Having to do WAL replication for DR plus logical backups to enable per-db restores is such a waste :|

The real waste: Wal-e is constantly writing the transaction logs, doesn't matter if there are writes or not.

(Read: a new 10MB file to S3 every 10sec, even when the DB is 100% idle).

That's weird, what's your checkpoint_timeout? The default is 5 minutes, so you certainly shouldn't be pushing to S3 every 10s if the DB is idle.

Apparently PG 10 will improve your use case, though: http://paquier.xyz/postgresql-2/postgres-10-checkpoint-skip/

EDIT: Also, wal-e compresses by default, so even those regular WAL files should be much smaller than 10MB. Are you sure the DB is really idle?

There is a setting for the time interval. That's not the point. I'm not gonna delay replication and backup by minutes just because the replication system sucks. I'd rather pay the storage for my use case.

Compression is enabled indeed. Surprisingly, the compression ratio for "nothing going on" is terrible. (still multiple MBytes).

The next version of postgre will redo the transaction log to have dynamic adaptive sizing, with new settings to control it. Not there yet.

AFAIK the dynamic WAL sizing has already landed in 9.5: http://www.databasesoup.com/2016/01/configuration-changes-in...

Or is this something else you're talking about?

Yes, I'm talking about that and it's in 9.5 (which was released recently)

That sounds like your archive_timeout is set to 10 seconds. (or close, as WAL segments are 16MB pre-compression).

That's the maximum age of a WAL segment before rotation, and Postgres will force the log rotation even if there's no data in the WAL segment.

If you're worried about keeping the last n seconds of data in replication, streaming replication is a far better tactic than log-shipping. (Though log shipping is useful for longer term storage)

Thanks for your insight, I have no clue but will need a backup to pg in the next months, so this helped.

Just came from a nice presentation on the PG backup fundamentals, I highly recommend watching it when the video comes online: https://fosdem.org/2017/schedule/event/postgresql_backup/

The video is online now.

Thanks!

Reply on news.ycombinator.com