Re: Teaching pg_receivexlog to follow timeline switches
От | Phil Sorber |
---|---|
Тема | Re: Teaching pg_receivexlog to follow timeline switches |
Дата | |
Msg-id | CADAkt-hgE3E+kt6nBnsrXMso=Lu0uDW=omq6R3pwZP2W+oNZBQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Teaching pg_receivexlog to follow timeline switches (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Список | pgsql-hackers |
On Tue, Jan 22, 2013 at 8:33 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Heikki Linnakangas <hlinnakangas@vmware.com> writes: >> You might not want to keep a copy of the whole data directory around, as you >> have to in a cascading standby. I can see value in a separate WAL proxy >> software, especially if it's integrated into a larger backup manager program >> like barman or wal-e. > > +1 > > I somehow forgot about $PGDATA here. Time for a little break I guess :) > > Another idea is to have a daemon mode pg_receivexlog where not only it > can maintain a local archive but also feed it using the replication > protocol to standbies, keeping track of their position. I'm not sure if i described it well, but that's essentially what I was asking about. It would have both wal receiving and and wal sending capability. Along with it's own local WAL storage perhaps governed in size by a keep_wal_segments and also a longer term archive that you could have compressed but also pull from with a archive and restore command. And also be able to act as a synchronous replication peer. I think it has already been discussed to have pg_receivexlog do that last one. So yeah, a cascading standby without $PGDATA or hot_standby or large shared_buffers resources. It seems like maybe we could add through subtraction. Add a parameter that disables wal replay? I'm sure there'd be more things it would have to disable, but then it's not two separate binaries. > > Regards, > -- > Dimitri Fontaine > http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
В списке pgsql-hackers по дате отправления: