Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ggnee-0005YR-U5 for pgsql-admin@arkaria.postgresql.org; Tue, 08 Jan 2019 09:26:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ggnec-0003Zh-Cs for pgsql-admin@arkaria.postgresql.org; Tue, 08 Jan 2019 09:26:34 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ggnec-0003ZZ-5Z for pgsql-admin@lists.postgresql.org; Tue, 08 Jan 2019 09:26:34 +0000 Received: from hermes.gatewaynet.com ([193.92.121.98]) by magus.postgresql.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ggneW-0000iK-32 for pgsql-admin@lists.postgresql.org; Tue, 08 Jan 2019 09:26:33 +0000 Received: from smadev.internal.net (pc131.internal.net [10.9.200.131]) by hermes.gatewaynet.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id x089QLXd030961 for ; Tue, 8 Jan 2019 11:26:26 +0200 Received: from smadev.internal.net (smadev [10.9.200.131]) by smadev.internal.net (8.15.2/8.15.2) with ESMTP id x089QLR8033598 for ; Tue, 8 Jan 2019 11:26:21 +0200 (EET) (envelope-from achill@matrix.gatewaynet.com) Subject: Re: Database migration across different operating systems To: pgsql-admin@lists.postgresql.org References: <20190108090144.rdrtfh6wznoolsww@office.hexack.fr> From: Achilleas Mantzios Message-ID: <3eef1017-ce4a-5c4a-0217-ff69d705e38f@matrix.gatewaynet.com> Date: Tue, 8 Jan 2019 11:26:21 +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: <20190108090144.rdrtfh6wznoolsww@office.hexack.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.98.7 at hermes X-Virus-Status: Clean X-Spam-Status: No, score=-28.0 required=5.0 tests=ALL_TRUSTED,DYN_HAM_COORD, DYN_HAM_IT,DYN_HAM_NAUTICAL,DYN_HAM_SIGNAT1 autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on hermes.gatewaynet.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 8/1/19 11:01 π.μ., Stéphane KANSCHINE wrote: > Hey ! > > Le lun. 7 janv., vers 22:51, Natalie Wenz exprimait : >> 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. >> >> I understand that the recommended, safest, approach would be to >> dump/restore. We intend to do that wherever possible. > It's not anymore since PostgreSQL have logical replication. You can > initialize you FreeBSD cluster with a pg_basebackup and you follow > updates with logical streaming. Hmm, maybe you mean pg_dump --schema-only? I cannot see how taking physical copy with pg_basebackup will help with logical replication. Logical replication has its own initial snapshot phase. Doing a pg_basebackup would work if followed by truncating all tables, but that's duplicate work and equivalent to pg_dumpall --schema-only | psql -f - > >> However, we have some databases that require high >> availability/minimal downtime that are also very large. (50 TB, for >> example) > With logical replication, is it's permanently up to date in > miliseconds, you can switch when you want. > >> 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. > Your OS or cpu architecture doesn't matter, really :-) > > Regards, -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt