On Tue, Nov 10, 2015 at 12:33 PM, Daniel Farina <[email protected]> wrote:
> > Perhaps. The problem is not that something is slow, but rather than > Postgres can't seem to get the crash recovery log it needs to start, and it > cannot do that because it apparently does not exist in S3 (i.e. a 404 > error). > > So check your prefixes and credentials, and possibly cross-verify with a > program like the amazon console or s3cmd or whathaveyou. > Thanks for the response. I was finally able to do a restore, by increasing the timeout in the systemctl postgres script. Here's what I observed: it took awhile, but the postgres systemctl script finally completed. In the pg_log, Postgres was trying to fetch the next log every 10 seconds or so. Interestingly, in the syslog, wal-e was still trying to fetch old wal files in batches, even though Postgres had completed recovery to the present. I was then able to bring up postgres and the database looks complete. What I don't understand is why is it trying to fetch so many missing wal files, and why was it continuing to try to fetch them after Postgres had completed the initial recovery? If I had just done a full backup, there shouldn't be much to recover, and it should not take very long, right? Clearly I'm not understanding something. Any help would be greatly appreciated. Thanks, Mark -- You received this message because you are subscribed to the Google Groups "wal-e" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
