Mechanics of streaming replication - Mailing list pgsql-admin

From A J
Subject Mechanics of streaming replication
Date
Msg-id 1311699626.15557.YahooMailNeo@web120012.mail.ne1.yahoo.com
Whole thread Raw
List pgsql-admin
Hello,
Trying to understand the mechanics of streaming replication.
I understand that the WAL SENDER on primary streams to WAL RECEIVER on standby. Also that depending on the settings, completed WAL files on the primary are sent to the archive directory. If needed, the standby will move the files from the archive directory to its wal directory (pg_xlog) and start applying them to its data files.

My questions are:
1. Is it that the restore command in the recovery.conf only controls when files get moved from archive to the WAL directory on the standby ? If so, when does the restore command get kicked in ? Only at failover or whenever the connection between the primary and the standby is terminated ?
2. The archive directory contents will always lag behind the current WAL on primary by 16MB (unless you tweak archive_timeout parameter at the expense of bloating your archive storage). So in a typical setup, you always risk loosing up-to 16MB of committed data at failover. Right ? And I assume there is no way to reconcile this 16MB automatically when the crashed ex-primary server comes up again. Right ?
3. I don't think 'wal_keep_segments' has too much of a practical use. It keeps the WALs in the pg_xlog directory of the primary which is local only to primary. So in case of primary going down, all those WALs will be lost to the standby. I guess most people primarily rely on 'archive_command' and not wal_keep_segments, and use  Right ?
Or is it that it is preferred to keep wal_keep_segments high enough so that standby need not go to archive directory every now and then ?
4. Does the standby switch-back from reading the archive to streaming once the connection between primary and secondary is restored ?

Thanks for any inputs.

pgsql-admin by date:

Previous
From: Isabella Ghiurea
Date:
Subject: PG 9.0.1 database errors
Next
From: Filippos
Date:
Subject: heavy load-high cpu itilization