On Mon, Feb 25, 2019 at 11:45 PM Stephen Frost <sfrost@xxxxxxxxxxx> wrote: > > Greetings, > > * Filip Rembiałkowski (filip.rembialkowski@xxxxxxxxx) wrote: > > There is a large (>5T) database on PostgreSQL 9.0.23. > > First off, I hope you understand that 9.0 has been *long* out of > support and that you *really* need to upgrade to a supported version of > PostgreSQL (9.4 and up these days...). Yes I do. Unfortunately it was not possible. >> > I would like to setup new WAL-shipping standby. > > https://www.postgresql.org/docs/9.0/warm-standby.html > > > > On my way I find unexpected issues. Here's the story, in short: > > > > 1. WAL archiving to remote archive is setup & verified > > > > 2. base backup is transferred directly to new server using > > pg_start_backup + rsync + pg_stop_backup. > > > > 3. recovery.conf is created > > > > 4. Server is started and consumes all the remaining WAL segments > > accumulated in the archive - finishing with optimistic message LOG: > > consistent recovery state reached at 9FC1/112BEE10. > > > > 5. When I go to postgres on the standby and try to connect system > > "postgres" database psql: FATAL: could not open file "global/11819": > > No such file or directory > > That seems pretty odd- does that file exist on the existing database > system..? No. "global/11819" does not exist on the primary. That's what makes it a mystery for me. At first, I was thinking - maybe OIDs of some objects in pg_global tablespace were "rotated" (VACUUM FULL, etc) during the rsync. But it seems unlikely.
