Christopher Browne wrote: > > I'm getting less and less keen on the merits of 'altperl' for running > slon processes. > > There are 3 problems that arise: > > 1. Fragility of some options > 2. Insufficient letters in alphabet > 3. Inability to support non-uniform node treatment > > 1. Fragility: > > If running log shipping, I don't want a bug in the watchdog script > to cause the slon to be able to run for even an instant without the > "-a" option; that would irretrievably corrupt log shipping, > requiring going to a fresh data dump. > > 2. Alphabetic insufficiency > > There are getting to be so many config parameters that we just can't > have a command line parameter for each. > > 3. Nonuniform node treatment > > Log shipping is an obvious case where we want different nodes to > behave differently; there are a bunch of slon parameters, and we > might want different nodes to have different values. > > Doing this via options in the Perl watchdog script would complicate > its data structures precipitously. And that adds to 1. (Fragility) > > What I see as the "way of the future" is to use slon.conf files, as > can be configured in tools/mkslonconf.sh and launched via > tools/launch_clusters.sh. > > mkslonconf.sh creates a series of config files, one for each node, > which you can then customize as much as needed. > > launch_clusters.sh is then a trivially simple script which doesn't > need to be very intelligent. > > There may be some way to bring this together, though it seems to me > that the combination of the conf files and launcher is powerful > enough, despite being very simple, that all we could do is to make it > more complicated and thereby LESS nice for an Unhappy DBA to have to > cope with at 3am...
Chris, Thanks for the response. These points all seem valuable to consider. I'm certainly not attached the current design or implementation of altperl, but there are key benefits to it that seem worth preserving: 1. The single, central config file. Even if there are options that are set per-node, it's still nice to have everything in one config file, perhaps with an "include" directive to handle complex setups. 2. No raw slonik or custom scripting needed for common commands. For the basic master/slave setup, altperl has been a complete solution for me. Stepping back, as a new user, the various interfaces and layers have been confusing, especially: 1. slon.conf vs slon_tools.conf 2. 'slon' vs 'slonik' vs "slony" vs "slonik_*" It would be nice to bring some simplicity here. It seems like a a future "slon.conf" could merge in the functionality that "slon_tools.conf". I see that binaries better named as: slon -> slond slonik* -> slonc (with subcommands..."c" being for "client") Anyway, the names themselves are not the most important thing, but the quality of different but similar names is. Are others interested in continuing to have a higher-level interface that doesn't require using slonik directly for common operations? Mark _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
