From guenther@internet24.de Tue Aug 1 07:49:49 2006 X-Original-To: pgsql-admin-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 449F69FA6B5 for ; Tue, 1 Aug 2006 04:49:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 87805-05 for ; Tue, 1 Aug 2006 04:49:45 -0300 (ADT) X-Greylist: delayed 00:27:08.622082 by SQLgrey- Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 9706C9FA5E9 for ; Tue, 1 Aug 2006 04:49:45 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from mailout02.ims-firmen.de (mailout02.ims-firmen.de [213.174.32.97]) by svr4.postgresql.org (Postfix) with ESMTP id 223B25AF07B for ; Tue, 1 Aug 2006 07:22:35 +0000 (GMT) Received: from mailin02.ims-firmen.de ([192.168.1.111]) by mailout02.ims-firmen.de with esmtp (Exim 4.30) id 1G7oaE-00018D-RU for pgsql-admin@postgresql.org; Tue, 01 Aug 2006 09:22:30 +0200 Received: from [213.174.32.254] (helo=GUENTHER) by mailin02.ims-firmen.de with esmtpa (Exim 4.62) (envelope-from ) id 1G7oaE-0003Ji-P3 for pgsql-admin@postgresql.org; Tue, 01 Aug 2006 09:22:30 +0200 From: =?iso-8859-1?Q?Thomas_G=FCnther?= To: Subject: Cascading replication Date: Tue, 1 Aug 2006 09:22:30 +0200 Message-ID: <011401c6b53b$40025370$2b00a8c0@imsfirmen.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0115_01C6B54C.038B2370" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aca1Oz+YxzH1CsRIQHOnisAEZ91ttA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.291 tagged_above=0 required=5 tests=AWL, HTML_MESSAGE, SARE_SPEC_REPLICA, SPF_FAIL X-Spam-Level: * X-Archive-Number: 200608/3 X-Sequence-Number: 22547 This is a multi-part message in MIME format. ------=_NextPart_000_0115_01C6B54C.038B2370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, my configuration exists of 2 db-nodes, 2 replication nodes and 1 loadbalancer. Is it able to replicate only some tables (not all) to a third db node. Has someone experiences with cascaded reolication. Can anyone post a sample conf for cascading? Best regards Tom :) ------=_NextPart_000_0115_01C6B54C.038B2370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

my configuration exists of 2 db-nodes, 2 = replication nodes and 1 loadbalancer.

 

Is it able to replicate only some tables (not = all) to a third db node.

Has someone experiences with cascaded = reolication.

Can anyone post a sample conf for = cascading?

 

Best regards

 

Tom :)

