GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-08-18) - page 1 of 10
 
___________________________________________________________________
Introducing WAL-G: Faster Disaster Recovery for Postgres
115 points by craigkerstiens
https://www.citusdata.com/blog/2017/08/18/introducing-wal-g-fast...
___________________________________________________________________
 
craigkerstiens - 4 hours ago
For those interested in the repo directly to give it a try you can
find it here: https://github.com/wal-g/wal-g
 
upbeatlinux - 4 hours ago
Wow, great work! I am definitely going to test this out over the
weekend. However AFAICT the `aws.Config` approach breaks certain
backwards compatibility w/how wal-e handles credentials. Also wal-g
does not currently support encryption. FWIW, I would love to simply
drop-in wal-g without having to make any configuration changes.
 
  fdr - 1 hours ago
  Do you want GPG based or some other client side encryption, or
  S3's encryption support? The latter could probably just be turned
  on. The former is a feature requiring code.
 
    upbeatlinux - 8 minutes ago
    Ideally the presence of the `WALE_GPG_KEY_ID` env var should
    enable encrypted backups
    https://github.com/wal-e/wal-e#encryption.Put differently to be
    a "successor" it needs to be a drop in replacement ;)
 
mephitix - 4 hours ago
Fantastic intern project, and fantastic work by the intern!
 
jfkw - 3 hours ago
Will WAL-G eventually support the same archive targets as WAL-E (S3
and work-alikes, Azure Blob Store, Google Storage, Swift, File
System)?
 
  fdr - 2 hours ago
  As I'm probably the steward on this going forward: unknown. I
  don't intend to implement them unless I need them. Would I take a
  patch with good coverage that implemented those.
 
kafkes - 5 hours ago
Hello everyone, I'm the primary author for WAL-G and would be happy
to answer any questions.
 
  sehrope - 4 hours ago
  What's the min version of the Postgres server this can be used
  with?
 
    kafkes - 4 hours ago
    WAL-G uses non-exclusive backups so at least 9.6
 
  brianwawok - 4 hours ago
  Is this production ready, or just an early dev snapshot?
 
    kafkes - 4 hours ago
    WAL-G is not yet production ready, but it has been used in a
    staging environment for the past few weeks without any issues.
    Once fdr adds parallel WAL support, he plans to take it into
    production.
 
      brianwawok - 3 hours ago
      Cool cool.is google cloud storage on the roadmap?
 
        fdr - 2 hours ago
        I answered this question in a couple of other places, but:
        unknown because I don't have use for that yet.
        https://news.ycombinator.com/item?id=15049527
 
    craigkerstiens - 3 hours ago
    We've currently been testing it at Citus, but have not flipped
    it to be live for our disaster recovery yet.We're going to
    start rolling it out for Forks/point-in-time recoveries first,
    which present less risk to start. Later we'll explore either
    parallel restores from WAL-E and WAL-G or possibly just flip
    the switch based on the results.On restoration there's really
    no risk to data. Further we page our on call for any issues
    that happen such as WAL not progressing, or servers not coming
    online out of restore.
 
  ngrilly - 1 hours ago
  Thanks! Does WAL-G provides some kind of "continuous backup"
  where changes committed to the database are continuously streamed
  to the backup storage? Or does it work "step by step", for
  example by backing up every 5 minutes or every 10 MB?
 
    andruby - 19 minutes ago
    It does continuous backup like WAL-E.Both back up PG's WAL
    files (Write Ahead Log) and allow restoring your database state
    as it was at a specific time or after a specific transaction
    committed. This is known as point-in-time recovery (PITR)
    [0]Users and admins make mistakes, and accidentally delete or
    overwrite data. With PITR you can restore in a new environment,
    just before the mistake occurred and recover the data from
    there.[0] https://www.postgresql.org/docs/9.6/static
    /continuous-archiv...
 
  bluetech - 2 hours ago
  It would be nice if you could sign the tarball with the binary. I
  see the tag is already signed so hopefully it's not much trouble:
  https://wiki.debian.org/Creating%20signed%20GitHub%20release...
 
    kafkes - 2 hours ago
    Done.
 
  bgentry - 4 hours ago
  Seriously awesome work on this! I was expecting some solid
  improvement when I heard you were rewriting this in Go, but this
  is beyond what I could have expected. 7x improvement on high end
  instance types!Also, what an impressive project to have on the
  resume as a college intern. I don't think many interns get to
  tackle something so meaningful.
 
    andrewstuart2 - 4 hours ago
    Nor would many choose to, given the opportunity. Way to pick an
    interesting and challenging project! :-)
 
  trojanowski - 4 hours ago
  Do you have plans to support encrypted backups?
 
    fdr - 1 hours ago
    Maybe. Depends what you mean by that:
    https://news.ycombinator.com/item?id=15049691
 
  ocharles - 4 hours ago
  Can you elaborate on how much automated testing is behind this?
  When it comes to backup tools, I am very cautious.
 
    kafkes - 3 hours ago
    WAL-G has a number of unit tests, and has been tested manually
    in a staging environment for a number of weeks without issues.
    We are looking to implement more integration tests in the
    future.
 
  patrick_vbn - 2 hours ago
  Any plans to support backup to Google Cloud Storage instead of
  just S3?
 
    timdorr - 2 hours ago
    Or some sort of pluggable storage system.For now, since I'm
    also on GCP, I'm using PGHoard: https://github.com/ohmu/pghoard
 
      fdr - 2 hours ago
      Unknown, but I don't have an immediate plan to implement
      them: https://news.ycombinator.com/item?id=15049527
 
  whitepoplar - 4 hours ago
  Thanks for making this! To someone who's unfamiliar with Postgres
  tooling, what's the difference between WAL-G and Barman? What're
  the advantages of using one over the other?
 
    ibotty - 2 hours ago
    WAL-G (and WAL-E) are expected to run next to the main
    database, while barman is to be run on a separate machine.
    Barman can also backup many databases. It is essentially the
    difference between a central backup service and local backups.
 
    fdr - 4 hours ago
    I was kafkes's guide on this project, and the WAL-E author and
    maintainer...I'd say the differences between WAL-G and Barman
    are similar to WAL-E and Barman, which comes up relatively
    frequently. https://news.ycombinator.com/item?id=13573481In
    summary, WAL-E is simpler program all around that focuses on
    cloud storage, barman does more around inventories of backups
    and file-based backups and configuring Postgres. There are
    integrative downsides to its span. WAL-E also happens to
    predate Barman.
 
sehrope - 5 hours ago
I've used WAL-E (the predecessor of this) for backing up Postgres's
DB for years and it's been a very pleasant experience. From what
I've read so far this looks like it's superior in every way. Lower
resource usage, faster operation, and the switch to Go for WAL-G
(v.s. Python for WAL-E) means no more mucking with Python versions
either.Great job to everybody that's working on this. I'm looking
forward to trying it out.
 
  mylons - 1 hours ago
  python versioning can be a bitch, but
  virtualenv/virtualenvwrapper make 99.999999% of the problems go
  away.i have a huge ETL pipeline at twitch that relies heavily on
  wal-e, and installs it on worker nodes and things like that.that
  being said, if WAL-G is faster, i don't care waht it is written
  in, and am happy to use it
 
  tyingq - 4 hours ago
  Every time I saw that mentioned, my mind goes to the movie.
  https://g.co/kgs/d8G9u5
 
    ocharles - 4 hours ago
    I don't think it's a coincidence WAL-E is named as it is :)
 
drob - 3 hours ago
This is great. Can't wait to be using it.We've been using WAL-E for
years and this looks like a big improvement. The steady, high
throughput is a big deal ? our prod base backups take 36 hours to
restore, so if the recovery speed improvements are as advertised,
that's a big win. In the kind of situation in which we'd be using
these, the difference between 9 hours and 36 hours is major.Also,
the quality of life improvements are great. Despite deploying WAL-E
for years, we _still_ have problems with python, pip, dependencies,
etc, so the switch to go is a welcome one. The backup_label issue
has bitten us a half dozen times, and every time it's very scary
for whoever is on-call.  (The right thing to do is to rm a file in
the database's main folder, so it's appropriately terrifying.) So
switching to the new non-exclusive backups will also be great.We're
on 9.5 at the moment but will be upgrading to 10 after it comes
out. Looking forward to testing this out. Awesome work!
 
  ozgune - 2 hours ago
  Hey Dan, nice to hear from you!> our prod base backups take 36
  hours to restore, so if the recovery speed improvements are as
  advertised, that's a big win.Yes, if you attach 16TB of storage
  to each instance, your back-up restores may take a while. :))
 
    paulsutter - 16 minutes ago
    Is it possible to run a continuous restore in parallel with
    normal operation so that there's a warm standby (almost) ready
    to go? Especially in another data center?
 
  humanfromearth - 2 hours ago
  Same here, perf is obviously great, but no more crazy
  dependencies is just great! So much time I wasted trying to make
  it fit into a docker container.
 
jarym - 3 hours ago
"WAL-E compresses using lzop as a separate process, as well as the
command cat to prevent disk I/O from blocking."Good to see people
sticking to the unix philosophy of doing one thing well and
delegating other concerns - cat and lzop are both fine choices!
 
  wmf - 3 hours ago
  I don't know if you're being sarcastic, because the point of the
  article is that the Unix philosophy was a performance bottleneck
  and they replaced all the Unixy stuff with Go libraries.