On Tue, Apr 1, 2008 at 1:33 PM, Henry <henry at zen.co.za> wrote:
> Good morning all,
>
> I seem to recall (I think it was touched on by someone else) that this
> aspect *might* be addressed in a near-future version of slony:
>
> Given that some users of slony have large (your definition of large will
> vary, but let's say DBs in excess of 100GB) databases, and that the
> initial replication of a DB can take weeks, would it not be a great idea
> to have a more efficient initial 'copy' mode?  ie, either allow a user to
> dump/restore to all slaves, then start replication from that point
> (without truncating/copying/etc), or, build this functionality into slony
> so it does the dump/restore, but does not then truncate all tables and
> start from scratch?
>
> For smaller DBs this doesn't present a problem, but for larger DDs coupled
> with LARGE clusters, this is a major problem.

I would love this too. My use case is the daily building of a staging
database from a dump of our production database. The pg_restore takes
1.5 hours. Now we are adding replication into the equation, and this
is going to add a further 3 hours to the process. The end result is
for nearly 20% of the day the staging server is running with 1 core
tied behind its back as it rebuilds. Previously, this was a more
manageable 6-7%. Ideally, I would pg_restore both master and slave
staging databases simultaneously from the same dump and then setup the
replication sets without the redundant data copying. The proposed
CLONE commands are not suitable for this use case.

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/