Обсуждение: Streaming replication status and fail over questions

I'm investigating moving from slony to streaming replication as we plan some upgrades from 8.x versions of postgres to 9. I've managed to get it working but there's a couple questions I've been unable to find answers to so far.

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?

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.

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


--
Michael Holt, Database Administrator  |  TERAPEAK
2307-4464 Markham Street, Victoria, BC, CANADA V8Z 7X8
+1 250 483 3271 (FAX)
www.terapeak.com | |

On Fri, 2011-06-03 at 11:07 -0700, Michael Holt wrote:
> I'm investigating moving from slony to streaming replication as we
> plan some upgrades from 8.x versions of postgres to 9. I've managed to
> get it working but there's a couple questions I've been unable to find
> answers to so far.
>
> 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?

It can't.

>  Do I need to wait for 9.1 and it's replication monitoring features?
>

It will only give you time lag (and some nice views, but no query lag).

> 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?

Automatically, no.

>  Without this it seems like fail over could be pretty messy.
>

Failover isn't messy. Switchover, in the other hand, is pretty
difficult.

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

Yes.


--
Guillaume
  http://blog.guillaume.lelarge.info
  http://www.dalibo.com

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