Re: Migrating a live database

You don't need a lot of additional space to run pg_start_backup(). Read
following:
http://www.postgresql.org/docs/8.3/interactive/continuous-archiving.html (see
24.3.2)

On Tue, Jan 18, 2011 at 10:49 AM, Vladislav Geller <
vladislav(dot)geller(at)vincorex(dot)ch> wrote:

> HI,
>
> The problem with this solution is that i don't have enough space on the
> targeted live to implement such a procedure. It would have to work by
> pulling data directly off the live server. The issue with new data whilst
> the procedure is running (over a span of days or weeks in not severe as each
> daily activity generates new tables)
>
> As someone else mentioned - I am against implementing any kind of
> replication as the live server will only have a subset of the data after i'm
> migrating thus making replication useless. And i also don't have the
> bandwidth to pull out the data in one day.
>
> Regards,
>
> Vladislav Geller
>
>
> On Jan 18, 2011, at 8:39 AM, Vladimir Rusinov wrote:
>
>
>
> On Tue, Jan 18, 2011 at 8:07 AM, Vladislav Geller <
> vladislav(dot)geller(at)vincorex(dot)ch> wrote:
>
>> Hello,
>>
>> I'm currently in the process of migrating a huge live database from one
>> part of the world to the other (for local use and data analysis). The
>> bandwidth does not allow me to get a decent transfer speed. Furthermore i
>> can not migrate during business hours since the connection is critical. This
>> leaves me with a timeframe of 9 hours a day where i can migrate this
>> database. Does anyone have experience he is willing to share in respect how
>> to migrate such databases?
>>
>
> run pg_start_backup() and use rsync on live data files to transfer them.
> If sync won't finish in 9 hours, abort it, run pg_stop_backup() and
> continue next day - I assume most of the data won't change, so rsync won't
> re-transfer it (but will calculate hash and compare).
>
> --
> Vladimir Rusinov
> http://greenmice.info/
>
>
>

--
Vladimir Rusinov
http://greenmice.info/