Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sdqAS-001Su2-9f for pgsql-general@arkaria.postgresql.org; Tue, 13 Aug 2024 11:58:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sdqAQ-003Kbv-Jq for pgsql-general@arkaria.postgresql.org; Tue, 13 Aug 2024 11:58:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sdqAQ-003Kbn-8u for pgsql-general@lists.postgresql.org; Tue, 13 Aug 2024 11:58:22 +0000 Received: from mail-oo1-xc33.google.com ([2607:f8b0:4864:20::c33]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sdqAN-004e4r-HK for pgsql-general@postgresql.org; Tue, 13 Aug 2024 11:58:21 +0000 Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-5d5c324267aso3175786eaf.0 for ; Tue, 13 Aug 2024 04:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723550296; x=1724155096; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=CdP3XPxnxx1qkSZbcrQnhwBXnxXpJFgBOC6O2p4bYHQ=; b=cUJGlJIW2CTS/Ujcoa0M432MzoCgp2Eij4LJgyG/INEFVph73CiW02+TTIF3sHP7YZ R0eRkhcMe+wdXnXnQ8rJ/DnBLEy2EJb4XJzxE+u0vqwkEPSYD9yxZSumsUFQ3D7HWIEG mkrteQFI3qasXzT7twjGzSnk4hBtIrJlovII467C0sA+sIc8hf2Oy3IJ1oAaezv+wCyB 27hfYNZ4xJ6/sr+8UHqbTMXrXaeT5OieIciuPcdLxJPoAx5aOTN2pfo/ZRebzxzO9/ff hi+8mVvpRyixR70PjdQuWoWKO80QtNk/0b/aArqe5I6yCT788seaxqXfNYMpPa5ISsWv WFHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723550296; x=1724155096; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CdP3XPxnxx1qkSZbcrQnhwBXnxXpJFgBOC6O2p4bYHQ=; b=UKDjdBzqWoTnYpPdS7galsN4S5PiPvtyNU3E50HGZHDrtHTyLdDr25aUVUDnFTWC1y 6AFZKwKZ4S7b2d0zlyIYmdnpYEEIMkRztKmguvONtKgjwhA0Tl9m1QNx9v78nC5soku4 nWlQbQEeJa/5LC2fTA9jjuV6+jSfnESPDZi689ShOzLep7/oFead1aPFnAQt14YUWerX awGOLbdovjkyOEHCwGgXuT45thV+tDSinEXUCqsgWUW7v76zsDJxyUq7xnlUMxkC4CCz 76qu68o/3wkB7LbN2Gcp7PI+JMON9OJioXWfatVrBUmGdqbfXKfIPt6nVbXVtiUVVlXJ 2PTw== X-Gm-Message-State: AOJu0YyG3luZllQ1yuGAJ8Z+yX5Uy5GSGktQ16jgnszTy9PsK1rOvgQD Tbcd3BTcdj0iyh6Og07Kv/Yg4akregSqBPA15e7BaAQefUhpXWgU3MMob+MFD3t6z4ysFG82jXQ /KmJPdkCnig//vjaaab/LJv3Lw+yalf6s X-Google-Smtp-Source: AGHT+IFePt4mlwpbosOx3yrDeIcBUz0J6l3SwMkI1/6bu8hRwXSSRINI8QgUSwJ03KQbITUdRO+vQgbpmPdfXQUkTcY= X-Received: by 2002:a05:6820:826:b0:5c6:658c:a9f6 with SMTP id 006d021491bc7-5da685aa569mr3988058eaf.2.1723550295921; Tue, 13 Aug 2024 04:58:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Tue, 13 Aug 2024 07:58:04 -0400 Message-ID: Subject: Re: PG Dump on 11 - Restore on 16 - is possible? To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000241ff3061f8f5372" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000241ff3061f8f5372 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2024 at 5:47=E2=80=AFAM Durumdara wro= te: > Hello! > > We have to upgrade our server. The PG upgrade is impossible because of to= o > much data. > So we will create a new server with PG 16, and we have to migrate the > databases one by one (from a PG 11 server). > > Is it possible? > > Does PG16 read PG11 dumps and restore them correctly on the PG16 server? > https://www.postgresql.org/docs/release/16.0/ "See Section 19.6 for general information on migrating to new major releases." Section 19.6: https://www.postgresql.org/docs/16/upgrading.html "Current releases of the dump programs can read data from any server version back to 9.2." The major flaw in Section 19.6 is that it repeatedly says "use pg_dumpall", and only mentions pg_dump once. Don't use pg_dumpall; use pg_dump in "directory mode" with multiple threads. ("pg_dumpall --globals" is critical for roles and whatnot.) This is how I recently migrated three multi-TB PG 9.6 RHEL6 servers to PG 14 on RHEL8. --=20 Death to America, and butter sauce. Iraq lobster! --000000000000241ff3061f8f5372 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 13, 2024 at 5:47=E2=80=AFAM D= urumdara <durumdara@gmail.com= > wrote:
Hello!

We have t= o upgrade our server. The PG upgrade is impossible because of too much=C2= =A0data.
So we will create a new server with PG 16, and we have t= o migrate the databases one by one (from a PG 11 server).

Is it possible?

Does PG16 read PG11 dumps = and restore them correctly on the PG16 server?

"See=C2=A0Section=C2=A019.6=C2= =A0for general information on migrating to new major releases."=

https://www.postgresql.org/docs/16/upgrading.html
<= div>"Current releases of the dump programs can rea= d data from any server version back to 9.2."
The major flaw in Section 19.6 is that it repeatedly says &quo= t;use pg_dumpall", and only mentions pg_dump once.=C2=A0 Don't use= pg_dumpall; use pg_dump in "directory mode" with multiple=C2=A0t= hreads.=C2=A0 ("pg_dumpall --globals" is critical for roles and w= hatnot.)

This is how I recently migrated three mul= ti-TB PG 9.6 RHEL6 servers to PG 14 on RHEL8.

--
Death to America, and butter sauce.
Iraq l= obster!
--000000000000241ff3061f8f5372--