On Apr 8, 2009, at 4:46 PM, Dimitri Fontaine wrote:
$ londiste.py setup.ini provider add schema.table
$ londiste.py setup.ini subscriber add schema.table
That is nice. One could probably do that for slony too.
I may try some tests out with londiste.. I'm always open to new
(ideally,
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
is that the nodes can get out of internally consistent sync state:
Heikki Linnakangas wrote:
Lists wrote:
Server is a dual core xeon 3GB ram and 2 mirrors of 15k SAS drives (1
for most data, 1 for wal and a few tables and indexes)
In total all databases on the server are about 10G on disk (about 2GB
in pgdump format).
I'd suggest buying as much RAM as you
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
Hi,
Ok I need to answer some more :)
Le 8 avr. 09 à 20:20, Jeff a écrit :
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
On Monday 06 April 2009 14:35:30 Andrew Sullivan wrote:
*SkyTools/Londiste* - Don't know anything special about it.
I've been quite impressed by the usability. It's not quite as
flexible as Slony, but it has the same theory of operation. The
documentation is not as voluminous, although
Andrew Sullivan wrote:
On Sun, Apr 05, 2009 at 11:36:33AM -0700, Lists wrote:
*Slony-I* - I've used this in the past, but it's a huge pain to work
with, caused serious performance issues under heavy load due to long
running transactions (may not be the case anymore, it's been a while
Lists wrote:
I'm currently running 32bit FreeBSD so I can't really add more ram (PAE
doesn't work well under FreeBSD from what I've read)
That's probably left-over from the time many drivers were not 64-bit
friendly. I've yet to see a new configuration that doesn't work with PAE
(also, the
On Tue, Apr 07, 2009 at 10:31:02PM +1200, Mark Kirkwood wrote:
From my experience - gained from unwittingly being in the wrong place at
the wrong time and so being volunteered into helping people with Slony
failures - it seems to be quite possible to have nodes out of sync and
not be
Lists wrote:
Server is a dual core xeon 3GB ram and 2 mirrors of 15k SAS drives (1
for most data, 1 for wal and a few tables and indexes)
In total all databases on the server are about 10G on disk (about 2GB in
pgdump format).
I'd suggest buying as much RAM as you can fit into the server.
On Sun, Apr 05, 2009 at 11:36:33AM -0700, Lists wrote:
*Slony-I* - I've used this in the past, but it's a huge pain to work
with, caused serious performance issues under heavy load due to long
running transactions (may not be the case anymore, it's been a while
since I used it on a
I'm currently running 32bit FreeBSD so I can't really add more ram (PAE
doesn't work well under FreeBSD from what I've read) and there are
enough writes that more ram won't solve the problem completely.
However I will add plenty more ram next time I rebuild it.
Heikki Linnakangas wrote:
Andrew Sullivan wrote:
On Sun, Apr 05, 2009 at 11:36:33AM -0700, Lists wrote:
*Slony-I* - I've used this in the past, but it's a huge pain to work
with, caused serious performance issues under heavy load due to long
running transactions (may not be the case anymore, it's been a while
I am looking to setup replication of my postgresql database, primarily
for performance reasons.
The searching I've done shows a lot of different options, can anyone
give suggestions about which one(s) are best? I've read the archives,
but there seems to be more replication solutions since the
I have a high traffic database with high volumes of reads, and moderate
volumes of writes. Millions of queries a day.
Running the latest version of Postgresql 8.2.x (I want to upgrade to
8.3, but the dump/reload requires an unacceptable amount of downtime)
Server is a dual core xeon 3GB ram
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Running the latest version of Postgresql 8.2.x (I want to upgrade to
8.3, but the dump/reload requires an unacceptable amount of downtime)
You can use Slony or Bucardo to ugrade in place. Both will incur some
overhead and more overall
16 matches
Mail list logo
