Re: Simplifying "standby mode"
От | Simon Riggs |
---|---|
Тема | Re: Simplifying "standby mode" |
Дата | |
Msg-id | 1154964679.2570.78.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Simplifying "standby mode" (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Simplifying "standby mode"
|
Список | pgsql-hackers |
On Mon, 2006-08-07 at 09:48 -0400, Tom Lane wrote: > I'm in process of reviewing the restartable-recovery patch, > http://archives.postgresql.org/pgsql-patches/2006-07/msg00356.php > and I'm wondering if we really need to invent a "standby mode" boolean > to get the right behavior. The problem I see with that flag is that > it'd be static over a run, whereas the behavior we want is dynamic. > It seems entirely likely that a slave will be started from a base backup > that isn't quite current, and will need to run through some archived WAL > segments quickly before it catches up to the master. So during the > catchup period we'd prefer that it not do restartpoints one-for-one > with the logged checkpoints, whereas after it's caught up, that's what > we want. That's a great observation. It also ties in neatly with the last piece of function I've been trying to add. Let's have it run at full speed, i.e. restartpoint every 100 checkpoints up until we hit end-of-logs, then if we are not in standby_mode the recovery will just end. [Also: Currently, we do not retry a request for a archive file during recovery, though for balance with archive we should retry 3 times.] If we are in standby mode, then rather than ending recovery we go into a wait loop. We poll for the next file, then sleep for 1000 ms, then poll again. When a file arrives we mark a restartpoint each checkpoint. We need the standby_mode to signify the difference in behaviour at end-of-logs, but we may not need a parameter of that exact name. The piece I have been puzzling over is how to initiate a failover when in standby_mode. I've not come up with a better solution than checking for the existence of a trigger file each time round the next-file wait loop. This would use a naming convention to indicate the port number, allowing us to uniquely identify a cluster on any single server. That's about as portable and generic as you'll get. We could replace the standby_mode with a single parameter to indicate where the trigger file should be located. This is then the last piece in the standby server puzzle. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: