Re: Fastest way to duplicate a quite large database

Поиск
Список
Период
Сортировка
От Edson Richter
Тема Re: Fastest way to duplicate a quite large database
Дата
Msg-id BLU436-SMTP1786DB83911168A984BCCA3CF960@phx.gbl
обсуждение исходный текст
Ответ на Re: Fastest way to duplicate a quite large database  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: Fastest way to duplicate a quite large database  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: Fastest way to duplicate a quite large database  (CS DBA <cs_dba@consistentstate.com>)
Список pgsql-general
Em 13/04/2016 11:18, Adrian Klaver escreveu:
> On 04/13/2016 06:58 AM, Edson Richter wrote:
>
>>
>>
>> Another trouble I've found: I've used "pg_dump" and "pg_restore" to
>> create the new CustomerTest database in my cluster. Immediately,
>> replication started to replicate the 60Gb data into slave, causing big
>> trouble.
>> Does mark it as "template" avoids replication of that "copied" database?
>> How can I mark a database to "do not replicate"?
>
> With the Postgres built in binary replication you can't, it replicates
> the entire cluster. There are third party solutions that offer that
> choice:
>
> http://www.postgresql.org/docs/9.5/interactive/different-replication-solutions.html
>
>
> Table 25-1. High Availability, Load Balancing, and Replication Feature
> Matrix

Thanks, I'll look at that.

> It has been mentioned before, running a non-production database on the
> same cluster as the production database is a generally not a good
> idea. Per previous suggestions I would host your CustomerTest database
> on another instance/cluster of Postgres listening on a different port.
> Then all you customers have to do is create a connection that points
> at the new port.

Thanks for the concern.
This "CustomerTest" database is a staging, for customer approval before
upgrading the production system.
I bet the users will only open the system, and say it is ok. As crowded
as people are those days, I doubt they will validate something that is
already validated by our development team.
But our contractor requires, and we provide.
Since we have "express devivery of new versions" (almost 2 per week), we
would like to automate the staging environment.

Thanks,

Edson

>
>>
>> Thanks,
>>
>> Edson
>>
>>
>
>



В списке pgsql-general по дате отправления:

Предыдущее
От: Alban Hertroys
Дата:
Сообщение: Re: Why is the comparison between timestamp and date so much slower then between two dates
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: Fastest way to duplicate a quite large database