------=_NextPart_000_0115_01C6B54C.038B2370-- From bnichols@ca.afilias.info Tue Aug 1 15:02:25 2006 X-Original-To: pgsql-admin-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 717DA9FB31C for ; Tue, 1 Aug 2006 12:02:25 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 31312-06 for ; Tue, 1 Aug 2006 12:02:16 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.libertyrms.com (vgateway.libertyrms.info [207.219.45.62]) by postgresql.org (Postfix) with ESMTP id 73A109FB200 for ; Tue, 1 Aug 2006 12:02:16 -0300 (ADT) Received: from dba5.int.libertyrms.com ([10.1.3.44]) by mail.libertyrms.com with esmtp (Exim 4.22) id 1G7vl9-0005iM-9o; Tue, 01 Aug 2006 11:02:15 -0400 Subject: Re: Cascading replication From: Brad Nicholson To: Thomas =?ISO-8859-1?Q?G=FCnther?= Cc: pgsql-admin@postgresql.org In-Reply-To: <011401c6b53b$40025370$2b00a8c0@imsfirmen.de> References: <011401c6b53b$40025370$2b00a8c0@imsfirmen.de> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 01 Aug 2006 11:02:14 -0400 Message-Id: <1154444535.2624.1.camel@dba5.int.libertyrms.com> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 (2.6.2-1.fc5.5) Content-Transfer-Encoding: quoted-printable X-SA-Exim-Mail-From: bnichols@ca.afilias.info X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.495 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, SARE_SPEC_REPLICA X-Spam-Level: X-Archive-Number: 200608/7 X-Sequence-Number: 22551 On Tue, 2006-08-01 at 09:22 +0200, Thomas G=FCnther wrote: > Hello, >=20 > =20 >=20 > my configuration exists of 2 db-nodes, 2 replication nodes and 1 > loadbalancer. >=20 > =20 >=20 > Is it able to replicate only some tables (not all) to a third db > node.=20 >=20 > Has someone experiences with cascaded reolication. >=20 > Can anyone post a sample conf for cascading? >=20 Slony supports cascading replicas. What you would do is create two sets, one set would only get replicated to the second DB, and the other one would get subscribed from the second DB to the 3rd DB. If you want more information or assistance, the Slony list is the place to ask. Brad. From ilian.kostadinov@gmail.com Tue Aug 20 11:55:16 2024 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 1sgNSX-001MeX-AP for pgsql-admin@arkaria.postgresql.org; Tue, 20 Aug 2024 11:55:33 +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 1sgNSV-00FoQB-Ax for pgsql-admin@arkaria.postgresql.org; Tue, 20 Aug 2024 11:55:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sgNSU-00FoPN-W4 for pgsql-admin@lists.postgresql.org; Tue, 20 Aug 2024 11:55:31 +0000 Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sgNST-000Yy0-3x for pgsql-admin@lists.postgresql.org; Tue, 20 Aug 2024 11:55:30 +0000 Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-70d399da0b5so4569262b3a.3 for ; Tue, 20 Aug 2024 04:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724154928; x=1724759728; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=idDSY5m1vb3fZiijP7EhaiR2HcYjMLGg5inaEl+Tcek=; b=ZBuvSVKflCtu04Rd735q5DLTg/0L0jH7CvpJLsqqGCnNS/YF3BTY6VgCmwcj15z5go /ydwl3TwtmpPy6k/7q28Xo/zVAe7fSn+shygk+hgzZ+wHtrsX0UwjS4ue0/FY927bfS/ pvAWoniimSQ/vDpjA/NWaQh1It24Is/bppmesIx1uRrEyLLBn+1BujD7Muz/PydfM4aR 3ebd/hv6bndn7OQJnJB7++Zu+bcDhMmsXnASi/2tBMhLxb/0hKtaZRiZYO/MxJ3tzfWQ W8rNtP5RfyarOewccO1av7idSrOcad3tcjy7eaRf6NIB4xu+GXj4cTDeZBtnwyX83a0t rtVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724154928; x=1724759728; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=idDSY5m1vb3fZiijP7EhaiR2HcYjMLGg5inaEl+Tcek=; b=hbOfD8e/qH9/SUwV06eWLxU2usaUX9cNuvn8mDbPrNX5yfb7DMB7edMs8NH8BeJL2F xZldWEf6Hp/sgtYwMrtRdWePWbknAGmO9cXmzE60aDR+3mrJeC0MoO6AZnpZH7bJnrVx V3Udsn/Q+YCGymOFpgQxeyDLD387W8Dlie5cwbqppCKNymNPSk393DiOp7UOEND4fCfX MXLKeDFdP6vEqSi34sl/KPbKCrCGoUplvtDtWgmd/zb5X7siHkWXzb1KkdViyhXf3vy/ pniBJ/DPlV3A5kQ/T6IKSqC58RSrODAaTyEx6P9EScZzyXAVU4ng+s85+J+4YjciQXwN +gBg== X-Gm-Message-State: AOJu0YzLq/FDu7dIbscZQIcoLwk+jo1wMvMYyAJD4h5nJhsubxd+u841 b31RI6GRImhR7EajelxhQkelMbQGBMsA2MmBlBMGLEWdVfw2G0C/19MEM9in6ZblfSJPHm1mJzW U1kIGHrj05+AsEVvdP5vTZfo9oYWK1A== X-Google-Smtp-Source: AGHT+IG4pmS3938zYaAzDras1qBDdJNUfD6XMoDuURoB9WfQMKu9pNuPfEOzKHLDJZzHzEJZVnzXWGvfh9QmdF60Og0= X-Received: by 2002:a05:6a21:3998:b0:1c1:92f8:d3c6 with SMTP id adf61e73a8af0-1c904fb5129mr17375589637.27.1724154927772; Tue, 20 Aug 2024 04:55:27 -0700 (PDT) MIME-Version: 1.0 From: Ilian Kostadinov Date: Tue, 20 Aug 2024 14:55:16 +0300 Message-ID: Subject: Cascading Replication To: pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000001fd7e06201c1af8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000001fd7e06201c1af8 Content-Type: text/plain; charset="UTF-8" Hello, currently we have postgresql 16 with streaming replication. Is it possible to create logical replication of the streaming replica? So I have server A which is main database server with application connected to it. Also server B which is streaming replication of server A. I succeded to created server C which is streaming replica of server B, but I want to convert it to logical replica of server B. Database is more then 50TB, so how to convert server C to logical replica without need to sync all data from the beginning? Best Regards, Iliyan --00000000000001fd7e06201c1af8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

