Parameter name standby_mode
in [PgSql]
|
Prev: pgsql: Make standby server continuously retry restoringthe next WAL
Next: pg_restore --single-transaction and --clean
From: Heikki Linnakangas on 11 Feb 2010 07:20 Simon Riggs wrote: > The docs say "If this parameter is on, the streaming replication is > enabled". So who is wrong? The docs. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 11 Feb 2010 20:29 On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > If they want to implement the warm standby using the (new) built-in > logic to keep retrying restore_command, they would set > standby_mode='on'. standby_mode='on' doesn't imply streaming replication. But if we fail in restoring the archived WAL file, "standby_mode = on" *always* tries to start streaming replication. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 12 Feb 2010 02:04 Fujii Masao wrote: > On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> Fujii Masao wrote: >>> But if we fail in restoring the archived WAL file, "standby_mode = on" >>> *always* tries to start streaming replication. >> Hmm, somehow I thought it doesn't if you don't set primary_conninfo. I >> think that's the way it should work, ie. if primary_conninfo is not set, >> don't launch walreceiver but just keep trying to restore from the archive. > > Yeah, even if primary_conninfo is not given, the standby tries to invoke > walreceiver by using the another connection settings (environment variables > or defaults). This is intentional behavior, and would make the setup of SR > easier. So I'd like to leave it be. You could do primary_conninfo='' for that. Maybe we should have two options, "streaming_mode='on'" and "primary_conninfo='...'". -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 12 Feb 2010 01:28 On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Fujii Masao wrote: >> On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas >> <heikki.linnakangas(a)enterprisedb.com> wrote: >>> If they want to implement the warm standby using the (new) built-in >>> logic to keep retrying restore_command, they would set >>> standby_mode='on'. standby_mode='on' doesn't imply streaming replication. >> >> But if we fail in restoring the archived WAL file, "standby_mode = on" >> *always* tries to start streaming replication. > > Hmm, somehow I thought it doesn't if you don't set primary_conninfo. I > think that's the way it should work, ie. if primary_conninfo is not set, > don't launch walreceiver but just keep trying to restore from the archive. Yeah, even if primary_conninfo is not given, the standby tries to invoke walreceiver by using the another connection settings (environment variables or defaults). This is intentional behavior, and would make the setup of SR easier. So I'd like to leave it be. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 12 Feb 2010 05:09
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > There's yet another mode that would be useful with hot standby: start up > the standby, but don't poll the archive and don't try to connect to the > master. Kind of 'paused' mode. Simon had functions to do that and more > in the original hot standby patch. And having the pause/resume functions would lower the need for perfect conflict resolution too. When you want to run this huge reporting query set and not get interrupted, pause the standby. Afterward, resume it. Of course, while paused, it's not a good HA standby anymore, but you just did pause it, so you're not surprised, right? > I've been thinking that this would work with just the three options we > have now: I like that, because it exposes exactly the code logic, and it is not complex enough to merit being hidden from the users. Also, you depend on understanding how the server really works to setup a trustworthy HA solution, so exposing the very used concepts is a win. > primary_conninfo (string) specifies a connection string to use to > connect to the master. If not given, don't try to connect. Would it be possible to expose that at the SQL level, so that you can easily check in scripts what master you're a slave of? Think nagios cascading alerts or topology graphs, etc. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |