Обсуждение: 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 | |
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