| From: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
|---|---|
| To: | "Phil Monroe *EXTERN*" <phil(at)identified(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
| Cc: | Infrastructure <infrastructure(at)identified(dot)com>, Vladimir Giverts <vlad(at)identified(dot)com>, Tejas <tejas(at)identified(dot)com>, Sasha Kipervarg <sasha(at)identified(dot)com> |
| Subject: | Re: Postgres WAL Recovery Fails... And Then Works... |
| Date: | 2013-01-15 08:17:29 |
| Message-ID: | A737B7A37273E048B164557ADEF4A58B0579983E@ntex2010a.host.magwien.gv.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Phil Monroe wrote:
> So we had to failover and do a full base backup to get our slave database back online and ran into a
> interesting scenario. After copying the data directory, setting up the recovery.conf, and starting the
> slave database, the database crashes while replaying xlogs. However, trying to start the database
> again, the database is able to replay xlogs farther than it initially got, but ultimately ended up
> failing out again. After starting the DB a third time, PostgreSQL replays even further and catches up
> to the master to start streaming replication. Is this common and or acceptable?
Certainly not acceptable.
Just checking: When you were "copying the data directory",
did you have online backup mode enabled?
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Albe Laurenz | 2013-01-15 08:42:32 | Re: Casting bytea to varchar |
| Previous Message | Vinod V | 2013-01-15 06:23:37 | Need assistance in incremental backup for my environment |