On Wed, Aug 14, 2002 at 10:15:32PM -0500, Greg Copeland wrote:
> Reading about the pgmonitor thread and mention of gborg made me wonder
> about replication and ready ability to uniformly monitor it. Just as
> pg_stat* tables exist to allow for statistic gathering and monitoring in
> a uniform fashion, it occurred to me that a predefined set of views
> and/or tables for all replication implementations may be worthwhile.
> That way, no matter what replication method/tool is being used, as long
> as it conforms to the defined replication interfaces, generic monitoring
> tools can be used to keep an eye on things.
That sounds like the cart is before the horse. You need to know what
sort of replication scheme you might ever have before you could
know the statistics that you might want to know.
There are different sorts of replication schemes under consideration.
For instance, rserv uses an asynchronous master/slave approach, which
relies on slaves that are almost dumb as chickens. (Not quite.
There is some data about the state of replication in the slave
database; but most of it is in the master.) Postgres-R, on the other
hand, contemplates a distributed model wherein different database
machines participate in a pool.
So for rserv-style replication, you want to know (for instance)
average slave-update times, and whether slaves are getting behind,
and by how much, and such. Balancing of inserts, however, is not
relevant, because you can't do that.
Postgres-R will have the opposite need: you'll want to know what sort
of load balancing you're getting, but time-to-replicate is not
relevant, because a commit on one machine is necessarily a commit
everywhere (that's why it's "eager" replication).
You probably could design a set of statistics that would cover all
cases, but only after you know what the cases were.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3 +1 416 646 3304
x110
