Hi,
Simon Riggs wrote:
1. Standby contacts primary and says it would like to catch up, but is
currently at point X (which is a point at, or after the first consistent
stopping point in WAL after standby has performed its own crash
recovery, if any was required).
2. primary initiates data transfer of old data to standby, starting at
point X
3. standby tells primary where it has got to periodically
4. at some point primary decides primary and standby are close enough
that it can now begin streaming "current WAL" (which is always the WAL
up to wal_buffers behind the the current WAL insertion point).
Hm.. wouldn't it be simpler, to start streaming right away and "cache"
that on the standby until it can be applied? I.e. a protocol like:
1. - same as above -
2. primary starts streaming from live or hot data from it's current
position Y in the WAL stream, which is certainly after (or probably
equal to) X.
3. standby receives the hot stream from point Y on. It now knows it
misses 'cold' portions of the WAL from X to Y and requests that.
4. primary serves remaining 'cold' WAL chunks from its xlog / archive
from between X and Y.
5. standby applies 'cold' WAL, until done. Then proceeds with the cached
WAL segments from 'hot' streaming.
Bear in mind that unless wal_buffers > 16MB the final catchup will
*always* be less than one WAL file, so external file based mechanisms
alone could never be enough.
Agreed.
This also probably means that receipt of WAL data on the standby cannot
be achieved by placing it in wal_buffers. So we probably need to write
it directly to the WAL files, then rely on the filesystem cache on the
standby to buffer the data for use by ReadRecord.
Makes sense, especially in case of cached WAL as outlined above. Is this
a problem in any way?
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
