Hi,
Le 11 août 09 à 07:50, Heikki Linnakangas a écrit :
> >2009/8/11 Robert Haas <robertmhaas@gmail.com>
> > We should probably have a separate discussion about what the least
> > committable unit would be for this patch. I wonder if it might be
> > sufficient to provide a facility for streaming WAL, plus a
> standalone
> > tool for receving it and storing it to a file.
>
> That's an interesting idea. That would essentially be another method
> to set up a WAL archive. I'm not sure it's worthwhile on its own,
> but once we have the wal-sender infrastructure in place it should be
> easy to write such a tool.
Well it might be over engineering time *again* but here's what it
makes me think about:
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.
Now, the archive and restore commands would make a independent
subsystem, the only one (for modularisation sake) allowed to work with
the archives. So we extend it to support sending and receiving
archives to/from a remote PostgreSQL server, using libpq and the
already proposed protocol in the current patch form.
It could be that for integration purpose we'd need something like the
autovacuum launcher, an archive manager daemon child of postmaster
accepting signals in order to spawn a specific tasks. Sender part
could be launched more than once at any time, e.g.
Of course the included automatic and easy to setup daemon wouldn't
care about setting up a remote archiving policy, but on the other hand
a remote PostgreSQL instance could easily be set up as a wal receiver
from the master's archive. The archive retention policy and how it
applies to known list of receivers is to discuss :)
As far as the (a)Sync Rep patch is concerned, this could solve the
setup part of it, this step where starting from a filesystem level
backup you realize you need archived WALs before being able to apply
currently received entries (LSN granularity).
Regards,
--
dim