Hi!
On 01/03/11 20:56, Tom Lane wrote:
> Scott Ribe<scott_ribe@elevated-dev.com> writes:
>
>> Unless I misread his earlier post, he is starting the backup, copying files, stopping the backup, and expecting
thosetransactions (between start& stop) to be applied, even though files changed during that time (including WAL
files)have not all been copied. Again, unless I misread his earlier post, he is *not* copying WAL that was generated
betweenstart& stop.
>>
> If that's the case, it just plain won't work. You can either shut down
> the postmaster and copy a static set of files, or you can apply WAL to a
> base backup that was taken from a live database. There is no way to get
> consistent results from a backup of a live database without applying all
> the WAL that was generated while the backup was being taken.
>
> regards, tom lane
>
First of all, thanks for your time dealing with my situation. I must
stress that i have wal arhived starting from before issuing
pg_start_backup, wal archives generated before pg_start/stop_backup and
also some wal archive files generated after pg_stop_backup (and
permissions are ok). But for some reason my replay starts exactly where
.backup file says 'stop wal location', referring to my earlier post
STOP WAL LOCATION: 1/6325B2E0 (file 000000010000000100000063)
I am starting to think more in the direction what Kevin Grittner
suggested that i miss something in my procedure and instead following so
to say recovery path i am doing something else which strangely ends up
with working database process but actually misses some data. I really
tried to write down all the steps i take in my first mail, maybe you
could say something based on that or i could do some additional checking
(with pg_controldata or the like) before starting database in wal-replay
mode. In the meantime a try to read thru manual once more and try out
streaming replication, hope it advances my general understanding of the
process and helps in solving the current problem.
Best regards,
Imre