currently we have pos= tgresql 16 with streaming replication. Is it possible
to cre= ate logical replication of the streaming replica?
So I have = server A which is main database server with application connected to it.
Also server B which is streaming replication of server A.=C2=A0 I s= ucceded to created server C
which is streaming replica of server = B, but I want to convert it to logical replica of server B.
Datab= ase is more then 50TB, so how to convert server C to logical replica withou= t need to sync all data from the beginning?

Best R= egards,
Iliyan

--00000000000001fd7e06201c1af8-- From asadalinagri@gmail.com Thu Aug 22 11:22:16 2024 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 1sh5tk-00Co4K-Bh for pgsql-admin@arkaria.postgresql.org; Thu, 22 Aug 2024 11:22:36 +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 1sh5ti-001fAn-D6 for pgsql-admin@arkaria.postgresql.org; Thu, 22 Aug 2024 11:22:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sh5th-001fAf-TY for pgsql-admin@lists.postgresql.org; Thu, 22 Aug 2024 11:22:34 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sh5tf-000tHF-SK for pgsql-admin@lists.postgresql.org; Thu, 22 Aug 2024 11:22:33 +0000 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a86910caf9cso96945566b.1 for ; Thu, 22 Aug 2024 04:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724325750; x=1724930550; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EM5bX6krcAHZqxilkmYE5Edk/DcBIf2Aybs6fgHhb9U=; b=VHGvowDqJMblEHk0zP9M6G3dY6/yagKUD+SCJblntyHzqBxIqfqxTrfJf3HhQNS/Zt mHFpAL77r92eDvsvf4uQ+9eW7FKmzwn8FqNouh4XuEZmRQ8C1QKD7xO83RNLhX9LxT1l XFIDX24h9D8Yu3WglwoYkV3CyahibmtUP7S6htMlBwbqHCCgnLMb3vrqNdCLLxXZKTeN Gor11/7p7jmuujcdoOMESBXSBZkNdrP8Z+GT/GcGk45Jd/ex+7mxBSjHv/kIB++74auG nNIojmGiEGOrYK1aTwEufoekpr8ITnwxTAz+Ri8p+mzo2o+zamrFoVy8HC6zn4bM8vRo mHDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724325750; x=1724930550; h=cc: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=EM5bX6krcAHZqxilkmYE5Edk/DcBIf2Aybs6fgHhb9U=; b=newtuLwBHxdHK7HH15rrK3bVIEP5yNpSqg4wgn6ShQRgkPIltwQgNl1zOGfj2drECH iOuHQd+icWcBAIHSqIrPYhCN30M5Cwj5zE82xfqvQmSU/+GVuBpcDnGWZDsWvubEx3C+ LPO/F+WPqkKNG5B6AULq9YHX9dllcXW57OQriJe7ZpaC9banJ+URIsra4epkeFRNUyvx OC7/zo09s8yJ9W81jb/OatleBBS2i/CQB2sbvaOKhfmgmJoWfceK5k3/Mn0NKRnvepA4 knsuarPCdTzxqWSc0F3ZVho0Y0nMRRtt38aOSUwcblc3AxKN/yNOdEL6CNV8THoTWMfW tVMA== X-Gm-Message-State: AOJu0YwZxmQEoUOsz806cMprYs0Wl3e1ee1n0CKfncH8+rMHZm2AIimw n9KP4DRyWObhfWGzQzoWYIQ4fV1XUfFeIZZJYpPDAexU5Cim9r6H/Kuz/UcEX1TL47Nse0CfpCt vXnkiKnFKqjGwHYwwyym9IE/zwBpS+nH0 X-Google-Smtp-Source: AGHT+IFP2qBmb2bo562OiixOEYmxSdB4I4a0nceWmlmx3pi9ajg3wCUVp2lpwA9Ekz6odUuncnhnVZtq16hPTw4Lo0w= X-Received: by 2002:a17:906:4fcb:b0:a7a:acae:340b with SMTP id a640c23a62f3a-a868a92106emr223066266b.31.1724325749812; Thu, 22 Aug 2024 04:22:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Asad Ali Date: Thu, 22 Aug 2024 16:22:16 +0500 Message-ID: Subject: Re: Cascading Replication To: Ilian Kostadinov Cc: pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000cb7722062043dfb2" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000cb7722062043dfb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello *Ilian Kostadinov,* Here=E2=80=99s how you can achieve this without needing to sync all data fr= om the beginning: Make sure logical replication is enabled on Server B. In your postgresql.conf, set the following parameters on Server B: *wal_level =3D logicalmax_replication_slots =3D max_wal_sen= ders =3D * Restart PostgreSQL on Server B for these changes to take effect. On Server B, create a publication for the tables you want to replicate: *CREATE PUBLICATION my_publication FOR ALL TABLES;* If you need specific tables, adjust the query accordingly. Create a logical replication slot on Server B. This slot will be used by Server C to stream changes: *SELECT * FROM pg_create_logical_replication_slot('my_slot', 'pgoutput');* On Server C, create a subscription to the publication on Server B: On Server C, create a subscription to the publication on Server B: *CREATE SUBSCRIPTION my_subscription CONNECTION 'host=3D dbname=3D user=3D password=3D'PUBLICATI= ON my_publicationWITH (copy_data =3D false);* The WITH (copy_data =3D false) clause is crucial because it prevents Server= C from copying all the data from scratch, which would be inefficient given your 50TB database size. Instead, it will start replicating changes from the point when the subscription is created. Since you're skipping the initial data copy, you need to ensure that the data on Server C is in sync with Server B. If Server C was already a streaming replica of Server B, this should already be the case. However, if any discrepancies exist, you may need to manually sync specific tables or sequences. Best Regards, Asad Ali On Tue, Aug 20, 2024 at 4:55=E2=80=AFPM Ilian Kostadinov wrote: > Hello, > > currently we have postgresql 16 with streaming replication. Is it possibl= e > to create logical replication of the streaming replica? > So I have server A which is main database server with application > connected to it. > Also server B which is streaming replication of server A. I succeded to > created server C > which is streaming replica of server B, but I want to convert it to > logical replica of server B. > Database is more then 50TB, so how to convert server C to logical replica > without need to sync all data from the beginning? > > Best Regards, > Iliyan > > --000000000000cb7722062043dfb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ilian Kostadinov,

