Subject: Re: Database migration across different operating systems
To: pgsql-admin@lists.postgresql.org
References: <A740E5D2-34BE-46AA-A9FE-50F510E771EC@gmail.com>
From: Achilleas Mantzios <achill@matrix.gatewaynet.com>
Message-ID: <1f5d9299-2924-e481-7988-326f07d4af0c@matrix.gatewaynet.com>
Date: Tue, 8 Jan 2019 11:05:30 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101
 Thunderbird/60.3.2
MIME-Version: 1.0
In-Reply-To: <A740E5D2-34BE-46AA-A9FE-50F510E771EC@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

Hello,
On 8/1/19 6:51 π.μ., Natalie Wenz wrote:
> We are in an unusual circumstance, where we need to move all of our Postgres 10 databases from their homes on servers running FreeBSD 11 with ZFS to servers in another data center running Red Hat Linux 7.6 (also with ZFS), with minimal downtime.
any technical reason behind the switch to linux?
>
> I understand that the recommended, safest, approach would be to dump/restore. We intend to do that wherever possible.
>
> However, we have some databases that require high availability/minimal downtime that are also very large. (50 TB, for example)
>
> Because we use ZFS on all of our current FreeBSD database hosts, one idea that we are exploring is to use filesystem replication to move the data ahead of time, and keep it in sync. Then we could start the databases on the Linux hosts at any time and it would be up to date. With that option, there’s almost no downtime.
Not at any time, you should :
- pause (all) the application(s)/service(s) accessing the DB
- stop the filesystem replication
- start the new cluster
- point the apps/services to the new server
- resume the apps/services
So, you should not start the new cluster with the filesystem replication still active.

There are many other solutions as well, you should give logical replication a try. But you have to test first on a similar sized db with similar sized tables, ideally with a copy of the production db. 
Some tuning might be needed.
>
> We’ve tested this procedure on a small database, and it starts, it runs, returns queries. There seems to be no issues.
>
> Is this a reasonable approach? Are there any known concerns/things to investigate before choosing this course?
>
> If it helps:
> The cpu architecture is the same on both hosts, and we’ll be running Postgres with the same version and same build options.
>
> Many thanks,
> Natalie


-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt