| Slony-I 1.2.22 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
It's a bit of a pain writing Slonik scripts by hand, particularly as you start working with Slony-I clusters that may be comprised of increasing numbers of nodes and sets. Some problems that have been noticed include the following:
If you are using Slony-I as a "master/slave" replication system with one "master" node and one "slave" node, it may be sufficiently mnemonic to call the "master" node 1 and the "slave" node 2.
Unfortunately, as the number of nodes increases, the mapping of IDs to nodes becomes way less obvious, particularly if you have a cluster where the origin might shift from node to node over time.
Similarly, if there is only one replication set, it's fine for that to be "set 1," but if there are a multiplicity of sets, the numbering involved in using set numbers may grow decreasingly intuitive.
People have observed that Slonik does not provide any notion of iteration. It is common to want to create a set of similar SLONIK STORE PATH entries, since, in most cases, hosts will likely access a particular server via the same host name or IP address.
Users seem interested in wrapping everything possible in TRY blocks, which is regrettably somewhat less useful than might be hoped...
These have assortedly pointed to requests for such enhancements as:
Named nodes, named sets
This is supported in Slony-I 1.1 by the SLONIK DEFINE and SLONIK INCLUDE statements.
The use of SLONIK INCLUDE to allow creating "preamble files" has proven an invaluable tool to reduce errors. The preamble file is set up once, verified once, and then that verified script may be used with confidence for each slonik script.
Looping and control constructs
It seems to make little sense to create a fullscale parser as Yet Another Little Language grows into a rather larger one. There are plenty of scripting languages out there that can be used to construct Slonik scripts; it is unattractive to force yet another one on people.
There are several ways to work around these issues that have been seen "in the wild":
Embedding generation of slonik inside shell scripts
The test bed found in the src/ducttape directory takes this approach.
The altperl tools use Perl code to generate Slonik scripts.
You define the cluster's configuration as a set of Perl objects; each script walks through the Perl objects as needed to generate a slonik script for that script's purpose.