Re: psql: FATAL: the database system is starting up
От | Adrian Klaver |
---|---|
Тема | Re: psql: FATAL: the database system is starting up |
Дата | |
Msg-id | 2a8309a5-df17-cb8b-840c-278f2d0ac422@aklaver.com обсуждение исходный текст |
Ответ на | Re: psql: FATAL: the database system is starting up (Tom K <tomkcpr@gmail.com>) |
Ответы |
Re: psql: FATAL: the database system is starting up
|
Список | pgsql-general |
On 6/1/19 5:21 PM, Tom K wrote: > > > On Sat, Jun 1, 2019 at 7:34 PM Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.com>> wrote: > > On 6/1/19 4:22 PM, Tom K wrote: > > > > > > > > > Looks like this crash was far more catastrophic then I thought. > By the > > looks of things, thinking on psql02 would be my best bet. > > > > The more I look at it the more I think the replication was not doing > what you thought it was doing. That psql02 was the primary and that > psql01 and psql03 where out of sync and/or defunct standbys. > > > Now that I look at the files myself, that's the conclusion I was coming > to myself. Sample config: The below would be for someone that uses and understands Patroni. That would not be me:) > > [root@psql02 base]# cat /etc/patroni.yml > scope: postgres > namespace: /db/ > name: postgresql1 > > restapi: > listen: 192.168.0.124:8008 <http://192.168.0.124:8008> > connect_address: 192.168.0.124:8008 <http://192.168.0.124:8008> > > Or perhaps when the system crashed, the filesystem check simply moved > the folders out due to corruption. That would leave the cluster in an inconsistent state and you would not have been able to start the one you got going. -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: