Best practices for cloning DB servers - Mailing list pgsql-general

From Andy Lau
Subject Best practices for cloning DB servers
Date
Msg-id CAPnMqr2sx3a_sCmn049nVDze_tTZOtT+=o9B7yBcSuROOJjwKg@mail.gmail.com
Whole thread Raw
Responses Re: Best practices for cloning DB servers  (Bill Mitchell <bill@publicrelay.com>)
List pgsql-general
Hi everyone,

I had a question about some best practices. Our situation is that we want to be able to clone a database server. Our single database server is hosted in AWS, we take EBS snapshots every so often, and upload our WAL logs to S3. We want to be able to start a new server from a snapshot, replay the WAL logs to get to a specific point in time, then start using the database from there. The problem we ran into here was that this exact clone started uploading WAL logs to our S3 archive, mixing them up with the original WAL logs. Since this is effectively a branch off of the original DB, mixing up the logs is very bad. A solution here could be to just point clones to a different location in S3 so they won't collide, but I was wondering if there were any best practices for doing this.

Also would appreciate any advice on cloning DB servers in general. A few of our use cases include restoring to a previous good DB to experiment while keeping the production DB unaffected, and testing Postgres version upgrades (9.1 to 9.3).

Thanks!
-Andy

pgsql-general by date:

Previous
From: Si Chen
Date:
Subject: is there a way log last query in pg_stat_activity
Next
From: Tom Lane
Date:
Subject: Re: is there a way log last query in pg_stat_activity