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 1ggst2-00027e-O8 for pgsql-admin@arkaria.postgresql.org; Tue, 08 Jan 2019 15:01:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ggst1-0004uQ-HX for pgsql-admin@arkaria.postgresql.org; Tue, 08 Jan 2019 15:01:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ggsQW-0004Yf-8B for pgsql-admin@lists.postgresql.org; Tue, 08 Jan 2019 14:32:20 +0000 Received: from mail-it1-x144.google.com ([2607:f8b0:4864:20::144]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ggsQT-0003ft-AG for pgsql-admin@lists.postgresql.org; Tue, 08 Jan 2019 14:32:18 +0000 Received: by mail-it1-x144.google.com with SMTP id h193so6186800ita.5 for ; Tue, 08 Jan 2019 06:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H66P61DeCOLj0JLqWdAzM37R5OnyJ7gYxSoQ9Ujtjt8=; b=SnbY7L3sSIIU5dKQ9Fnp7Df6o0O8kSK8JuqH69J35VLDjQDVra15EI3evJq/V39rVp 2C/zYX5wVJB8c5scfK8jkRtJPmpgA6A2DjDGAPQdES/lbF+6ttM9k8PN3LeWhtFV6xeP baSscR/9rxFHtk7PTkIRxXM33ei6Wy0kj8ymwjpJ1X1WdjL6Bw3YDfUitjoQ1FJRkYyv QeXZbhdUO3eNidscQrpmDe8l1M7cXWIkTHxA80js1q3hDlXfLt1+r8OTLK2EhvNMI9Wj ZD3rLRsMBbGrNS118mDibNBB3GYkcvecKHR3gmRRGtYqb5Pf3YsbL+8NSvjxOauI5Cmr LlWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H66P61DeCOLj0JLqWdAzM37R5OnyJ7gYxSoQ9Ujtjt8=; b=KbByD2MrEyp3tfYPpRZYKdmwCPmjc4Hs+ayyCWLD/C0z4Tv+aM57Lednk0n0wgYE1s 2rDKjSaRFfspfH5vPp2oe8qZsK0VkbqEUsbK/D0ir9Z0tpiXlodXddCy8VBd6LrM9vzZ t0qydlt9frmqyJN9ItUNNXuGmqXj3T3S9lpMMpOI5sdTbv1MD4ZYQkYvBj/Jgb+rjRH/ 8CCtLs5gIxMa08jWZ/KIrNPdPOmMMdbKXYkCyoc3CdTLuB4KvPnnw9a04KvO2enbtHqo b6l0WP2wQQuJiBu0vbni3kQaT6CDxL2X6iSPJYzxrfiVfuBGI2nqpfCWFs2xYIH+r8eC Syag== X-Gm-Message-State: AJcUukey37iZRFoUNXrNFgXU+DXblTeQwPQRwFRHBc4ToV8Glnju43/x Bxdk4umK1kpVmaVapWZtoV1sZIIj X-Google-Smtp-Source: ALg8bN7cj8xTHmcfH9Nb5iK7Gdnr9RGia1zfo6pfcKZA8Jki/lDfw8OxoYNhwPmZJKaHZ7QkU7+cTw== X-Received: by 2002:a02:ac8c:: with SMTP id x12mr1109884jan.72.1546957936341; Tue, 08 Jan 2019 06:32:16 -0800 (PST) Received: from [172.16.3.133] ([67.148.93.60]) by smtp.gmail.com with ESMTPSA id l186sm4812878itl.22.2019.01.08.06.32.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jan 2019 06:32:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Database migration across different operating systems From: Natalie Wenz X-Mailer: iPhone Mail (16C101) In-Reply-To: <20190108090144.rdrtfh6wznoolsww@office.hexack.fr> Date: Tue, 8 Jan 2019 08:32:12 -0600 Cc: pgsql-admin@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <2862230A-6B04-42F0-83EE-D079AD0236A8@gmail.com> References: <20190108090144.rdrtfh6wznoolsww@office.hexack.fr> To: =?utf-8?Q?St=C3=A9phane_KANSCHINE?= List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I thought about logical replication, but it seems that the initial sync is j= ust a plain copy for each table, which will get us into xid trouble on the p= ublisher side while large tables copy. Unless someone can say conclusively t= hat the copy does NOT hold an xid open that would prevent autovacuums from c= ompleting on the publisher.=20 Then of course there=E2=80=99s the excitement of having to freeze everything= on the subscriber side, which can take weeks.=20 > On Jan 8, 2019, at 3:01 AM, St=C3=A9phane KANSCHINE w= rote: >=20 >=20 > Hey ! >=20 > Le lun. 7 janv., vers 22:51, Natalie Wenz exprimait : >>=20 >> 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.=20 >>=20 >> I understand that the recommended, safest, approach would be to >> dump/restore. We intend to do that wherever possible.=20 >=20 > 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. >=20 >> However, we have some databases that require high >> availability/minimal downtime that are also very large. (50 TB, for >> example) >=20 > With logical replication, is it's permanently up to date in > miliseconds, you can switch when you want. >=20 >> If it helps: The cpu architecture is the same on both hosts, and >> we=E2=80=99ll be running Postgres with the same version and same build >> options.=20 >=20 > Your OS or cpu architecture doesn't matter, really :-) >=20 > Regards, > --=20 > St=C3=A9phane KANSCHINE - https://www.hexack.fr./ - https://www.nuajik.io.= / > =EF=BC=A0 stephane@hexack.fr > =EE=88=81 +33 6 64 31 72 52