On 04/04/2012 01:30 PM, hans wulf wrote:
> I'm trying to set up a replication server that shall handle synchronized commits. I stopped my master database,
copiedall the files to the slave, added a recovery.conf, started the master with synchronized_commit = on and then
startedthe slave.
>
> I would prusume because the slave is nearly up to date, that the catching up would run in a few seconds.
>
> Now it's been half a day and I still see WAL sender and WAL receiver transfering data if I hit the linux ps command
(TheWAL id only changes every few minutes, is that normal?). The last entry in the logfiles of the slave says "redo
startsat XYZ"
>
> Does the master resend the hole database in WAL format? For tests I started a delte command for one sigle entry, but
itjust doesn't come to an end. Through the ps command I can also see other transactions waiting for ages.
>
> My question: Is this normal? Or did I do something wrong? Is there a change of speeding things up? I guess it must be
ageneral mistake I did, because between taking the copy and restarting the instances no or only a few tiny transactions
wherecommited.
In addition to synchronized_commit = on you also need to set synchronous_standby_names to replicate to a standby:
http://www.postgresql.org/docs/9.1/interactive/runtime-config-replication.html#GUC-SYNCHRONOUS-STANDBY-NAMES
To confirm, from the above:
"The synchronous standby will be the first standby named in this list that is both currently connected and streaming
datain real-time (as shown by a state of streaming in the pg_stat_replication view)."
>
> I don't use any WAL archives.
>
> Maybe a side question: Can the slave catch up without any base backup or some really old one when no WAL archive
exists?Does the master translate its current state into some fake WAL to transfer via TCP?
--
Adrian Klaver
adrian.klaver@gmail.com