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, copied all the files to the slave, > added a recovery.conf, started the master with synchronized_commit = on and > then started the 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 (The WAL id only changes every > few minutes, is that normal?). The last entry in the logfiles of the slave > says "redo starts at XYZ" > > Does the master resend the hole database in WAL format? For tests I started a > delte command for one sigle entry, but it just 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 a general mistake I did, because > between taking the copy and restarting the instances no or only a few tiny > transactions where commited.
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 data in 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 [email protected] -- Sent via pgsql-general mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
