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

Re: Streaming replication status and fail over questions

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Michael Holt <michael(at)aers(dot)ca>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Streaming replication status and fail over questions
Date: 2011-06-10 04:02:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
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:
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(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support
"PostgreSQL 9.0 High Performance":

In response to

pgsql-admin by date

Next:From: Thomas BednarzDate: 2011-06-10 05:13:53
Subject: Re: calling pg_dump from perl
Previous:From: Greg Sabino MullaneDate: 2011-06-09 20:16:24
Subject: Re: calling pg_dump from perl

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