Having attempted to use Slony and given up (for now), I share some of Craig's frustration.  It appears that the Slony community has focused on making a very powerful and highly configurable toolset.  What has been lost is ease of use.

Having worked with other databases, where replication is very easy to set up, I was surprised and frustrated by the extent that Slony was not a replication appliance, so much as a collection of tools with which a replication solution can be crafted.  It is, apparently, a very good set of tools, but I imagine that the vast majority of database users (as opposed to Slony users) really only need a simple setup: replicate all tables onto 1 or a few slaves.

My difficulties (and perhaps Craig's) were not with the technology, but with packaging.  I would find enormous value in a canned, complete, pre-configured, one-size-fits-all distribution with a simple user interface.  Perhaps I'm just displaying my stupidity, but having spent weeks compiling, configuring, debugging, recompiling, restoring a mangled database, lather, rinse repeat, I have to concur with Craig's characterization of the documentation and error messaging as inadequate.  I've done the equivalent task with MySQL in less than an hour (including the replication time), without any loss of data, despite having (at the time) considerably more ignorance.

Some have indicated that they "found the slony docs quite good", which may be true at the detail level, but from the I-haven't-a-clue-how-do-I-get-started level, I never found a single, complete, correct, applicable set of instructions, but instead found many little snippets that explained part of the job, then pointed to other instructions that made conflicting assumptions about how things were set up.

Perhaps Mammoth will provide the simple solution that we (Craig and I) need, but I don't see value in splitting the efforts of the community across 2 solutions.  I would have thought it better to write a simple setup script for Slony, or at least a Slony Setup for Dummies document.

FWIW, I learned to program in machine code, it's merely that my boss expects me to be more productive than that.

Walter
-----Original Message-----
From: slony1-general-bounces at lists.slony.info [mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Jan Wieck
Sent: Friday, April 04, 2008 5:18 PM
To: Glyn Astill
Cc: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] Abandoning Slony (was: drop-set/create-set,causes "node -1 not found")

On 4/4/2008 5:25 PM, Glyn Astill wrote:
> See below

It appeared to me that Craig needed to get something off his chest after 
getting very frustrated. And getting frustrated with Slony is something 
that we all know is possible. The only thing that really worried me in 
the whole rant was that he obviously ran into all these problems while 
attempting to use Slony in a large scale production environment without 
bothering to test and learn in a lab setup prior to risking all that 
precious data.

Slony was not developed with that sort of irresponsible user in mind.

I am sorry that Slony does not meet Craig's ease of use expectations. As 
has been said many times, there can not be a one size fits all approach 
to replication. Hopefully he will find that some other project, like 
Mammoth (which is being open sourced right now) can deliver the 
functionality, performance as well as simplicity that he expects.


Good luck
Jan


> 
> ----- Original Message ----
>> From: Craig James <craig_james at emolecules.com>
>> To: slony1-general at lists.slony.info
>> Sent: Friday, 4 April, 2008 7:09:24 PM
>> Subject: [Slony1-general] Abandoning Slony (was: drop-set/create-set, causes  "node -1 not found")
>> 
>> Glyn Astill wrote:
>> 
>> > I had a similar scenario a few months ago and never managed to figure
>> > out what happened. Nobody could tell me what the node -1 was all about...
>> > 
>> > I'd love to know if you  get to the bottom of it.
>> 
>> Yes, I just now got to the bottom of it.  I realized that Slony is not high 
>> enough quality to use in a production environment, and I'm abandoning it until 
>> some time in the future when it has matured a bit more.
>> 
>> This is just the last straw.  I really hate to be critical of any open-source 
>> project, because I genuinely appreciate everyone's hard work.  But in the end, 
>> Slony has proved to be more trouble that it is worth.  It simply doesn't get the 
>> job done reliably.
>> 
>> It's clear to me that Slony's developers are focused on features, and have not 
>> paid enough attention to the user experience.  It's a classic case where the 
>> developers, who are experts in their own technology, don't realize just how 
>> difficult their product is for the mainstream user.
>> 
>> * Slony's configuration is like programming in FORTRAN or assembly language in 
>> 1966.  There is no reason why Slony should need anything more than a set's name 
>> and the table's names that belong to the set.  Computers are good at numbering 
>> things, why should I have to?  It takes DAYS to learn how to create a Slony 
>> configuration, and it is only achieved through lots of trial and error.
> 
> Really? I found the slony docs quite good to be honest, and the slonik language is there to make it flexible.
> How you manage to compare slonik scripts to fortran is beyond me, and from that comment I can only guess you've never touched any form of assembly.
> 
>> 
>> * It is trivially easy to DESTROY an entire database with Slony.  All you have 
>> to do is a simply typo, reversing node 1 and node 2, and Slony will, with no 
>> further warning, truncate every table in your master database.  There is no way 
>> to say, "This is the MASTER, no matter what else I say, never mess with it."  
>> This should be a fundamental concept in Slony, but is not.  This is particularly 
>> serious, given that Slony expects to connect as the super-user, so you can't 
>> (for example) use a guest account that has no write priviliges, which would be 
>> the sensible approach.  Slony really needs two users: The super user (during 
>> configuration only), and the operational user (during normal operation), and 
>> these should be set separately for the master and slaves..
>> 
> 
> Hmm, slonik has proved to be very forgiving with any typos like that for me. If something is wrong then it generally doesn't run the script. However you can get yourself into a mess if you're not careful to wait for certain things to complete, in my opinion it could do with a little brushing up here. I also recently made a bit of a mess by adding a trigger onto a slave database, then trying to drop the table without bringing it out of the cluster - I still need to sort this.
> 
> 
>> * Slony's configuration files can contain errors that are only detected after 
>> many hours, even days, of operation have elapsed. This happened to me yesterday: 
>> 14 hours after an initial copy-set operation started, it reported that one of 
>> the slave tables was missing its primary key, something it could have reported 
>> when the cluster was created.  And often when the error is discovered, the only 
>> recourse seems to be to uninstall the Slony schema, and restart from ground 
>> zero.
>>
> 
> Afaik if theres no primary key on the table slony will create what it needs?
>  
>> * Slony can encounter errors from which there is no recovery, except to blow off 
>> the system and start over.  Such as the one I'm facing right now.
>>
> 
> In the aforementioned shagged scenario, I can agree that I had to recreate the slony cluster here to get our of a similar problem - and I can see how it could be a big problem. But honestly - since I read the docs better and ran the scripts ONLY as described in the docs, I've yet to have another big problem.
> 
>> 
>> * Almost every serious error I've encountered has resulted in a meaningless 
>> error message.  The only recourse is to post a question on this forum, and wait 
>> for an answer.  Developers have been very friendly and helpful, but the point 
>> is, I shouldn't have to come here for EVERY problem.  Take this particular 
>> problem, "node -1 not found in runtime configuration."  In the exact spot of 
>> code that generated that message, the developer who wrote that code KNEW what 
>> was going on.  What operation was being tried?  What set is being copied?  What 
>> generated this event?  This information is available somewhere, but IS NOT 
>> REPORTED TO THE USER.  This seems to be the rule, not the exception, in my 
>> experience with Slony, and it demonstrates a lack of attention to the quality of 
>> the user experience.  There is never an excuse for not telling the user 100% of 
>> the information that is known when an exception occurs.
> 
> I've seen worse in commercial products. But must agree I thought the same about the -1 thing - Surely someone at affilias has to know how we end up with that?
> 
>> 
>> Or take this example, that I reported on 4/2/2008:
>> 
>>     ERROR: Slonik version: 1.2.13 != Slony-I version in PG build 1.2.9
>> 
>> What's the critical missing information here? WHICH NODE NUMBER IS REPORTING 
>> THIS???  The developer who wrote this code KNEW which node generated the 
>> problem, but didn't put that information into the error message, which cost me, 
>> and Jeff Frost (who helped my diagnose the problem), about 4 hours of wasted 
>> time.  This seems to be the rule, rather than the exception, in the way Slony is 
>> coded.
>>
> 
> Bloomin heck! How many nodes have you got!
>  
>> Slony is like a really fast race car.  The drivers are justifiably proud that it 
>> is a very fine machine, that their machine is REALLY fast.  But if you want to 
>> get to the grocery store, you're better off to take the family car, or even a 
>> horse and buggy, because if you take the race car to the grocery store, you may 
>> be hungry several times each week.  And if you have a critical situation, like 
>> someone is sick, the race car might get them to the hospital very quickly 
>> indeed.  But there's an equally good chance the sick patient would die by the 
>> side of the road waiting for the the race car's team to repair the engine.
>> 
>> So, best wishes to the Slony team, and keep up the good work.  If my comments 
>> seem harsh, it's because I care: I wouldn't even bother if Slony was junk.  It's 
>> a great idea, and most of Slony is well conceived and well executed.  I hope 
>> that my comments will be take as constructive criticism.  I hope to be back in a 
>> few years when you've made more progress.
>> 
>> Regards,
>> Craig
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Slony1-general mailing list
>> Slony1-general at lists.slony.info
>> http://lists.slony.info/mailman/listinfo/slony1-general
>> 
> 
> 
> 
> 
>       ___________________________________________________________ 
> Yahoo! For Good helps you make a difference  
> 
> http://uk.promotions.yahoo.com/forgood/
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general


-- 
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin

_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general