Обсуждение: erserver
Hi, can somebody give me a hint on how to contact the guys at pgsql.com regarding the eRserver software? They don't seem to check their info@ accounts listed on their websites. Thanks Greetings, Bjoern
Similar in here. I sent as well some email info request related with some questions. Seems nobody is answering from info@pgsql.com - stefan On Thu, 25 Jul 2002, Bjoern Metzdorf wrote: > Hi, > > can somebody give me a hint on how to contact the guys at pgsql.com > regarding the eRserver software? > > They don't seem to check their info@ accounts listed on their websites. > > Thanks > > Greetings, > Bjoern > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
Hi guys, They've had email problems recently, specifically with the "info@pgsql.com" email address. Seems email wasn't collecting from it properly, so there were nearly 100 unanswered emails in there and they're going through them. If it's any help, I'm in the process of becoming a "Platinum Development Partner" and getting to know a lot about erServer is high on my agenda. What did you want to know about it? :-) Regards and best wishes, Justin Clift stefan@extum.com wrote: > > Similar in here. I sent as well some email info request related with some > questions. Seems nobody is answering from info@pgsql.com - > > stefan > > On Thu, 25 Jul 2002, Bjoern Metzdorf wrote: > > > Hi, > > > > can somebody give me a hint on how to contact the guys at pgsql.com > > regarding the eRserver software? > > > > They don't seem to check their info@ accounts listed on their websites. > > > > Thanks > > > > Greetings, > > Bjoern > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Thu, Jul 25, 2002 at 07:36:34PM +1000, Justin Clift wrote:
> If it's any help, I'm in the process of becoming a "Platinum Development
> Partner" and getting to know a lot about erServer is high on my agenda.
Feel free to ask me, as well. We're using the code in production.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
Hi, > Feel free to ask me, as well. We're using the code in production. We are looking for some reliable replication mechanism in order to avoid unlimited database server upgrading and single machine point of failure. Well, does it work? :-) Are multiple slaves possible (I do suspect so)? How fast is the replication (some seconds)? On what architectures does it run? Does it work with 7.2/7.2.1 ? How much is it? Any other personal experiences? Greetings, Bjoern
We had a problem with that box that was corrected several weeks back and all email to there is processed several times daily (by myself) ... did you get a bounce back, or just no answer? when did you send to it? :( On Thu, 25 Jul 2002, Bjoern Metzdorf wrote: > Hi, > > can somebody give me a hint on how to contact the guys at pgsql.com > regarding the eRserver software? > > They don't seem to check their info@ accounts listed on their websites. > > Thanks > > Greetings, > Bjoern > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
Hi, > We had a problem with that box that was corrected several weeks back and > all email to there is processed several times daily (by myself) ... did > you get a bounce back, or just no answer? when did you send to it? :( I sent it about 24 hours ago. I didn't receive a bounce. Greetings, Bjoern
On Thu, Jul 25, 2002 at 02:35:20PM +0200, Bjoern Metzdorf wrote:
>
> Well, does it work? :-)
Yes. In fact, if you do a whois query against .info hostnames
(whois.afilias.net) you are actually seeing a replicated PostgreSQL
database most of the time.
> Are multiple slaves possible (I do suspect so)?
They're supposed to be. I've run into a little problem recently, but
more on that below.
> How fast is the replication (some seconds)?
Quite fast. IIRC, we benchmarked > 1000 rows/s when we stopped,
because that was fast enough for our purposes.
One thing we did discover with 7.1.3 is that RI triggers on the slave
can _really_ slow things down. It appears that triggers get slower
and slower as a transaction rolls on, and therefore make everything
crawl if you have a lot of rows to update (if, for instance, you stop
replication for a while for some reason). The easy answer is to drop
all the RI triggers, although that means you have to add another step
in the event you have to flip over to the slave server. I haven't
yet discovered whether the same problem persists in 7.2.
> On what architectures does it run?
The tools are written in Perl, or at least the ones we have. (AFAIK,
PostgreSQL, Inc. hasn't changed that). We re-implemented the
external part of the code in Java (I am still unclear on why, to be
honest, so don't ask me. I guess someone really liked Java), but all
the internal stuff (the triggers in the database, replication system
tables, &c.) are the same. Our Java developer claimed both that his
implementation was faster, and that it was slower than the Perl code.
I'm not really sure which is true ;-). In my tests, they seemed
about the same to me; and, as I say, in any case fast enough for us.
> Does it work with 7.2/7.2.1 ?
Yes. The same code does not work with 7.1 and 7.2, but a new
function has been provided us for 7.2, and it does indeed work. We
had the new function within a very short time of 7.2. becoming
stable. I presume PostgreSQL, Inc. ships the function appropriate
for the database you use. (BTW, a free plug for PostgreSQL, Inc.: we
had a lot of interaction with them when we were coming up last year,
and setting up this replication system. They did a fine job.)
> How much is it?
That I do not know. Nobody here ever tells me anything about money
;-)
> Any other personal experiences?
The re-implementation has caused me some pain, because the developer
who did it is no longer available to me, and, well, I now have an odd
problem with multi-slave replication that I need to figure out. The
Perl seems to do it, though.
The Perl code is not exactly a complete replication system; it's more
a toolkit, in that you don't run "setup" and get an easy set of
dialogues to configure your replication and go to town. That has
some obvious disadvantages, but it makes the system very flexible,
and I don't really believe that a "one-size-fits-all" replication
facility is practical. For instance, we don't want some tables
replicated, because they are "holding" tables (that is, data goes
into them, and then is processed further afterwards by a lazy
process. This is all to speed up transactions and reduce contention
on some frequently-accessed tables), and so would exact a performance
penalty with no benefit.
The code is similar to, but much improved from, the rserv code in
contrib/. You can get a vague feel of how the system works by
looking at that. It is _not_ the same code, however, by a long shot.
Failover and recovery is not that difficult, but it _is_ a manual
process. I'm not even sure it can be made automatic, because of the
store-and-forward approach: what would you do about the potential
tuples stranded on the master when it went down? (This is a policy
problem that is pretty tough to build into software. Any
asynchronous-replication system that claims to have fully automated
hot failover is just papering over the problem; I know of several
cases where such failover has caused some problems, so think
carefully about it!)
This is also _only_ a master-slave replication. You _must never_
insert data into the slave on a table which is replicated, or you
will all but certainly break something. That means that eRserver is
not a tool for llowing scaling to huge insert volumes. Also, if you
need the slave to handle read-only queries transparently for the
read-write database, you're out of luck: there is a gap between when
the data hits the master and when it hits the slave. If you want
near-real-time, it's more than good enough.
On the whole, I think it's a pretty good system.
Hope that's helpful,
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
On Thu, 25 Jul 2002, Andrew Sullivan wrote: > One thing we did discover with 7.1.3 is that RI triggers on the slave > can _really_ slow things down. It appears that triggers get slower > and slower as a transaction rolls on, and therefore make everything > crawl if you have a lot of rows to update (if, for instance, you stop > replication for a while for some reason). The easy answer is to drop > all the RI triggers, although that means you have to add another step > in the event you have to flip over to the slave server. I haven't > yet discovered whether the same problem persists in 7.2. As a note, very possibly not, since IIRC Tom made some changes to speed up the adding of the deferred triggers between 7.1 and 7.2. However, it's probably not a bad idea to drop the triggers anyway. :)
> Yes. In fact, if you do a whois query against .info hostnames > (whois.afilias.net) you are actually seeing a replicated PostgreSQL > database most of the time. This would be a great way to advertise both PostgreSQL and PgSQL Inc wouldn't it ? .into - Powered by PostgreSQL ERServer !
On Thu, 25 Jul 2002, Bjoern Metzdorf wrote: > Hi, > > > We had a problem with that box that was corrected several weeks back and > > all email to there is processed several times daily (by myself) ... did > > you get a bounce back, or just no answer? when did you send to it? :( > > I sent it about 24 hours ago. I didn't receive a bounce. Damn ... my fault on this :( info@erserver.com has been bouncing: reject: RCPT from ns1.turtle-entertainment.de[193.41.200.20]: 554 <info@erserver.com>: Recipient address rejected: Relayaccess denied; from=<bm@turtle-entertainment.de> to=<info@erserver.com> Fixed now, please resend?
On Thu, Jul 25, 2002 at 12:57:37PM -0300, Jeff MacDonald wrote:
> > Yes. In fact, if you do a whois query against .info hostnames
> > (whois.afilias.net) you are actually seeing a replicated PostgreSQL
> > database most of the time.
>
> This would be a great way to advertise both PostgreSQL and PgSQL Inc
> wouldn't it ?
Yes, it would. I'm working on it ;-) If you check the archives,
though, you'll see several threads about companies being a little
skittish about talking about their use of PostgreSQL. Many marketing
folks, who have frankly never heard of PostgreSQL and want to know
why we are not using the most expensive machine in the hospital (read
"Oracle"), are loathe to associate themselves with something that
isn't already well-known. So our use of PostgreSQL is sort of an
open secret.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110