Re: dropdb breaks replication?

Поиск
Список
Период
Сортировка
От Lonni J Friedman
Тема Re: dropdb breaks replication?
Дата
Msg-id CAP=oouH49F999iJoth-W=vL15Nd8hi0dMXrMUdkjxuGxj2xUiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: dropdb breaks replication?  (Edson Richter <edsonrichter@hotmail.com>)
Ответы Re: dropdb breaks replication?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: dropdb breaks replication?  (Edson Richter <edsonrichter@hotmail.com>)
Список pgsql-general
On Wed, Oct 31, 2012 at 11:01 AM, Edson Richter
<edsonrichter@hotmail.com> wrote:
> Em 31/10/2012 15:39, Lonni J Friedman escreveu:
>>
>> On Wed, Oct 31, 2012 at 10:32 AM, Edson Richter
>> <edsonrichter@hotmail.com> wrote:
>>>
>>> I've two PostgreSQL 9.1.6 running on Linux CentOS 5.8 64bit.
>>> They are replicated asynchronously.
>>>
>>> Yesterday, I've dropped a database of 20Gb, and then replication has
>>> broken,
>>> requiring me to manually synchronize both servers again.
>>>
>>> It is expected that dropdb (or, perhaps, createdb) break existing
>>> replication between servers?
>>
>> How did you determine that replication was broken, and how did you
>> manually synchronize the servers?  Are you certain that replication
>> was working prior to dropping the database?
>>
>>
> I'm sure replication was running.
> I usually keep two windows open in both servers, running
>
> In master:
>
> watch -n 2 "ps aux | egrep sender"
>
> In slave:
>
> watch -n 2 "ps aux | egrep receiver"
>
>
> At the point the dropdb command has been executed, both disappeared from my
> "radar".
> Also, in the log there is the following error:
>
> LOG:  replicação em fluxo conectou-se com sucesso ao servidor principal
> FATAL:  não pôde receber dados do fluxo do WAL: FATAL:  segmento do WAL
> solicitado 0000000100000001000000BE já foi removido
>
>
> May the cause not having enough segments (currently 80) for dropdb command?
> Is dropdb logged in transaction log page-by-page excluded?

I can't read portugese(?), but i think the gist of the error is that
the WAL segment was already removed before the slave could consume it.
 I'm guessing that you aren't keeping enough of them, and dropping the
database generated a huge volume which flushed out the old ones before
they could get consumed by your slave.


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

Предыдущее
От: Raghavendra
Дата:
Сообщение: Re: Boolean type storage format
Следующее
От: Mike Christensen
Дата:
Сообщение: Re: Boolean type storage format