PG Phriday: The Bones of High Availability
Well, the bell has tolled, the day is over, and at the end of it all, Postgres Open has ended its fifth year in service of the community. I will say it was certainly an honor to speak again this year, though now that it’s not conveniently in Chicago, I’ll have to work harder to justify hauling myself across the country next year. Of course at this point, I’d feel guilty if I didn’t at least try, assuming any of my submissions are accepted. :)
Given that the conference has ended, I would be remiss if I didn’t post my slides. The official location on the PostgreSQL Wiki is a start, but I have a website, so I might as well use it. So if you want to view my presentation directly, there are two ways:
What was the presentation about? If you believe Gabby’s tweet, it was about puns. That’s not too far from the truth, but the despite my propensity for wordplay, the actual topic focused on—what else—Postgres high availability. By starting the journey with a single server, I discuss how each additional server on the stack can reinforce the (spooky) skeleton of a successful database architecture. In the process I also share a couple of the sobering disasters that probably shaved a few years off of my life due to some level of insufficient paranoia.
High availability really is the result of a cost to benefit analysis between how much downtime costs the company, and the expense of hardware and space in a data center. With Postgres, there are a lot of ways to leverage built-in features and take advantage of its underlying capabilities in avoiding such scenarios. This isn’t like the year I built a DRBD + Pacemaker + Postgres stack live on stage, so don’t be afraid to read through it. If nothing else, the slides are good for a few laughs.
Hope to see you at Postgres Open 2016!