Em 31/10/2012 16:09, Lonni J Friedman escreveu:
On Wed, Oct 31, 2012 at 11:01 AM, Edson Richter
<edsonrichter@xxxxxxxxxxx> wrote:
Em 31/10/2012 15:39, Lonni J Friedman escreveu:
On Wed, Oct 31, 2012 at 10:32 AM, Edson Richter
<edsonrichter@xxxxxxxxxxx> 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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
