Best practices for cloning DB servers

Поиск
Список
Период
Сортировка
От Andy Lau
Тема Best practices for cloning DB servers
Дата
Msg-id CAPnMqr2sx3a_sCmn049nVDze_tTZOtT+=o9B7yBcSuROOJjwKg@mail.gmail.com
обсуждение исходный текст
Ответы Re: Best practices for cloning DB servers
Список 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 по дате отправления:

Предыдущее
От: Si Chen
Дата:
Сообщение: is there a way log last query in pg_stat_activity
Следующее
От: Tom Lane
Дата:
Сообщение: Re: is there a way log last query in pg_stat_activity