Re: dropdb breaks replication?
От | Edson Richter |
---|---|
Тема | Re: dropdb breaks replication? |
Дата | |
Msg-id | BLU0-SMTP854446346D78C263C33DE6CF610@phx.gbl обсуждение исходный текст |
Ответ на | Re: dropdb breaks replication? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Em 31/10/2012 16:34, Tom Lane escreveu: > Lonni J Friedman <netllama@gmail.com> writes: >> On Wed, Oct 31, 2012 at 11:01 AM, Edson Richter >> <edsonrichter@hotmail.com> wrote: >>> 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. > dropdb generates one, not very large, WAL record saying "go rm -rf this > directory". So sheer WAL volume is not the correct explanation. It's > possible though that the slave spent long enough executing the rm -rf > to fall behind the master. Your assumption is right: the slave server is a slow mono processor, low memory, cloud computer, and would have taken very long time to delete everything. > > In any case, it should have been able to catch up automatically if WAL > archiving was configured properly. I don't use WAL archiving - both servers are miles away from each other, and don't have anything except PostgreSQL async replication over VPN connecting them. Edson > > regards, tom lane > >
В списке pgsql-general по дате отправления: