Re: Strategy for moving a large DB to another machine with least possible down-time

På søndag 21. september 2014 kl. 16:10:54, skrev Adrian Klaver <
adrian(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)com>>: On 09/21/2014
06:50 AM, Andreas Joseph Krogh wrote:
> På søndag 21. september 2014 kl. 15:48:00, skrev Adrian Klaver
> <adrian(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)com>>:
>
>     On 09/21/2014 05:44 AM, Andreas Joseph Krogh wrote:
>      > På søndag 21. september 2014 kl. 13:51:00, skrev Bill Moran
>      > <wmoran(at)potentialtech(dot)com <mailto:wmoran(at)potentialtech(dot)com>>:
>      >
>
>      >
>      > I see this limitation in Slyny:
>      > http://slony.info/documentation/2.2/limitations.html
>      >
>      > Slony-I does not automatically replicate
>      >
>      >   *
>      >
>      >     Changes to large objects (BLOBS)
>      >
>      >   *
>      >
>      >     Changes made by DDL commands
>      >
>      >   *
>      >
>      >     Changes to users and roles
>      >
>      > Not being able to replicate BLOBS is a show-stopper for me as we have
>      > lots of them.
>
>     Well I would say it depends on where you are storing the binary data, in
>     large objects or in a bytea column?  If you are using bytea columns then
>     you would be okay. If it is large objects then you have a problem.
>
> Large-objects, not BYTEA, as they allow for much more efficient
> streaming (require less memory).

Here are some other suggestions from the project, though they are
cluster wide(including PITR):

http://www.postgresql.org/docs/9.3/static/backup-file.html   I think the
rsync-approach is the most attractive option.   -- Andreas Joseph Krogh CTO /
Partner - Visena AS Mobile: +47 909 56 963 andreas(at)visena(dot)com
<mailto:andreas(at)visena(dot)com> www.visena.com <https://www.visena.com>
<https://www.visena.com>