Обсуждение: BUG #7549: max_connections check should query master when starting standby
BUG #7549: max_connections check should query master when starting standby
От
petsku@petteriraty.eu
Дата:
The following bug has been logged on the website: Bug reference: 7549 Logged by: Petteri R=C3=A4ty Email address: petsku@petteriraty.eu PostgreSQL version: 9.2.0 Operating system: Linux or OS X Description: = On a streaming hot standby slave starting postgres: LOG: database system was interrupted while in recovery at log time 2012-09-17 21:29:31 EEST HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. LOG: entering standby mode FATAL: hot standby is not possible because max_connections =3D 20 is a low= er setting than on the master server (its value was 100) LOG: startup process (PID 51494) exited with exit code 1 LOG: aborting startup due to startup process failure It was indeed the case that the limit was lower on the slave but to resolve it I lowered the setting on the master: postgres=3D# SHOW max_connections; max_connections = ----------------- 20 (1 row) The slave should allow resolving the issue by not only changes on the slave side but by checking if the master has been updated as well. Regards, Petteri
On Tue, Sep 18, 2012 at 3:51 AM, <petsku@petteriraty.eu> wrote: > The following bug has been logged on the website: > > Bug reference: 7549 > Logged by: Petteri R=E4ty > Email address: petsku@petteriraty.eu > PostgreSQL version: 9.2.0 > Operating system: Linux or OS X > Description: > > On a streaming hot standby slave starting postgres: > > > LOG: database system was interrupted while in recovery at log time > 2012-09-17 21:29:31 EEST > HINT: If this has occurred more than once some data might be corrupted a= nd > you might need to choose an earlier recovery target. > LOG: entering standby mode > FATAL: hot standby is not possible because max_connections =3D 20 is a l= ower > setting than on the master server (its value was 100) > LOG: startup process (PID 51494) exited with exit code 1 > LOG: aborting startup due to startup process failure > > It was indeed the case that the limit was lower on the slave but to resol= ve > it I lowered the setting on the master: > > postgres=3D# SHOW max_connections; > max_connections > ----------------- > 20 > (1 row) > > The slave should allow resolving the issue by not only changes on the sla= ve > side but by checking if the master has been updated as well. If you change the max_connections on the master, you need to take a fresh backup from the master and start the standby from it. Regards, --=20 Fujii Masao
Re: BUG #7549: max_connections check should query master when starting standby
От
Petteri Räty
Дата:
On 17.9.2012 16.57, Fujii Masao wrote: > On Tue, Sep 18, 2012 at 3:51 AM, <petsku@petteriraty.eu> wrote: >> The following bug has been logged on the website: >> >> Bug reference: 7549 >> Logged by: Petteri Räty >> Email address: petsku@petteriraty.eu >> PostgreSQL version: 9.2.0 >> Operating system: Linux or OS X >> Description: >> >> On a streaming hot standby slave starting postgres: >> >> >> LOG: database system was interrupted while in recovery at log time >> 2012-09-17 21:29:31 EEST >> HINT: If this has occurred more than once some data might be corrupted and >> you might need to choose an earlier recovery target. >> LOG: entering standby mode >> FATAL: hot standby is not possible because max_connections = 20 is a lower >> setting than on the master server (its value was 100) >> LOG: startup process (PID 51494) exited with exit code 1 >> LOG: aborting startup due to startup process failure >> >> It was indeed the case that the limit was lower on the slave but to resolve >> it I lowered the setting on the master: >> >> postgres=# SHOW max_connections; >> max_connections >> ----------------- >> 20 >> (1 row) >> >> The slave should allow resolving the issue by not only changes on the slave >> side but by checking if the master has been updated as well. > > If you change the max_connections on the master, you need to take a > fresh backup from the master and start the standby from it. > > Regards, > If that's the case then would make sense to document it in connection to the output. I wouldn't have guessed that to be the case. Regards, Petteri
Re: BUG #7549: max_connections check should query master when starting standby
От
Craig Ringer
Дата:
On 09/18/2012 07:57 AM, Fujii Masao wrote: > If you change the max_connections on the master, you need to take a > fresh backup from the master and start the standby from it. WTF, really? What else breaks the replication and forces a re-clone? -- Craig Ringer
Re: BUG #7549: max_connections check should query master when starting standby
От
Heikki Linnakangas
Дата:
On 18.09.2012 09:46, Craig Ringer wrote: > On 09/18/2012 07:57 AM, Fujii Masao wrote: >> If you change the max_connections on the master, you need to take a >> fresh backup from the master and start the standby from it. > > WTF, really? No. It's enough to bump up max_connections on the standby, and restart. - Heikki
On Mon, Sep 17, 2012 at 11:46 PM, Craig Ringer <ringerc@ringerc.id.au>wrote: > On 09/18/2012 07:57 AM, Fujii Masao wrote: > >> If you change the max_connections on the master, you need to take a >> fresh backup from the master and start the standby from it. >> > > WTF, really? > > What else breaks the replication and forces a re-clone? > > Another WTF from me too. I can understand moving from read-only to read-write, but internally *why* does this happen? If it is the case, it needs to be clearly documented. (mental note to test this and report back). Why would this create a different timeline? Best Wishes, Chris Travers
On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > On 18.09.2012 09:46, Craig Ringer wrote: >> >> On 09/18/2012 07:57 AM, Fujii Masao wrote: >>> >>> If you change the max_connections on the master, you need to take a >>> fresh backup from the master and start the standby from it. >> >> >> WTF, really? > > > No. It's enough to bump up max_connections on the standby, and restart. Hmm... Petteri wants to solve the issue without changing anything on the standby, according to his original post. So in his case, a fresh backup is required. Of course my previous answer was confusing... Regards, -- Fujii Masao
Re: BUG #7549: max_connections check should query master when starting standby
От
Bruce Momjian
Дата:
On Tue, Sep 18, 2012 at 09:09:13PM +0900, Fujii Masao wrote: > On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: > > On 18.09.2012 09:46, Craig Ringer wrote: > >> > >> On 09/18/2012 07:57 AM, Fujii Masao wrote: > >>> > >>> If you change the max_connections on the master, you need to take a > >>> fresh backup from the master and start the standby from it. > >> > >> > >> WTF, really? > > > > > > No. It's enough to bump up max_connections on the standby, and restart. > > Hmm... Petteri wants to solve the issue without changing anything > on the standby, according to his original post. So in his case, a fresh > backup is required. > > Of course my previous answer was confusing... I assume you mean the slave needs an updated copy of the master's config file changes, not an entire copy of the data directory. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +