Re: [GENERAL] Migrate 2 DB's - v8.3
Martin: Could you please avoid unedited top posts? On Sat, May 28, 2016 at 7:53 PM, Martín Marquéswrote: > 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 thing is trying to find the fastest way to move a single database between two clusters on different machines, or trying to find a way to do it without downtime, is useful on its own, whicever the versions are. > All this hassle to stay on an unsupported postgres is just useless, IMNSHO. You can ask the OP for the reason to stay in 8.3 directly. Maybe is something as simple as "I'm the one who pays, you do what I pay you for.". I've had several of these. Francisco Olarte. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Migrate 2 DB's - v8.3
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, May 28, 2016 at 12:38 AM, Jeff Baldwinwrote: >> 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 MAY get a little more speed if you > run pg_dump AND psql each in the same host as the DB it's operating on > to minimize latency ( and I would time unix socket vs network first in > case it differs ). ( to do that I would try something like 'ssh dbms11 > "pg_dump mls11 " | psql -d mls11' with all the needed doodahs, and > maybe use something like netcat or socat instead of ssh ). The > rationale being the intermediate dump is just a data stream and not > latency sensitive ( except for the window*latency problem, but you are > not going to hit that on a LAN ), while the dump/restore does DB work > which is more latency sensitive ( I do not know how many RTTs it would > need, specially with blobs, but you can try it ). > > ¿ How many hours does it take in your tests? Because if you have 1-2 > and you can do the dump psql pipe trick, which is quite robust, in 3-4 > you may push for it ( arguing it's a simpler an more testable process > ). > > Francisco Olarte. > > -- Martín Marquéshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Migrate 2 DB's - v8.3
Jeff: On Sat, May 28, 2016 at 12:38 AM, Jeff Baldwinwrote: > 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 MAY get a little more speed if you run pg_dump AND psql each in the same host as the DB it's operating on to minimize latency ( and I would time unix socket vs network first in case it differs ). ( to do that I would try something like 'ssh dbms11 "pg_dump mls11 " | psql -d mls11' with all the needed doodahs, and maybe use something like netcat or socat instead of ssh ). The rationale being the intermediate dump is just a data stream and not latency sensitive ( except for the window*latency problem, but you are not going to hit that on a LAN ), while the dump/restore does DB work which is more latency sensitive ( I do not know how many RTTs it would need, specially with blobs, but you can try it ). ¿ How many hours does it take in your tests? Because if you have 1-2 and you can do the dump psql pipe trick, which is quite robust, in 3-4 you may push for it ( arguing it's a simpler an more testable process ). Francisco Olarte. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Migrate 2 DB's - v8.3
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 dumping and importing (in either direction -- either merge existing target dbs into the rsync'ed cluster or vice versa). My original suggestion would transfer the original cluster as-is to the target machine into an empty directory, and create a new (possibly additional) postgresql instance on the target. In Ubuntu (and I guess in CentOS as well) there is built-in support for multiple clusters (instances) on a single host (see pg_lsclusters or pg_ctlcluster). Every cluster will listen on a different port. This enables (but also forces) per-cluster management of replication, backup and upgrades. However, that approach might not scale well and tuning memory/io settings might be more difficult than with a single cluster on the DB host. > Perhaps I could stand up a 2nd postgres instance on the target > server, and move the data there first? Then it would at least be on > the same box/storage. Then I could pg_dump/pgrestore the 2 DB's I > need into the production cluster, and shutdown the 2nd instance on > the target server. That would be an option, but consider that in this case the IO subsystem of the target server would have to read and write your data at the same time. Unless you have source and target clusters on independent spindles or a really slow source server, this will possibly take even longer than to pipe the data over your GBIT network connection. Best regards, -hannes -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Migrate 2 DB's - v8.3
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 postgres instance on the target server, and move the data there first? Then it would at least be on the same box/storage. Then I could pg_dump/pgrestore the 2 DB's I need into the production cluster, and shutdown the 2nd instance on the target server. Or is that not necessary? Just some thoughts... Jeff On Fri, May 27, 2016 at 6:41 PM Hannes Ervenwrote: > 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 > - drop unwanted databases in target > > That way you could have minimal downtime (seconds to minutes) at the > expense of temporary disk usage on the target host. > Additional bonus: it's all standard Postgres tools (in contrast to e.g. a > fancy trigger-based replication) and will also keep any statistics and > analyzes. > > > > Best regards, > > -hannes > > > > > Am 27. Mai 2016 23:23:04 MESZ, schrieb Jeff Baldwin >: > >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 rsync of only the 2 DB's in > >question. Then stop the source DB and sync only the delta to the > >target, > >or something along those lines.I've also been looking at barman and > >Slony to see if they might fit the bill as well. > > > >Thanks again for the replies. > > > >Jeff > > > >On Fri, May 27, 2016 at 5:18 PM Melvin Davidson > >wrote: > > > >> > >> > >> 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 Regards, > >>> Jeff > >>> > >>> On Fri, May 27, 2016 at 5:05 PM Melvin Davidson > > > >>> wrote: > >>> > > 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, and I was able > >to > > use pg_dump/pgrestore for those, and it worked fine. These final > >2 are > > live DB's, and I need to move them with minimal downtime (1-2hrs > >is > > acceptable). > > > > The DB's are blob DB's that are 45 and 90G in size, and are in the > >same > > Data Center, with 1G connection in between > > > > I am running postres 8.3 (I know :) ), so there may be some > >limitations > > there as well. > > > > Any help/guidance on the best way to approach this, are greatly > > appreciated. > > > > Kind Regards, > > Jeff > > > > Well generically speaking, since you are migrating from 8.3, you > >are > limited to pg_dump in plain format. > It would be nice (important) to know the PostgreSQL version you are > migrating to, as well as what O/S you are working with. > > > -- > *Melvin Davidson* > I reserve the right to fantasize. Whether or not you > wish to share my fantasy is entirely up to you. > > >>> > >> OK, well since both PostgreSQL versions are the same, then you can > >use > >> custom format. > >> > >> I would first by creating a testdb in the target server. Then export > >one > >> small table in customer format and verify that you can use pg_restore > >to > >> load to > >> the testdb. If that works, time how long a full dump takes in the old > >> server as a start point. Then time how long it takes to do a full > >load into > >> testdb. > >> You will then know how big of a window you need for migrating. > >> > >> -- > >> *Melvin Davidson* > >> I reserve the right to fantasize. Whether or not you > >> wish to share my fantasy is entirely up to you. > >> > >
Re: [GENERAL] Migrate 2 DB's - v8.3
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 - drop unwanted databases in target That way you could have minimal downtime (seconds to minutes) at the expense of temporary disk usage on the target host. Additional bonus: it's all standard Postgres tools (in contrast to e.g. a fancy trigger-based replication) and will also keep any statistics and analyzes. Best regards, -hannes Am 27. Mai 2016 23:23:04 MESZ, schrieb Jeff Baldwin: >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 rsync of only the 2 DB's in >question. Then stop the source DB and sync only the delta to the >target, >or something along those lines.I've also been looking at barman and >Slony to see if they might fit the bill as well. > >Thanks again for the replies. > >Jeff > >On Fri, May 27, 2016 at 5:18 PM Melvin Davidson >wrote: > >> >> >> 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 Regards, >>> Jeff >>> >>> On Fri, May 27, 2016 at 5:05 PM Melvin Davidson > >>> wrote: >>> 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, and I was able >to > use pg_dump/pgrestore for those, and it worked fine. These final >2 are > live DB's, and I need to move them with minimal downtime (1-2hrs >is > acceptable). > > The DB's are blob DB's that are 45 and 90G in size, and are in the >same > Data Center, with 1G connection in between > > I am running postres 8.3 (I know :) ), so there may be some >limitations > there as well. > > Any help/guidance on the best way to approach this, are greatly > appreciated. > > Kind Regards, > Jeff > Well generically speaking, since you are migrating from 8.3, you >are limited to pg_dump in plain format. It would be nice (important) to know the PostgreSQL version you are migrating to, as well as what O/S you are working with. -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you. >>> >> OK, well since both PostgreSQL versions are the same, then you can >use >> custom format. >> >> I would first by creating a testdb in the target server. Then export >one >> small table in customer format and verify that you can use pg_restore >to >> load to >> the testdb. If that works, time how long a full dump takes in the old >> server as a start point. Then time how long it takes to do a full >load into >> testdb. >> You will then know how big of a window you need for migrating. >> >> -- >> *Melvin Davidson* >> I reserve the right to fantasize. Whether or not you >> wish to share my fantasy is entirely up to you. >> -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Migrate 2 DB's - v8.3
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 not a DBA, just trying to pretend to be one for this project). Can you elaborate on what might I need to do there? Kind Regards, Jeff On Fri, May 27, 2016 at 6:05 PM Alan Hodgsonwrote: > 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 probably take a long > time > > to > > replicate, but then you have the option to promote the slave at your time > > preference (IE: your 2 hr window). It should only take a few minutes for > > Slony to do the switchover, but the best thing to do is a dry run first. > > IOW, you'll have to do the whole thing twice to get an accurate switch > time, > > but you won't need to change your network until you are ready to go live. > > Slony doesn't do BLOBs, afaik, unless he's using BYTEA fields. > > Otherwise I believe dump/reload is OP's only choice. He should be able to > do > 90GB in 2 hours on fast enough hardware; just pipe it over the network to > do > the restore simultaneous with the dump. > > Also remove as many indexes as possible beforehand and use create > concurrently > manually afterwards to add them back in. > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
Re: [GENERAL] Migrate 2 DB's - v8.3
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 probably take a long time > to > replicate, but then you have the option to promote the slave at your time > preference (IE: your 2 hr window). It should only take a few minutes for > Slony to do the switchover, but the best thing to do is a dry run first. > IOW, you'll have to do the whole thing twice to get an accurate switch time, > but you won't need to change your network until you are ready to go live. Slony doesn't do BLOBs, afaik, unless he's using BYTEA fields. Otherwise I believe dump/reload is OP's only choice. He should be able to do 90GB in 2 hours on fast enough hardware; just pipe it over the network to do the restore simultaneous with the dump. Also remove as many indexes as possible beforehand and use create concurrently manually afterwards to add them back in. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Migrate 2 DB's - v8.3
On Fri, May 27, 2016 at 5:23 PM, Jeff Baldwinwrote: > 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 rsync of only the 2 DB's in > question. Then stop the source DB and sync only the delta to the target, > or something along those lines.I've also been looking at barman and > Slony to see if they might fit the bill as well. > > Thanks again for the replies. > > Jeff > > On Fri, May 27, 2016 at 5:18 PM Melvin Davidson > wrote: > >> >> >> 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 Regards, >>> Jeff >>> >>> On Fri, May 27, 2016 at 5:05 PM Melvin Davidson >>> wrote: >>> 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, and I was able to > use pg_dump/pgrestore for those, and it worked fine. These final 2 are > live DB's, and I need to move them with minimal downtime (1-2hrs is > acceptable). > > The DB's are blob DB's that are 45 and 90G in size, and are in the > same Data Center, with 1G connection in between > > I am running postres 8.3 (I know :) ), so there may be some > limitations there as well. > > Any help/guidance on the best way to approach this, are greatly > appreciated. > > Kind Regards, > Jeff > Well generically speaking, since you are migrating from 8.3, you are limited to pg_dump in plain format. It would be nice (important) to know the PostgreSQL version you are migrating to, as well as what O/S you are working with. -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you. >>> >> OK, well since both PostgreSQL versions are the same, then you can use >> custom format. >> >> I would first by creating a testdb in the target server. Then export one >> small table in customer format and verify that you can use pg_restore to >> load to >> the testdb. If that works, time how long a full dump takes in the old >> server as a start point. Then time how long it takes to do a full load into >> testdb. >> You will then know how big of a window you need for migrating. >> >> -- >> *Melvin Davidson* >> I reserve the right to fantasize. Whether or not you >> wish to share my fantasy is entirely up to you. >> > 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 probably take a long time to replicate, but then you have the option to promote the slave at your time preference (IE: your 2 hr window). It should only take a few minutes for Slony to do the switchover, but the best thing to do is a dry run first. IOW, you'll have to do the whole thing twice to get an accurate switch time, but you won't need to change your network until you are ready to go live. -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
Re: [GENERAL] Migrate 2 DB's - v8.3
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 rsync of only the 2 DB's in question. Then stop the source DB and sync only the delta to the target, or something along those lines.I've also been looking at barman and Slony to see if they might fit the bill as well. Thanks again for the replies. Jeff On Fri, May 27, 2016 at 5:18 PM Melvin Davidsonwrote: > > > 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 Regards, >> Jeff >> >> On Fri, May 27, 2016 at 5:05 PM Melvin Davidson >> wrote: >> >>> >>> 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, and I was able to use pg_dump/pgrestore for those, and it worked fine. These final 2 are live DB's, and I need to move them with minimal downtime (1-2hrs is acceptable). The DB's are blob DB's that are 45 and 90G in size, and are in the same Data Center, with 1G connection in between I am running postres 8.3 (I know :) ), so there may be some limitations there as well. Any help/guidance on the best way to approach this, are greatly appreciated. Kind Regards, Jeff >>> >>> Well generically speaking, since you are migrating from 8.3, you are >>> limited to pg_dump in plain format. >>> It would be nice (important) to know the PostgreSQL version you are >>> migrating to, as well as what O/S you are working with. >>> >>> >>> -- >>> *Melvin Davidson* >>> I reserve the right to fantasize. Whether or not you >>> wish to share my fantasy is entirely up to you. >>> >> > OK, well since both PostgreSQL versions are the same, then you can use > custom format. > > I would first by creating a testdb in the target server. Then export one > small table in customer format and verify that you can use pg_restore to > load to > the testdb. If that works, time how long a full dump takes in the old > server as a start point. Then time how long it takes to do a full load into > testdb. > You will then know how big of a window you need for migrating. > > -- > *Melvin Davidson* > I reserve the right to fantasize. Whether or not you > wish to share my fantasy is entirely up to you. >
Re: [GENERAL] Migrate 2 DB's - v8.3
On Fri, May 27, 2016 at 5:09 PM, Jeff Baldwinwrote: > 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 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, and I was able to >>> use pg_dump/pgrestore for those, and it worked fine. These final 2 are >>> live DB's, and I need to move them with minimal downtime (1-2hrs is >>> acceptable). >>> >>> The DB's are blob DB's that are 45 and 90G in size, and are in the same >>> Data Center, with 1G connection in between >>> >>> I am running postres 8.3 (I know :) ), so there may be some limitations >>> there as well. >>> >>> Any help/guidance on the best way to approach this, are greatly >>> appreciated. >>> >>> Kind Regards, >>> Jeff >>> >> >> Well generically speaking, since you are migrating from 8.3, you are >> limited to pg_dump in plain format. >> It would be nice (important) to know the PostgreSQL version you are >> migrating to, as well as what O/S you are working with. >> >> >> -- >> *Melvin Davidson* >> I reserve the right to fantasize. Whether or not you >> wish to share my fantasy is entirely up to you. >> > OK, well since both PostgreSQL versions are the same, then you can use custom format. I would first by creating a testdb in the target server. Then export one small table in customer format and verify that you can use pg_restore to load to the testdb. If that works, time how long a full dump takes in the old server as a start point. Then time how long it takes to do a full load into testdb. You will then know how big of a window you need for migrating. -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
Re: [GENERAL] Migrate 2 DB's - v8.3
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 Davidsonwrote: > > 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, and I was able to use >> pg_dump/pgrestore for those, and it worked fine. These final 2 are live >> DB's, and I need to move them with minimal downtime (1-2hrs is acceptable). >> >> The DB's are blob DB's that are 45 and 90G in size, and are in the same >> Data Center, with 1G connection in between >> >> I am running postres 8.3 (I know :) ), so there may be some limitations >> there as well. >> >> Any help/guidance on the best way to approach this, are greatly >> appreciated. >> >> Kind Regards, >> Jeff >> > > Well generically speaking, since you are migrating from 8.3, you are > limited to pg_dump in plain format. > It would be nice (important) to know the PostgreSQL version you are > migrating to, as well as what O/S you are working with. > > > -- > *Melvin Davidson* > I reserve the right to fantasize. Whether or not you > wish to share my fantasy is entirely up to you. >
Re: [GENERAL] Migrate 2 DB's - v8.3
On Fri, May 27, 2016 at 4:56 PM, Jeff Baldwinwrote: > 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 are live > DB's, and I need to move them with minimal downtime (1-2hrs is acceptable). > > The DB's are blob DB's that are 45 and 90G in size, and are in the same > Data Center, with 1G connection in between > > I am running postres 8.3 (I know :) ), so there may be some limitations > there as well. > > Any help/guidance on the best way to approach this, are greatly > appreciated. > > Kind Regards, > Jeff > Well generically speaking, since you are migrating from 8.3, you are limited to pg_dump in plain format. It would be nice (important) to know the PostgreSQL version you are migrating to, as well as what O/S you are working with. -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
[GENERAL] Migrate 2 DB's - v8.3
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 are live DB's, and I need to move them with minimal downtime (1-2hrs is acceptable). The DB's are blob DB's that are 45 and 90G in size, and are in the same Data Center, with 1G connection in between I am running postres 8.3 (I know :) ), so there may be some limitations there as well. Any help/guidance on the best way to approach this, are greatly appreciated. Kind Regards, Jeff