Here=E2=80=99s how you can achieve this without nee= ding to sync all data from the beginning:

Make sur= e logical replication is enabled on Server B. In your postgresql.conf, set = the following parameters on Server B:
wal_level =3D logicalmax_replication_slots =3D <desired number>
max_wal_senders =3D &l= t;desired number>

Restart PostgreSQL on Server B for t= hese changes to take effect.

On Server B, crea= te a publication for the tables you want to replicate:
CRE= ATE PUBLICATION my_publication FOR ALL TABLES;
If you nee= d specific tables, adjust the query accordingly.

Create a logical replication slot on Server B. This slot will be used by= Server C to stream changes:
SELECT * FROM pg_create_logic= al_replication_slot('my_slot', 'pgoutput');
On Server C, create a subscription to the publication on Server B:


On Server C, create a subscription to the= publication on Server B:
CREATE SUBSCRIPTION my_subscription CONNECTION 'host=3D<Server B IP> dbname=3D<dbname> user= =3D<replication_user> password=3D<password>'
PUBLICATION= my_publication
WITH (copy_data =3D false);
The WITH (copy= _data =3D false) clause is crucial because it prevents Server C from copyin= g all the data from scratch, which would be inefficient given your 50TB dat= abase size. Instead, it will start replicating changes from the point when = the subscription is created.

