Martin:
Could you please avoid unedited top posts?
On Sat, May 28, 2016 at 7:53 PM, Martín Marqués wrote:
> I still don't understand why the OP is getting into so much trouble and
> doesn't upgrade to a newer version like 9.3 or 9.4 (or even 9.5).
Neither do I, but the
I still don't understand why the OP is getting into so much trouble and
doesn't upgrade to a newer version like 9.3 or 9.4 (or even 9.5).
All this hassle to stay on an unsupported postgres is just useless, IMNSHO.
Regards,
El 28/05/16 a las 12:26, Francisco Olarte escribió:
> Jeff:
>
> On Sat,
Jeff:
On Sat, May 28, 2016 at 12:38 AM, Jeff Baldwin wrote:
> Thank you for your time Alan.
..
> To move the DB, you are suggesting something like this:
> pg_dump -h dbms11 -U postgres -C mls11 | psql -h localhost -d mls11 -U
> postgres
I'd like to point one thing, you
Hi Jeff,
> Thank you for the message. --- I like your idea, but one thing I
> forgot to mention is that my target postgres cluster has production
> DB's running on it already.
Oh, that's important information.
The only way to "merge" additional databases into an existing cluster
would be
Hannes,
Thank you for the message. --- I like your idea, but one thing I forgot to
mention is that my target postgres cluster has production DB's running on
it already. I think your solution would overwrite those? Or cause any
other issues on the target side?
Perhaps I could stand up a 2nd
Jeff,
is (temporarily) migrating the whole cluster an option? What I have in mind is
roughly this:
- rsync/copy complete db dir to target (with src still being in production),
throttle/repeat as necessary
- stop source db
- rsync again
- start src + target dbs
- drop moved databases in src
-
Thank you for your time Alan.
I'd like to confirm my understanding of your statement, and ask a question.
To move the DB, you are suggesting something like this:
pg_dump -h dbms11 -U postgres -C mls11 | psql -h localhost -d mls11 -U
postgres
I'm not familiar with removing/adding indexes (I'm
On Friday, May 27, 2016 05:32:08 PM Melvin Davidson wrote:
> Well, Slony certainly will do the trick.
> Keep in mind you will need to do schema only first to the slave.
> You set up replication from the old server with the db on the new server as
> the slave. Then you initiate replication. It will
On Fri, May 27, 2016 at 5:23 PM, Jeff Baldwin wrote:
> Thanks Melvin.
>
> I have done just this, and the time required to dump/restore in this
> manner far exceeds the outage window we can afford to have (max of 2hrs).
> I am looking for alternatives to the standard
Thanks Melvin.
I have done just this, and the time required to dump/restore in this manner
far exceeds the outage window we can afford to have (max of 2hrs). I am
looking for alternatives to the standard dump/restore that might help me
save time.
For instance... if I could do a continuous
On Fri, May 27, 2016 at 5:09 PM, Jeff Baldwin wrote:
> Melvin,
>
> Thank you for taking the time to reply to my question.
>
> Below are the details you have requested:
>
> SOURCE:
> CentOS release 4.6
> Postgres 8.3
>
> TARGET:
> CentOS release 6.2
> Postgres 8.3
>
> Kind
Melvin,
Thank you for taking the time to reply to my question.
Below are the details you have requested:
SOURCE:
CentOS release 4.6
Postgres 8.3
TARGET:
CentOS release 6.2
Postgres 8.3
Kind Regards,
Jeff
On Fri, May 27, 2016 at 5:05 PM Melvin Davidson
wrote:
>
> On
On Fri, May 27, 2016 at 4:56 PM, Jeff Baldwin wrote:
> Hello,
>
> I am working to migrate 2 DB's (not the entire postgres instance), from 1
> host to another... and I need some guidance on the best approach/practice.
>
> I have migrated ~25 other DB's in this environment,
Hello,
I am working to migrate 2 DB's (not the entire postgres instance), from 1
host to another... and I need some guidance on the best approach/practice.
I have migrated ~25 other DB's in this environment, and I was able to use
pg_dump/pgrestore for those, and it worked fine. These final 2
14 matches
Mail list logo