Re: Fastest way to duplicate a quite large database
От | CS DBA |
---|---|
Тема | Re: Fastest way to duplicate a quite large database |
Дата | |
Msg-id | 570E5F1E.5030107@consistentstate.com обсуждение исходный текст |
Ответ на | Re: Fastest way to duplicate a quite large database (Edson Richter <edsonrichter@hotmail.com>) |
Список | pgsql-general |
On 04/13/2016 08:46 AM, Edson Richter wrote: > 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 >>> >>> >> >> > > > Have you tried this: - to copy database named prod to a database named prod_test: on the same cluster (same server): pg_dump prod --create --clean| psql prod_test Copy from prod db cluster to another cluster/server (i.e. the test server) pg_dump prod --create --clean| psql -h [test_server_ip] prod_test
В списке pgsql-general по дате отправления: