Обсуждение: warm standby possible with 8.1?
Dear List Is it possible to have a warm standby with 8.1? I have set up log shipping to standby server but it seems that i cannot make it read any subsequent walfiles except the first one played with initial data.With pg_standy with 8.2+ it is so easy to make it work but I would also like to have a warm standby for this 8.1 server. My set up is to monitor data/ dir for recovery.done. If it is there, stop the server, rename recovery.done to recovery.conf and then start the server. Will this work as a warm standy if recovery.conf contains a restore command? restore_command='cp walfiles/%f %p' Thanks mr.wu
zhong ming wu wrote: > Is it possible to have a warm standby with 8.1? No. You can set that up so that it replays an entire pile of log files sitting there when you start the server, which it sounds like you haven't managed yet because you're trying to treat it like a warm-standby. But 8.1 isn't capable of applying log files one at a time; it applies whatever you've got, and then it's done with recovery and transitions to live. You can't just stop the result and then feed it the next file, as you've already discovered through experimentation. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us
On Tue, Mar 09, 2010 at 05:48:41PM -0500, Greg Smith wrote: > zhong ming wu wrote: > >Is it possible to have a warm standby with 8.1? > > No. You can set that up so that it replays an entire pile of log > files sitting there when you start the server, which it sounds like > you haven't managed yet because you're trying to treat it like a > warm-standby. But 8.1 isn't capable of applying log files one at a > time; it applies whatever you've got, and then it's done with > recovery and transitions to live. You can't just stop the result > and then feed it the next file, as you've already discovered through > experimentation. Guys, I'm afraid there may be some confusion here. I've got a warm standby happily running with simple home-made archive and restore scripts on a legacy Postgresql installation as old as 8.0. And yes, I did failover multiple times (I posted a report or two on that to this list.) What Zhong isn't going to get is converting the master node to a warm standby node as easily as by just stopping it and renaming recovery.done to recovery.conf. The way to go here is to take a file-level DB backup from the master node and bootstrap a new warm standby node from it, then let it catch up with the master node WAL-wise. Yar
On Sun, Mar 28, 2010 at 8:20 PM, Yar Tykhiy <yar@barnet.com.au> wrote: > > Guys, I'm afraid there may be some confusion here. I've got a warm > standby happily running with simple home-made archive and restore > scripts on a legacy Postgresql installation as old as 8.0. And yes, I > did failover multiple times (I posted a report or two on that to this > list.) > > What Zhong isn't going to get is converting the master node to a warm > standby node as easily as by just stopping it and renaming recovery.done > to recovery.conf. The way to go here is to take a file-level DB backup > from the master node and bootstrap a new warm standby node from it, then > let it catch up with the master node WAL-wise. > > Yar > Greg confirmed the capability of 8.1 for me. While I am still sticking with 8.1, I think what I am doing is the same as Yar but I don't completely understand his terminology. What I do is every now and then, existing archive files on standby server are wiped out and the whole data directory on standby server has to refreshed from the master db and WAL starts to accumulate again on the standy server. Two things can force you to refresh like that: 1) archive data on standby server can get very big and you can easily run out of disk space. 2) if you don't want to play lots of wal files and wait a very long time on actual recovery you will need to refresh it. In my case wal files accumulate quickly on standby server because I am also sending fake traffic (as suggested by a website) frequently because I am not supposed to lose no more than five minutes of transaction data.