Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing WAL-G: Faster Disaster Recovery for Postgres

citusdata.com

Post reply on HN
Print view View original

11–20 of 66 posts

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#11

Post by ocharles »

tyingq wrote: post #8
sehrope wrote: post #3

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…

Every time I saw that mentioned, my mind goes to the movie. https://g.co/kgs/d8G9u5

I don't think it's a coincidence WAL-E is named as it is :)

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#13

Post by upbeatlinux »

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.

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#15

Post by andrewstuart2 »

bgentry wrote: post #10
kafkes wrote: post #2

Hello everyone, I'm the primary author for WAL-G and would be happy to answer any questions.

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.

Nor would many choose to, given the opportunity. Way to pick an interesting and challenging project! :-)

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#18

Post by kafkes »

brianwawok wrote: post #14
kafkes wrote: post #2

Hello everyone, I'm the primary author for WAL-G and would be happy to answer any questions.

Is this production ready, or just an early dev snapshot?

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.

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#19

Post by craigkerstiens »

brianwawok wrote: post #14
kafkes wrote: post #2

Hello everyone, I'm the primary author for WAL-G and would be happy to answer any questions.

Is this production ready, or just an early dev snapshot?

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.

Re: Introducing WAL-G: Faster Disaster Recovery for Postgres

#20

Post by drob »

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!

Post reply on HN