From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Michael Paquier <michael(at)paquier(dot)xyz>, Julie Nishimura <juliezain(at)hotmail(dot)com> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: upgrade and migrate |
Date: | 2019-12-04 15:26:33 |
Message-ID: | 089b4bfb-9f92-d0f8-77ea-a59e49ed31a5@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2019-12-04 08:56, Laurenz Albe wrote:
> On Wed, 2019-12-04 at 13:48 +0900, Michael Paquier wrote:
>> On Tue, Dec 03, 2019 at 10:32:22PM +0000, Julie Nishimura wrote:
>>> Hello, what is the best way to migrate from PostgreSQL 8.3.11 on
>>> x86_64-redhat-linux-gnu to PostgreSQL 9.6.16 on x86_64-pc-linux-gnu
>>> server, with minimal downtime?
>>> The caveat is the source has about 80 databases overall almost 30
>>> TB. I could migrate the smallest ones (up to 1 tb) using pg_dump and
>>> pg_restore, but the largest hot database is almost 17 tb, and I am
>>> not sure how to approach this effort in a better and efficient way?
>>
>> pg_upgrade could be one way to go here. That's not the scale pg_dump
>> would be very good at. I would have personally avoided using pg_dump
>> above 10~20GB. Depending on the downtime you are ready to accept,
>> a migration based on Slony could be something to investigate.
>
> Right, Slony is the way to go, since pg_upgrade doesn't support 8.3.
Also consider Londiste.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Zwettler Markus (OIZ) | 2019-12-04 16:49:13 | archiving question |
Previous Message | Stephen Frost | 2019-12-04 13:31:04 | Re: secure deletion of archived logs |