Skip site navigation (1) Skip section navigation (2)

Mechanics of streaming replication

From: A J <s5aly(at)yahoo(dot)com>
To: PG Admin <pgsql-admin(at)postgresql(dot)org>
Subject: Mechanics of streaming replication
Date: 2011-07-26 17:00:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
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

Next:From: FilipposDate: 2011-07-26 17:46:02
Subject: heavy load-high cpu itilization
Previous:From: Tomas VondraDate: 2011-07-25 18:15:10
Subject: Re: [ADMIN] Restore database after drop command

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group