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 adrian.klaver@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
