Re: Setting up replication on Windows, v9.4 - Mailing list pgsql-general

From Ron
Subject Re: Setting up replication on Windows, v9.4
Date
Msg-id d1196cdf-7a90-e587-8808-7b07f8035050@gmail.com
Whole thread Raw
In response to Setting up replication on Windows, v9.4  (Brad White <b55white@gmail.com>)
List pgsql-general
Note that WAL replication replicates the whole instance not just specific databases.  You need logical replication for that.

Also, I just learned that 9.4 does have WAL replication slots (which makes replication much easier).  v9.6 is where replication is "like rolling off a log" simple.

On 11/4/22 17:59, Brad White wrote:
I'm setting up a backup for our primary postgres server using the archived WAL files.
Then I'll try to upgrade it to Streaming Replication.
Then I'll upgrade the system to v.latest.
For now, we are on v.9.4.

I do a base backup from the primary to a directory on the NAS.

      "C:\Program Files\PostgreSQL\9.4\bin\pg_basebackup.exe" -D \\diskstation\AccessData\Dev\Backup -P -X s -v -h 192.168.1.118 -p 5432 -U postgres

That appears to go fine.
Then I delete data\*.* and copy everything except the config files from the backup into data.

Copy in recovery.conf
------
    standby_mode          = 'on'
    primary_conninfo      = 'host=192.168.1.118 port=5432 user=replication password=**********'
    restore_command = 'copy "\\\\DISKSTATION\\AccessData\\WALfiles\\%f" "%p"'
------
Copy in postgresql.conf, with settings
------
listen_addresses = '127.0.0.1,192.168.1.118'
wal_level = archive
hot_standby = on
------
Interestingly, the recovery file says 
# Note that recovery.conf must be in $PGDATA directory.
# It should NOT be located in the same directory as postgresql.conf
Those seem contradictory.
And if I remove the postgresql, it just refuses to start.

With all this in place, I start the service, it runs for a bit, then shuts down.
No errors in the event log.
5 postgres processes are left running along with a pid file.

The log file says
------
LOG:  database system was interrupted while in recovery at log time 2022-11-04 13:17:28 PDT
HINT:  If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target.
FATAL:  the database system is starting up
FATAL:  the database system is starting up
FATAL:  the database system is starting up
LOG:  entering standby mode
LOG:  consistent recovery state reached at 6A/35000090
LOG:  record with zero length at 6A/35000090
LOG:  started streaming WAL from primary at 6A/35000000 on timeline 1
LOG:  redo starts at 6A/35000090
FATAL:  the database system is starting up
FATAL:  the database system is starting up
FATAL:  the database system is starting up
....
FATAL:  the database system is starting up
FATAL:  the database system is starting up

So it seems that the backup didn't work as well as first appeared.

--
Angular momentum makes the world go 'round.

pgsql-general by date:

Previous
From: Christophe Pettus
Date:
Subject: Re: Q: fixing collation version mismatches
Next
From: Tom Lane
Date:
Subject: Re: ON CONFLICT and WHERE