On Tue, Nov 10, 2015 at 2:00 PM Mark Fletcher <[email protected]> wrote:
> 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. > That's...very interesting. WAL-E does do prefetching to speed things up. I didn't think it'd whine about missing files in such a case, but I've forgotten the details on how that was written. > 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. > The backup is hot, so the amount of WAL files to restore is related to how many WAL files were used in the duration of the backup. -- 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.
