Hi there,
In one of our systems we’ve noticed the following (strange?) behavior. In a Master/Slave configuration, we run wal-mgr to achieve data replication from the master to the slave node. Both nodes run PostgreSQL 8.4.1 (on Solaris 10). The slave starts in archive mode and initiates a restore from the log files. After few segments, it complains with the following error message:
...
LOG: WAL file is from different system
DETAIL: WAL file SYSID is 5466170076771909117, pg_control SYSID is 5516922116183112703
LOG: redo done at 0/8FFE920
LOG: last completed transaction was at log time 2010-09-17 10:19:49.545025-04
2010-09-17 10:20:15,621 20400 INFO 000000010000000000000008: Found
2010-09-17 10:20:16,776 20400 INFO {count: 1}
LOG: restored log file "000000010000000000000008" from archive
2010-09-17 10:20:17,118 20417 INFO 00000002.history: not found, ignoring
2010-09-17 10:20:17,119 20417 INFO got SystemExit(1), exiting
LOG: selected new timeline ID: 2
2010-09-17 10:20:17,458 20433 INFO 00000001.history: not found, ignoring
2010-09-17 10:20:17,459 20433 INFO got SystemExit(1), exiting
LOG: archive recovery complete
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
I’m trying to understand few things here:
1) Why one of the segments has a different SYSID (knowing that all WAL segments are originating from the same node)? In other words, under which circumstances the SYSID could be different from one segment to another one on the same node? CRC is ok, which means that none of these segments is corrupted.
2) Once the postmaster encounters this issue, it stops the recovery and switches to master mode, hence breaking Master/Slave mode. What’s the rationale behind changing underneath the system the database mode?
3) How would one know that the replication is progressing correctly?
I’m not sure if it’s the right mailing list. If not, please let me know which one is more appropriate and I’ll post there.
Thank you in advance for your time and help,
Regards,
Youssef