Re: Best replication solution?

От: Jeff
Тема: Re: Best replication solution?
Дата: ,
Msg-id: 8BCF1E1D-B78A-4FC8-9B76-E523280BFF47@torgo.978.org
(см: обсуждение, исходный текст)
Ответ на: Re: Best replication solution?  (Andrew Sullivan)
Ответы: Re: Best replication solution?  (Dimitri Fontaine)
Список: pgsql-performance

Скрыть дерево обсуждения

Best replication solution?  (Lists, )
 Re: Best replication solution?  (Lists, )
  Re: Best replication solution?  ("Greg Sabino Mullane", )
  Re: Best replication solution?  (Heikki Linnakangas, )
   Re: Best replication solution?  (Lists, )
    Re: Best replication solution?  (Ivan Voras, )
   Re: Best replication solution?  (Marinos Yannikos, )
 Re: Best replication solution?  (Andrew Sullivan, )
  Re: Best replication solution?  (Lists, )
   Re: Best replication solution?  (Andrew Sullivan, )
  Re: Best replication solution?  (Dimitri Fontaine, )
  Re: Best replication solution?  (Mark Kirkwood, )
   Re: Best replication solution?  (Andrew Sullivan, )
    Re: Best replication solution?  (Mark Kirkwood, )
    Re: Best replication solution?  (Jeff, )
     Re: Best replication solution?  (Dimitri Fontaine, )
      Re: Best replication solution?  (Jeff, )

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 <>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/





В списке pgsql-performance по дате сообщения:

От: "Rainer Mager"
Дата:
Сообщение: Re: difficulties with time based queries
От: Віталій Тимчишин
Дата:
Сообщение: Re: Nested query performance issue