Since you're skip= ping the initial data copy, you need to ensure that the data on Server C is= in sync with Server B. If Server C was already a streaming replica of Serv= er B, this should already be the case.
However, if any discrepanc= ies exist, you may need to manually sync specific tables or sequences.

Best Regards,
Asad Ali

On Tue, Aug 20, = 2024 at 4:55=E2=80=AFPM Ilian Kostadinov <ilian.kostadinov@gmail.com> wrote:
Hello,

currently we have postgresql 16 with streaming replica= tion. Is it possible
to create logical replication of the st= reaming replica?
So I have server A which is main database s= erver with application connected to it.
Also server B which is st= reaming replication of server A.=C2=A0 I succeded to created server C
=
which is streaming replica of server B, but I want to convert it to lo= gical replica of server B.
Database is more then 50TB, so how to = convert server C to logical replica without need to sync all data from the = beginning?

Best Regards,
Iliyan

--000000000000cb7722062043dfb2-- From ramsveeru441@gmail.com Thu Aug 22 12:53:08 2024 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 1sh7Jd-00D9Vh-Vz for pgsql-admin@arkaria.postgresql.org; Thu, 22 Aug 2024 12:53:26 +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 1sh7Jc-002SIp-3N for pgsql-admin@arkaria.postgresql.org; Thu, 22 Aug 2024 12:53:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sh7Jb-002SIZ-Jr for pgsql-admin@lists.postgresql.org; Thu, 22 Aug 2024 12:53:24 +0000 Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sh7JZ-000tzW-HY for pgsql-admin@lists.postgresql.org; Thu, 22 Aug 2024 12:53:22 +0000 Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a86984e035aso41498666b.2 for ; Thu, 22 Aug 2024 05:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724331200; x=1724936000; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nRNjEQMuyEq5gYT75jxpub6OoXMK2oZtR49l+psgMRo=; b=PpwUUSWvcS+JSr65Z1eY06e9xxPrmrC+UGxU2eKGuEvjvNxjj2uhj6TQTjeOGu5PNO KPyG9tlcnsEaKcq9Ag0Prv2ZKJYXhDjNOOeV9yBUy7WMUrQV3UVrfxJjtyeb2NlFQ/Dp eluZhZfIaKhirg0p/VZ0uGfVQfsJPkWmfsLEZNbdALxBrJZYn5HhreDPR7nRcnl1R1F+ UoEbh8Qhnk0FmUH5g1P+/UG2ebci/Hi2I13F+nnPYR1CaegHDEQUUXacGmDyYJdmX0HZ BH6FG/8sU2JYofiiKTVN/9df4HUhX0o/tkifTNO3vMlXziy6RluPSFmOTQ9Ld2OE4DWX TZEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724331200; x=1724936000; h=cc: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=nRNjEQMuyEq5gYT75jxpub6OoXMK2oZtR49l+psgMRo=; b=dNVwFt1XkDLPSwVKoOO4cLOHVZN8ZpxecrOE8mTptAgKPHnChltBZNoKBnbi7QuWNM ZSxBGU1Jz7b1c9dGgBe5I5V+AyxgZQWSvxevClOOJL3w26ZBYyCGcGDE+i54HcQPuvkv +N/kST1IdS45wyLi1tj9xhsJbizke/VlgctUYxp+ykhys4WUssIHNkOAg5iYhpy7ul3n kR0rd//c2bTKKggEOqdcBA3HLn85KrsLqDfCzlbEd6z3LxIeRRN1L0qC2HPo0hK+03Ea UfewfBVl9peDgTD09mf1tIutHIILRbvCO6lzX0x7qLkQmQKrQc7sy5xx5LexyyUk+ZV5 8nzg== X-Forwarded-Encrypted: i=1; AJvYcCVJ3Si5ZlavKzNqOl0Al74YHEmvHRNVjDNqR66HI3pB3Vx2vMcfMBxs+u1zXXllLQhnSi8BokN9ZB+hdA==@lists.postgresql.org X-Gm-Message-State: AOJu0YxTvn+D58jYtH6+gU8ZHkIWQZ5sSt1eEuo/0GRfTrgDyqXr4el/ rWR7iJq2w4SZI75+22ta0jfQdYfgvacnvYgkbWyjfNbF8Pt5TdtZbRxsFcV3aKoSMxY5LxUcE9A H38I/eBDP1vaGeEz2XljZHPPOGotirg== X-Google-Smtp-Source: AGHT+IHwMbcCV0cUjUQaxb3r8FD2GwexgB2JlH5QHGqhIOnB2e+XRefmtAjOsvUHauW0UcfUQitkq74AA8MnjJb8weI= X-Received: by 2002:a17:907:971d:b0:a86:7c6f:7cfa with SMTP id a640c23a62f3a-a867c6f7da8mr389297366b.37.1724331199708; Thu, 22 Aug 2024 05:53:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: rams nalabolu Date: Thu, 22 Aug 2024 07:53:08 -0500 Message-ID: Subject: Re: Cascading Replication To: Asad Ali Cc: Ilian Kostadinov , pgsql-admin@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000a24500062045246f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a24500062045246f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Along with Asad steps you need to add one extra parameter hot_standby_feedback=3Don on Standby server(B) And while creating subscriptions on server C using server B connection information it will be on halt state and won=E2=80=99t finish fast. This wi= ll happen while server B is waiting to sync the data from Server A. In this case you need to refresh the replication state between server A and Server B using =E2=80=9Cselect pg_log_standby_snapshot()=E2=80=9D and there after = the server B will allow the replication commands to be executed and subscription creation will be finished. Thanks Veeru On Thu, Aug 22, 2024 at 6:22=E2=80=AFAM Asad Ali w= rote: > Hello *Ilian Kostadinov,* > > Here=E2=80=99s how you can achieve this without needing to sync all data = from the > beginning: > > Make sure logical replication is enabled on Server B. In your > postgresql.conf, set the following parameters on Server B: > > > *wal_level =3D logicalmax_replication_slots =3D number>max_wal_senders =3D * > Restart PostgreSQL on Server B for these changes to take effect. > > On Server B, create a publication for the tables you want to replicate: > > *CREATE PUBLICATION my_publication FOR ALL TABLES;* > If you need specific tables, adjust the query accordingly. > > Create a logical replication slot on Server B. This slot will be used by > Server C to stream changes: > > *SELECT * FROM pg_create_logical_replication_slot('my_slot', 'pgoutput');= * > On Server C, create a subscription to the publication on Server B: > > > On Server C, create a subscription to the publication on Server B: > > > > *CREATE SUBSCRIPTION my_subscription CONNECTION 'host=3D > dbname=3D user=3D password=3D'PUBLICA= TION > my_publicationWITH (copy_data =3D false);* > The WITH (copy_data =3D false) clause is crucial because it prevents Serv= er > C from copying all the data from scratch, which would be inefficient give= n > your 50TB database size. Instead, it will start replicating changes from > the point when the subscription is created. > > Since you're skipping the initial data copy, you need to ensure that the > data on Server C is in sync with Server B. If Server C was already a > streaming replica of Server B, this should already be the case. > However, if any discrepancies exist, you may need to manually sync > specific tables or sequences. > > Best Regards, > Asad Ali > > On Tue, Aug 20, 2024 at 4:55=E2=80=AFPM Ilian Kostadinov < > ilian.kostadinov@gmail.com> wrote: > >> Hello, >> >> currently we have postgresql 16 with streaming replication. Is it >> possible >> to create logical replication of the streaming replica? >> So I have server A which is main database server with application >> connected to it. >> Also server B which is streaming replication of server A. I succeded to >> created server C >> which is streaming replica of server B, but I want to convert it to >> logical replica of server B. >> Database is more then 50TB, so how to convert server C to logical replic= a >> without need to sync all data from the beginning? >> >> Best Regards, >> Iliyan >> >> --000000000000a24500062045246f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Along with Asad steps you need to add one extra parameter= hot_standby_feedback=3Don on Standby server(B)=C2=A0

