Re: Hot standby and synchronous replication status
От | Greg Smith |
---|---|
Тема | Re: Hot standby and synchronous replication status |
Дата | |
Msg-id | alpine.GSO.2.01.0908130330110.13251@westnet.com обсуждение исходный текст |
Ответ на | Re: Hot standby and synchronous replication status (Dimitri Fontaine <dfontaine@hi-media.com>) |
Список | pgsql-hackers |
On Tue, 11 Aug 2009, Dimitri Fontaine wrote: > We should somehow provide a default archive and restore command integrated > into the main product, so that it's as easy as turning it 'on' in the > configuration for users to have something trustworthy: PostgreSQL will keep > past logs into a pg_xlog/archives subdir or some other default place, and > will know about the setup at startup time when/if needed. Wandering a little off topic here because this plan reminded me of something else I've been meaning to improve...while most use-cases require some sort of network transport for this to be useful, there is one obvious situation where it would be great to have a ready to roll setup by default. Right now, if people want to make a filesystem level background of their database, they first have to grapple with setting up the archive command to do so. If the system were shipped in a way that made that trivial to active, perhaps using something like what you describe here, that would reduce the complaints that PostgreSQL doesn't have any easy way to grab a filesystem hotcopy of the database. Those rightly pop up sometimes, and it would be great if the procedure were reduced to: 1) Enable archiving 2) pg_start_backup 3) rsync/tar/cpio/copy/etc. 4) pg_stop_backup 5) Disable archiving Because the default archive_command was something that supported a filesystem snapshot using a standard layout. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: