Mark Stosberg <[EMAIL PROTECTED]> writes: > As I'm sure it's evident by now, I'm a fan of the 'altperl' wrapper for > Slony. I think it makes a more pleasant interface for most operations. > I've run into a couple parts of the underlying framework that I would > like to be exposed, and I'm pondering how best to do that. > > 1. 'slon' command line options, in particular "-d", which is hardcoded > now to "-d2" in the "slon_start" routine. I'll propose to address this > by adding a general "$slon_args" option to slon_tools.conf, to be used > by "start_slon". It would default to "-d2". > > 2. Some "slon.conf" values are not accessible to be changed. Recently I > ran into this with the syslog options. This could also be addressed in > slon_tools.conf, by adding a "slon_conf" hashref, where more values > could be overridden here by key/value pairs in the hash. > > Seem reasonable?
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... -- (reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc")) <http://dba2.int.libertyrms.com/> Christopher Browne (416) 673-4124 (land) _______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
