Standby promotion does not work

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Standby promotion does not work
Дата
Msg-id 4DA21789.2090403@agliodbs.com
обсуждение исходный текст
Список pgsql-hackers
All,

So I've finally been able to do some testing, and I'll report that
currently there is way I've found to get existing standbys to subscribe
to a new master.

No matter what I do in recovery.conf, it results in errors and failure
to replicate.

Test setup:hosts: master1, master2, replica1replica1 and master2 are subscribed to master1

First, master1 is shut down.
Second, master 2 is promoted via "pg_ctl promote"

So, original recovery.conf on replica1:

#autogenerated recovery.conf file.  do not edit


standby_mode          = 'on'
primary_conninfo      = 'host=master1 port=5432 user=replication'
trigger_file = '/var/log/pgpool/trigger/trigger_file1'
restore_command = 'scp master1:/usr/local/pgsql/wal_share/%f %p'
recovery_target_timeline = 'latest'

This is changed to:

#autogenerated recovery.conf file.  do not edit


standby_mode          = 'on'
primary_conninfo      = 'host=master1 port=5432 user=replication'
trigger_file = '/var/log/pgpool/trigger/trigger_file1'
restore_command = 'scp master1:/usr/local/pgsql/wal_share/%f %p'
recovery_target_timeline = 'latest'

On restart of replica1, I get the following error:

2011-04-10 13:27:24.766 PDT,,,2867,,4da212ac.b33,1,,2011-04-10 13:27:24
PDT,,0,FATAL,XX000,"timeline 2 of the primary does not match recovery
target timeline 1",,,,,,,,,""
2011-04-10 13:27:29.875 PDT,,,2878,,4da212b1.b3e,1,,2011-04-10 13:27:29
PDT,,0,FATAL,XX000,"timeline 2 of the primary does not match recovery
target timeline 1",,,,,,,,,""

If I try to manually change the timeline in recovery.conf to '2', I get:

2011-04-10 13:23:05.115 PDT,,,2834,,4da211a9.b12,2,,2011-04-10 13:23:05
PDT,,0,FATAL,XX000,"recovery target timeline 2 does not exist",,,,,,,,,""
2011-04-10 13:23:05.116 PDT,,,2832,,4da211a8.b10,1,,2011-04-10 13:23:04
PDT,,0,LOG,00000,"startup process (PID 2834) exited with exit code
1",,,,,,,,,""
2011-04-10 13:23:05.116 PDT,,,2832,,4da211a8.b10,2,,2011-04-10 13:23:04
PDT,,0,LOG,00000,"aborting startup due to startup process
failure",,,,,,,,,""

Receive location on master2:
0/93000078

Receive location on replica1:
0/93000000

... and in any case, this is a test system with no activity.  So there's
no way we can replica1 be ahead.

So it seems like we still don't have any way to promote an existing
standby to a new master.  Is this fixable?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: BUG #5856: pg_attribute.attinhcount is not correct.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Teaching regex operators about collations