Re: dropdb breaks replication? - Mailing list pgsql-general

From Edson Richter
Subject Re: dropdb breaks replication?
Date
Msg-id BLU0-SMTP11405A8FAD2DDF8D75103BDCF610@phx.gbl
Whole thread Raw
In response to Re: dropdb breaks replication?  (Lonni J Friedman <netllama@gmail.com>)
Responses Re: dropdb breaks replication?  (John R Pierce <pierce@hogranch.com>)
List pgsql-general
Em 31/10/2012 16:09, Lonni J Friedman escreveu:
> 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.
>
>
Sorry for the portguese text. Yes, your assumption is correct: WAL
segment has been excluded before being able to replicate.
I keep 80 WAL segments, but I was wondering if a drop database is being
logged: it's just so fast, I thought it wasn't logged.
And what is the purpose to log (and replicate) the database drop, if you
will not be able to recover it - IMHO, dropdb should be replicated as
"database deactivation" or something more or like that...

Edson




pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: dropdb breaks replication?
Next
From: Edson Richter
Date:
Subject: Re: dropdb breaks replication?