Thread: pgsql doesn't include replication...
... is what we hear all the time. We *do* have enough replication solutions, but they're not immetiately visible and the argument "there are many different replication requirements, a single product will never satisfy that" stays true but those guys who want to see "replication included" won't understand that. As another step to make pgsql replication more visible, the next pgAdmin version will include Slony-I support, making maintainance a click thing. A preview image is at http://www.pgadmin.org//snapshots/pgadmin3-slony.png Regards, Andreas
Awesome! This should be very well received. I can't wait to try it out (and get away from my script for setting up slony) :) Gavin On Fri, 2005-02-11 at 23:10 +0000, Andreas Pflug wrote: > ... is what we hear all the time. > > We *do* have enough replication solutions, but they're not immetiately > visible and the argument "there are many different replication > requirements, a single product will never satisfy that" stays true but > those guys who want to see "replication included" won't understand that. > > As another step to make pgsql replication more visible, the next pgAdmin > version will include Slony-I support, making maintainance a click thing. > A preview image is at http://www.pgadmin.org//snapshots/pgadmin3-slony.png > > Regards, > Andreas > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
Andreas, > We *do* have enough replication solutions, but they're not immetiately > visible and the argument "there are many different replication > requirements, a single product will never satisfy that" stays true but > those guys who want to see "replication included" won't understand that. Well, frankly "those guys" are unlikely to adopt PG anyway, since they'll just move on to the next item in their "buzzword checklist", like "XML queries" or some such flavor-of-the-month. We've done a lot to clear up the issue of replicaiton support: http://www.postgresql.org/about/advantages http://www.postgresql.org/download/ http://www.postgresql.org/about/press/presskit80.html.en Basically, if someone is still bouncing us because we "don't have replication support" then it's because they were looking for an excuse. > As another step to make pgsql replication more visible, the next pgAdmin > version will include Slony-I support, making maintainance a click thing. > A preview image is at http://www.pgadmin.org//snapshots/pgadmin3-slony.png Which is really, really cool. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
>> As another step to make pgsql replication more visible, the next pgAdmin >> version will include Slony-I support, making maintainance a click thing. >> A preview image is at >> http://www.pgadmin.org//snapshots/pgadmin3-slony.png > > Which is really, really cool. Hmm, the Slony guys talked to us (the phpPgAdmin team) about doing this as well - but they never got back to us with any implementation details :D Perhaps I'll have to look at this new functionailty in pgAdmin and imitate it? I don't really want to spend forever learning Slony to implement the interface :D Chris
KL- > Hmm, the Slony guys talked to us (the phpPgAdmin team) about doing this as > well - but they never got back to us with any implementation details :D > > Perhaps I'll have to look at this new functionailty in pgAdmin and imitate > it? I don't really want to spend forever learning Slony to implement the > interface :D Well, the slony commands are pretty well-documented. And you can always pop back on IRC. How was the vacation, btw? -- Josh Berkus Aglio Database Solutions San Francisco
josh@agliodbs.com (Josh Berkus) wrote:
> KL-
>
>> Hmm, the Slony guys talked to us (the phpPgAdmin team) about doing this as
>> well - but they never got back to us with any implementation details :D
>>
>> Perhaps I'll have to look at this new functionailty in pgAdmin and imitate
>> it? I don't really want to spend forever learning Slony to implement the
>> interface :D
>
> Well, the slony commands are pretty well-documented. And you can always pop
> back on IRC.
The documentation tree includes docs about the stored functions, which
are probably the way to do this.
The problem of course is that everyone's pretty busy. Jan is
evidently pretty much hiding after he got back from France, and I have
had no lack of things to do.
There's some useful "protocol" to consider when looking at those
stored functions, as there are generally two for each action:
1. A "main" one, which gets invoked on one node
e.g. - to add a path between nodes, you call
storepath( integer, integer, text, integer )
These sometimes can be called "anywhere," but often need to be
called on the node where some interesting action is supposed to
take place. That way, the procedure can successfully check the
state of that node and give a decent error message if it fails.
If the action looks like it'll succeed, Slony-I "raises an event"
to broadcast the activity to everywhere else.
2. Then, there's an "internal" one that does internal work that
should be done on each node.
storepath_int ( integer, integer, text, integer )
When the 'STORE_PATH' event gets broadcasted everywhere, this
"internal" function is used to make the event take effect
"everywhere."
Thus, it's important to run the right functions, and sometimes to run
them on the right node. With storepath(), where to run it isn't
important, as it'll broadcast paths onwards as it propagates. But
with subscribeset(), it had better initially run on the node that's
supposed to be doing the subscribing.
That's reasonably well documented in the functions themselves, so that
trial and error will get you somewhere...
--
(format nil "~S@~S" "cbbrowne" "gmail.com")
http://linuxdatabases.info/~cbbrowne/slony.html
Blood is thicker than water, and much tastier.
The documentation tree includes docs about the stored functions, which
are probably the way to do this.
The problem of course is that everyone's pretty busy. Jan is
evidently pretty much hiding after he got back from France, and I have
had no lack of things to do.
There's some useful "protocol" to consider when looking at those
stored functions, as there are generally two for each action:
1. A "main" one, which gets invoked on one node
e.g. - to add a path between nodes, you call
storepath( integer, integer, text, integer )
These sometimes can be called "anywhere," but often need to be
called on the node where some interesting action is supposed to
take place. That way, the procedure can successfully check the
state of that node and give a decent error message if it fails.
If the action looks like it'll succeed, Slony-I "raises an event"
to broadcast the activity to everywhere else.
2. Then, there's an "internal" one that does internal work that
should be done on each node.
storepath_int ( integer, integer, text, integer )
When the 'STORE_PATH' event gets broadcasted everywhere, this
"internal" function is used to make the event take effect
"everywhere."
Thus, it's important to run the right functions, and sometimes to run
them on the right node. With storepath(), where to run it isn't
important, as it'll broadcast paths onwards as it propagates. But
with subscribeset(), it had better initially run on the node that's
supposed to be doing the subscribing.
That's reasonably well documented in the functions themselves, so that
trial and error will get you somewhere...
--
(format nil "~S@~S" "cbbrowne" "gmail.com")
http://linuxdatabases.info/~cbbrowne/slony.html
Blood is thicker than water, and much tastier.