Best practices for cloning DB servers

From: Andy Lau <alau(at)infer(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Best practices for cloning DB servers
Date: 2014-08-14 02:18:36
Message-ID: CAPnMqr2sx3a_sCmn049nVDze_tTZOtT+=o9B7yBcSuROOJjwKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Patrick Dung 2014-08-14 03:52:39 Trigger function cannot reference field name with capital letter
Previous Message Robin 2014-08-13 18:19:41 Re: Database block lifecycle