On Apr 7, 2009, at 1:18 PM, Andrew Sullivan wrote:
I should have stated that differently. First, you're right that if
you don't know where to look or what to look for, you can easily be
unaware of nodes being out of sync. What's not a problem with Slony
_$cluster.sl_status on the origin is a very handy tool to see your
slaves, how many sync's behind they are and whatnot. Maybe I'm lucky,
but I haven't got into a funky state that didn't cause my alarms that
watch sl_status to go nuts.
Complexity seems to be the major evil here.
Yes. Slony is massively complex.
Configuring slony by hand using slonik commands does suck horribly.
But the included altperl tools that come with it, along with
slon_tools.conf removes a HUGE amount of that suck.
To add a table with a pk you edit slon_tools.conf and add something
along the lines of:
"someset" => {
"set_id" => 5,
"table_id" => 5,
"pkeyedtables" => [ "tacos", "burritos", "gorditas" ]
}
then you just run
[create tables on slave(s)]
slonik_create_set someset;
slonik_subscribe_set 1 2;
there are other handy scripts in there as well for failing over,
adding tables, merging, etc. that hide a lot of the suck. Especially
the suck of adding a node and creating the store paths.
I'm running slony on a rather write intensive system, works fine, just
make sure you've got beefy IO. One sucky thing though is if a slave
is down sl_log can grow very large (I've had it get over 30M rows, the
slave was only down for hours) and this causes major cpu churn while
the queries slon issues sift through tons of data. But, to be fair,
that'll hurt any replication system.
--
Jeff Trout <jeff@xxxxxxxxxxxxx>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
