Streaming replication: sequences on slave seemingly ahead of sequences on master - Mailing list pgsql-general

From Vincent de Phily
Subject Streaming replication: sequences on slave seemingly ahead of sequences on master
Date
Msg-id 17158245.uOt7nTETV4@moltowork
Whole thread Raw
Responses Re: Streaming replication: sequences on slave seemingly ahead of sequences on master
Re: Streaming replication: sequences on slave seemingly ahead of sequences on master
List pgsql-general
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


pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Re: "OLD." || myColumnNameVar (How to generically access columns in a trigger's OLD or NEW records)
Next
From: Merlin Moncure
Date:
Subject: Re: Streaming replication: sequences on slave seemingly ahead of sequences on master