Message-ID: <4DF1975C.7060303@2ndquadrant.com>
Date: Fri, 10 Jun 2011 00:02:36 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Michael Holt <michael@aers.ca>
CC: pgsql-admin@postgresql.org
Subject: Re: Streaming replication status and fail over questions
References: <BANLkTi=GMRpVaFDAz_8Jj58bT4SnC72=WA@mail.gmail.com>
In-Reply-To: <BANLkTi=GMRpVaFDAz_8Jj58bT4SnC72=WA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael Holt wrote:
> 1) I've seen things about using pg_current_xlog_location(), 
> pg_last_xlog_replay_location(), pg_last_xlog_receive_location() to 
> check replication status, but how can this tell me either the time lag 
> or actual query lag? Do I need to wait for 9.1 and it's replication 
> monitoring features?

You might want to check out repmgr:  http://projects.2ndquadrant.com/repmgr
It can collect data in the background that it uses to compute lag in 
time units.

> 2) If I have a master to multi-slave setup and need to fail over, is 
> there anyway for slaves to detect the new master? Without this it 
> seems like fail over could be pretty messy.

repmgr also provides a view to help make this easier to figure out right 
now, and the next version due out any day now will go even further 
toward automating it completely.

> 3) Finally just wanted to confirm that SR allows only for replication 
> of an entire server.

Well, an entire database cluster on a server.  I have put more than one 
database cluster on a server before in order to make it possible to 
replicate only a subset of the data.  But that's difficult to pull off, 
you end up needing tools like dblink for anything that crosses the two 
databases together.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support  www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books