And while creating subscriptions on server C = using server B connection information it will be on halt state and won=E2= =80=99t finish fast. This will happen while server B is waiting to sync the= data from Server A. In this case you need to refresh the replication state= between server A and Server B using =E2=80=9Cselect pg_log_standby_snapsho= t()=E2=80=9D and there after the server B will allow the replication comman= ds to be executed and subscription creation will be finished.=C2=A0


Tha= nks
Veeru

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 22, 2024 at 6:22=E2=80=AFA= M Asad Ali <asadalinagri@gmail= .com> wrote:
Hello Ili= an Kostadinov,

Here=E2=80=99s how you can achieve this without needing to sync all data = from the beginning:

Make sure logical replication = is enabled on Server B. In your postgresql.conf, set the following paramete= rs on Server B:
wal_level =3D logical
max_replication_slots= =3D <desired number>
max_wal_senders =3D <desired number>
Restart PostgreSQL on Server B for these changes to take e= ffect.

On Server B, create a publication for t= he tables you want to replicate:
CREATE PUBLICATION my_pub= lication FOR ALL TABLES;
If you need specific tables, adj= ust the query accordingly.

Create a logical re= plication slot on Server B. This slot will be used by Server C to stream ch= anges:
SELECT * FROM pg_create_logical_replication_slot(&#= 39;my_slot', 'pgoutput');
On Server C, create= a subscription to the publication on Server B:


On Server C, create a subscription to the publication on Server= B:
CREATE SUBSCRIPTION my_subscription
CONNECTION 'host= =3D<Server B IP> dbname=3D<dbname> user=3D<replication_user&= gt; password=3D<password>'
PUBLICATION my_publication
WITH = (copy_data =3D false);
The WITH (copy_data =3D false) clause = is crucial because it prevents Server C from copying all the data from scra= tch, which would be inefficient given your 50TB database size. Instead, it = will start replicating changes from the point when the subscription is crea= ted.

Since you're skipping the initial data co= py, you need to ensure that the data on Server C is in sync with Server B. = If Server C was already a streaming replica of Server B, this should alread= y be the case.
However, if any discrepancies exist, you may need = to manually sync specific tables or sequences.

Bes= t Regards,
Asad Ali

On Tue, Aug 20, 2024 at 4:55=E2=80=AFPM = Ilian Kostadinov <ilian.kostadinov@gmail.com> wrote:
Hello,

currently we hav= e postgresql 16 with streaming replication. Is it possible
t= o create logical replication of the streaming replica?
So I = have server A which is main database server with application connected to i= t.
Also server B which is streaming replication of server A.=C2= =A0 I succeded to created server C
which is streaming replica of = server B, but I want to convert it to logical replica of server B.
Database is more then 50TB, so how to convert server C to logical replica= without need to sync all data from the beginning?

Best Regards,
Iliyan

--000000000000a24500062045246f--