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 1sSZ9O-008HTR-J2 for pgsql-general@arkaria.postgresql.org; Sat, 13 Jul 2024 09:34:42 +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 1sSZ9L-00FYxV-JU for pgsql-general@arkaria.postgresql.org; Sat, 13 Jul 2024 09:34:39 +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 1sSZ9L-00FYxN-4j for pgsql-general@lists.postgresql.org; Sat, 13 Jul 2024 09:34:39 +0000 Received: from mail-lj1-x22d.google.com ([2a00:1450:4864:20::22d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sSZ9H-001uRW-Qt for pgsql-general@lists.postgresql.org; Sat, 13 Jul 2024 09:34:37 +0000 Received: by mail-lj1-x22d.google.com with SMTP id 38308e7fff4ca-2ee910d6a9eso21757741fa.1 for ; Sat, 13 Jul 2024 02:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitnine-net.20230601.gappssmtp.com; s=20230601; t=1720863273; x=1721468073; 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=6O2CAQNXJ3cS6ZkKwgD9xgJ9wlYor6cx4GrcBJSiM44=; b=xhwTkKA5lJh33KwQf4N9hUE7MqT+GNLrq7j6eKPu5gU81aNJhtpb0kiYd/N55DlwPQ PWZHc8EkcxdvI16z5xNP1gzDWDHa7HYeZekRqDCMLPtYwnSV37U4qf9EUTVm86AoWH6G cMpzEOUsKP/Mrl6Bla3Dmpp0bLf+MEwA8IBudlHN7px7LVz6b0YvJLXf65P74XJ9Pgg6 O2rmyikOesLJKX874cVyLcr2owAik7xJmy/tw1fLRit2clDxqkameZU1LgoMzhUlJFFR vrtrJjCVBYgH7kKO1Q/jzfr+tgh74BXLOxofxr8qpuD34SbC4jFntgKikRijcIFwS4LB eqzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720863273; x=1721468073; 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=6O2CAQNXJ3cS6ZkKwgD9xgJ9wlYor6cx4GrcBJSiM44=; b=sJTx6jQu98O4514fuqvBVnOgu19F3R7dfsI2kqnzWRetGq4rG8N9TuDRO8Ng4Pxrx5 Ep5EzASOHaB7xc3OZFAzL0UfULdCnJNQIciBMlfRz8OAyOiR3mQeDCZs/YSZmhU7Nffo xtHxbTjWf+omboTInMsg+CxjPLSUSzE4yd1pWamXMwm/OK8BsgZ1XC1ryrKJmS6gPtgV cbJueVNfLQp108VmY9tkxn2kFr71CZOdE7JRhRtx5JIrQgujOTeVnS5JU+GMpanheHG6 N6Q55wcv9+NescmxXsLtMlJistsEyUjzX8TKDC9lvcFB/OASASyM4GY5DbzpLuVrpzQy +Trg== X-Gm-Message-State: AOJu0YzrAg05YjZb0J/REGV+KlRyBh+Udp+XDpt3u8fKUIspN8TGsb7j W1aOBMSLLcCeOUD41X1EnNhOQGl7dPkGwZiElWRU8SHAeqZCWasS1YWpn4ph06A/V7y8gN275Ft LYdgtnNfDRqb3JQ34pU3JJA5mS+3pDhHG+KsVkg== X-Google-Smtp-Source: AGHT+IEMGsZZMPLhBsVUHcG+WFud9LKWkHGCF1wRABBqS8bX8CDMJxEdXNw5mNmP7JhSN9w3QTG5qYWLfibBRCEQdw0= X-Received: by 2002:a2e:701a:0:b0:2ee:7b02:7fdc with SMTP id 38308e7fff4ca-2eed57c5202mr11406781fa.20.1720863272602; Sat, 13 Jul 2024 02:34:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Imtiaz Date: Sat, 13 Jul 2024 14:34:21 +0500 Message-ID: Subject: Re: Replication lag in Postgres To: Mukesh Tanuku Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000122bd2061d1db46f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000122bd2061d1db46f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I recommend the following configurations/options in this case: =E2=80=A2 wal_sender_timeout: This setting determines how long the primary = server waits for the standby server to acknowledge receipt of WAL data. Adjusting this can help ensure timely data transfer. =E2=80=A2 wal_keep_size: Ensures that enough WAL files are retained for the= standby to catch up if it falls behind. =E2=80=A2 checkpoint_timeout: Adjust the checkpoint frequency to ensure WAL= files are regularly flushed and sent to the standby server regularly. =E2=80=A2 pg_receivewal: Use this tool to continuously archive WAL files to= a safe location.It will helpful if there is a delay in streaming replication, you have a backup of WAL files. Regards, Muhammad Imtiaz On Fri, 12 Jul 2024, 20:11 Mukesh Tanuku, wrote= : > Hello everyone. > Firstly thanks to the community members who are addressing all the querie= s > that are posted. Those give us more insights about the issues/doubts in t= he > postgres. > > I have a question with postgres HA setup. > We are setting up a 2 node postgres cluster with async streaming > replication, we want to define a RPO (Recovery point objective) in case o= f > primary failure. > > How can we best define the RPO in this setup? since it's an async > streaming replication setup there might be a chance of data loss which is > proportional to the replication delay. > > Is there any way we can configure the delay duration, like for example to > make sure every 10 mins the standby sync has to happen with primary? > > Thank you > Regards > Mukesh T > > --000000000000122bd2061d1db46f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I recommend the following configurations/options in this c= ase:

=E2=80=A2 wal_sender_timeout: This setting determines how long the = primary server waits for the standby server to acknowledge receipt of WAL d= ata. Adjusting this can help ensure timely data transfer.

=E2=80=A2 wal_keep_size: Ensures that enough WAL files are retained= for the standby to catch up if it falls behind.

=E2=80=A2 checkpoint_timeout: Adjust the checkpoint frequency to en= sure WAL files are regularly flushed and sent to the standby server regular= ly.

=E2=80=A2 pg_receivewal: Use this tool to continuously archive WAL = files to a safe location.It will helpful if there is a delay in streaming r= eplication, you have a backup of WAL files.

=
Regards,
Muhammad Imtiaz

On Fri, 12 Jul 2024, 20:11 Mukesh Tanuku, <mukesh.postgres@gmail.com> wrote:
Hello everyone.=C2=A0
Firstly = thanks to the community members=C2=A0who are addressing all the queries tha= t are posted. Those give us more insights=C2=A0about the issues/doubts in t= he postgres.=C2=A0

I have a question with postgres HA se= tup.
We are setting up a 2 node postgres cluster with async streami= ng replication, we want to define a RPO (Recovery point objective) in case = of primary failure.=C2=A0

How can we best define= =C2=A0the RPO in this setup? since it's an async streaming replication = setup there might be a chance of data loss which is proportional to the rep= lication delay.=C2=A0

Is there any way we can conf= igure=C2=A0the delay duration, like for example to make sure every 10 mins = the standby sync has to happen with primary?=C2=A0

Thank you
Regards=C2=A0
Mukesh T
=
--000000000000122bd2061d1db46f--