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
Re: Fastest way to duplicate a quite large database |
Список | 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 по дате отправления: