Hi list,
we have two 9.1.2 servers on debian squeeze, and are setting up a simple
streaming replication between the two.
* wal_keep_segments is set high on the master
* the slave's recovery.conf contains just standbay_mode=on and
primary_conninfo=foo
* we use a simple start_backup/rsync/stop_backup to create the base copy
before starting the slave.
It all seems to be working fine, except that when checking the data (selecting
latest primary key and sequence value for all tables) on master and slave,
some sequence ids are higher on the slave than on the master. I could
understand if they were lower, but this is weird.
* The slave's sequences can be anywhere between 1 and 50 ids ahead.
* The actual table data is properly in sync.
* We look at the slave before the master.
* We ignore readings where pg_current_xlog_location() !=
pg_last_xlog_replay_location().
* It only happens on frequently-updated sequences.
* During recovery, we have warnings of the form:
2012-05-04 10:32:08 CEST WARNING: xlog min recovery request 16A/2A03BDD0 is
past current point 16A/1E72A880
2012-05-04 10:32:08 CEST CONTEXT: writing block 0 of relation
base/35355/42224_vm
xlog redo vacuum: rel 1663/1562168/1563037; blk 12122, lastBlockVacuumed
12070
2012-05-04 10:32:12 CEST WARNING: xlog min recovery request 16A/469F2120 is
past current point 16A/1E9B6EB8
2012-05-04 10:32:12 CEST CONTEXT: writing block 0 of relation
base/56308/57181_vm
xlog redo vacuum: rel 1663/1562168/1563037; blk 21875, lastBlockVacuumed
21329
2012-05-04 10:32:17 CEST WARNING: xlog min recovery request 16A/22D497B8 is
past current point 16A/1FF69258
* servers have near-identical hardware and software
* monitoring via munin show at most 1-2 KB of replication lag
* we retried the base backup twice
So...
* any likely mistake on our side ?
* can it be fixed ?
* is this harmless and to be ignored ?
Thank you.
--
Vincent de Phily