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 1sCQPc-005ZRA-Br for pgsql-general@arkaria.postgresql.org; Wed, 29 May 2024 21:00:45 +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 1sCQPc-00GzDD-7H for pgsql-general@arkaria.postgresql.org; Wed, 29 May 2024 21:00:44 +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 1sCBfI-00DPl6-6Y for pgsql-general@lists.postgresql.org; Wed, 29 May 2024 05:15:56 +0000 Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sCBfF-002TGh-Cd for pgsql-general@lists.postgresql.org; Wed, 29 May 2024 05:15:54 +0000 Received: by mail-lf1-x131.google.com with SMTP id 2adb3069b0e04-52b27afe214so70106e87.1 for ; Tue, 28 May 2024 22:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716959751; x=1717564551; 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=hMkk69E2s+toLqqC7asr4SIX52eBPzKiJr4ATAnxzVQ=; b=m4MbVQyykrNihfz96rYmhxQ4mfUtfbWZC+RMoLzJSBiQhwX0DESIO2zDvVcpfef+Gh 76pM9Jk/MIHYHoZxQ2/A9ua/acGQ2BmzQQ4eMDqyV/znvKERXvGjqNEnX2LCcOqQCkzu kn6tvELDu3W+lvc5WsM5aOfxUwJdkZb6Mo0JKXkuJlI8flF2U/ra4jthdScquHr1YVhS tCQyK6INfGzTJwMKP77O9W/KD6gvyZKcySUk0mVcSlDOr86jSrCU0ykwjSCTiCUkeQos 759bFUgk+66BRsFqQhn3I1yEgfuVd/zfO59gtqrqABb0x7ft/uHUzXYM4z3MjhLP7yX5 Jmzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716959751; x=1717564551; 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=hMkk69E2s+toLqqC7asr4SIX52eBPzKiJr4ATAnxzVQ=; b=lRe1jIrvy71gnD8thjAWk6AhlfS6RVDcYqFPsvMScQLf5mXkclmZhCfulgN+NGSn6X pgj/2A4wF+6Vax6LbZpftRirPPz17XJ8WGnbz/9CK0R1/pO8TWTlajBRgf9EvIh06oT9 IM7CihUl7cc6N5crlZbf46Ph55kxNNlfPaYhzecYePpOrXuS/DAi0CdPw4Ev56fIW2iA JOZkh/Yvhb8k69Ck8QsOXV6iPc6kCrPJj6zEJdlmY/eGqDvmiUi+IpCTTuUpSSEx7LhX km2lwc8wNu0Y8tve6uK2w+qY37tN+0bQTNKP7agDQsm06PpvKqnlqOseufGQxt6Nyaac ARmw== X-Gm-Message-State: AOJu0YwPyOZoh03uB1qQa0jOlm1V9cYecaX7TQd3xUyR54xTB9NBE+yw RZ/Oy5iIidYnDvJYISe6NMg+e256gqneaNyT25jZ6p9ZLktsxBo8UkexsXD1dV9m3UvJvXOdkf1 cvlmymU9vuYL1uhDx4uNOUZ5XHa1PKm1vy1g= X-Google-Smtp-Source: AGHT+IHACkpseDp9R/NHxez0P/r/bO866QdGOXq3Y2KVbc2e0ZtiIxu3JLEB01CCSd2KY0VM7I9X4kezTnkhn29pQ/U= X-Received: by 2002:ac2:5147:0:b0:51e:1391:9bf with SMTP id 2adb3069b0e04-52a78c3668fmr264975e87.22.1716959751273; Tue, 28 May 2024 22:15:51 -0700 (PDT) MIME-Version: 1.0 References: <22b7b0b8-c348-44df-a9a4-ceba94f379b2@aklaver.com> In-Reply-To: <22b7b0b8-c348-44df-a9a4-ceba94f379b2@aklaver.com> From: vijay patil Date: Wed, 29 May 2024 10:45:39 +0530 Message-ID: Subject: Re: Pgpool with high availability To: Adrian Klaver Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000011848f061990d87e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000011848f061990d87e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Adrian, After modifying the pgpool.conf configuration to correct a subnet mistake, Previously, the wrong subnet was specified as /26, and it has now been corrected to /24. The configuration changes were as follows: Previous Configuration: delegate_ip =3D '10.127.1.18' if_up_cmd =3D '/sbin/ip addr add $_IP_$/26 dev eth0 label eth0:1' if_down_cmd =3D '/sbin/ip addr del $_IP_$/26 dev eth0' arping_cmd =3D '/usr/sbin/arping -U $_IP_$ -w 1 -I eth0' Updated Configuration: delegate_ip =3D '10.127.1.18' if_up_cmd =3D '/sbin/ip addr add $_IP_$/24 dev eth0 label eth0:1' if_down_cmd =3D '/sbin/ip addr del $_IP_$/24 dev eth0' arping_cmd =3D '/usr/sbin/arping -U $_IP_$ -w 1 -I eth0' Current Issue:- Following the subnet correction, the Virtual IP (VIP) 10.127.1.18 is now reachable only from the leader node (ha0002), while it remains unreachable from the standby nodes (ha0001 and ha0003). Below are the details of the connectivity status and the commands executed: *Leader Node (**ha0002**)* [root@staging-ha0002 PG_LOGS]# ping 10.127.1.18 PING 10.127.1.18 (10.127.1.18) 56(84) bytes of data. 64 bytes from 10.127.1.18: icmp_seq=3D1 ttl=3D64 time=3D0.041 ms 64 bytes from 10.127.1.18: icmp_seq=3D2 ttl=3D64 time=3D0.058 ms 64 bytes from 10.127.1.18: icmp_seq=3D3 ttl=3D64 time=3D0.060 ms --- 10.127.1.18 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2080ms rtt min/avg/max/mdev =3D 0.041/0.053/0.060/0.008 ms [root@staging-ha0002 PG_LOGS]# ping 10.127.1.18 PING 10.127.1.18 (10.127.1.18) 56(84) bytes of data. 64 bytes from 10.127.1.18: icmp_seq=3D1 ttl=3D64 time=3D0.041 ms 64 bytes from 10.127.1.18: icmp_seq=3D2 ttl=3D64 time=3D0.058 ms 64 bytes from 10.127.1.18: icmp_seq=3D3 ttl=3D64 time=3D0.060 ms --- 10.127.1.18 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2080ms rtt min/avg/max/mdev =3D 0.041/0.053/0.060/0.008 ms [pgbigboss@staging-ha0002 ~]$ pcp_watchdog_info -h 10.127.1.18 -p 9898 -U pgbigboss -W Password: 3 3 YES ha0002:9999 Linux staging-ha0002 ha0002 ha0002:9999 Linux staging-ha0002 ha0002 9999 9000 4 LEADER 0 MEMBER ha0001:9999 Linux staging-ha0001 ha0001 9999 9000 7 STANDBY 0 MEMBER ha0003:9999 Linux staging-ha0003 ha0003 9999 9000 7 STANDBY 0 MEMBER *Standby Node (**ha0001**)* *[root@staging-ha0001 ~]# ping 10.127.1.18* *PING 10.127.1.18 (10.127.1.18) 56(84) bytes of data.* *From 10.127.1.10 icmp_seq=3D1 Destination Host Unreachable* *From 10.127.1.10 icmp_seq=3D2 Destination Host Unreachable* *From 10.127.1.10 icmp_seq=3D3 Destination Host Unreachable* *--- 10.127.1.18 ping statistics ---* *5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4126ms* *pipe 3* *[pgbigboss@staging-ha0001 ~]$ pcp_watchdog_info -h 10.127.1.18 -p 9898 -U pgbigboss -W* *Password:* *ERROR: connection to host "10.127.1.18" failed with error "No route to host"* The VIP 10.127.1.18 is accessible from the leader node (ha0002) but not from the standby nodes (ha0001 and ha0003). Thanks Vijay On Tue, May 28, 2024 at 11:31=E2=80=AFPM Adrian Klaver wrote: > > > On 5/28/24 1:31 AM, vijay patil wrote: > > > > HI Team, > > > > "I'm encountering challenges while configuring Pgpool with high > > availability. The initial setup is completed, and Pgpool is operational > > on a single node, functioning without issues. However, upon attempting > > to start Pgpool on any additional nodes, particularly node 2, it become= s > > immediately unreachable. > > And how we are supposed to arrive at an answer with essentially no > information provided? > > Need: > > 1) Configuration for initial setup. > > 2) A more detailed explanation of what "... upon attempting > to start Pgpool on any additional nodes" means? Include configuration > changes. > > 3) The error messages. > > 4) Where the nodes are located? > > > > > > I'm seeking assistance to address this issue. My setup consists of thre= e > > nodes, each hosting both PostgreSQL and Pgpool services." > > > > > > Thanks > > > > Vijay > > > > -- > Adrian Klaver > adrian.klaver@aklaver.com > --00000000000011848f061990d87e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Adrian,

After modifying the pgpool.conf configuration to correct a subnet mistake,=C2=A0 Previously, the wrong subnet was specified as /26, and it has now been corrected to /24. The configuration changes were as follows:

=C2=A0

Previous Configuration:

=C2=A0

delegate_ip =3D '10.127.1.18'

if_up_cmd =3D '/sbin/ip addr add $_IP_$/26 dev e= th0 label eth0:1'

if_down_cmd =3D '/sbin/ip addr del $_IP_$/26 dev= eth0'

arping_cmd =3D '/usr/sbin/arping -U $_IP_$ -w 1 = -I eth0'

=C2=A0

Updated Configuration:

=C2=A0

delegate_ip =3D '10.127.1.18'

if_up_cmd =3D '/sbin/ip addr add $_IP_$/24 dev e= th0 label eth0:1'

if_down_cmd =3D '/sbin/ip addr del $_IP_$/24 dev= eth0'

arping_cmd =3D '/usr/sbin/arping -U $_IP_$ -w 1 = -I eth0'

=C2=A0

Current Issue:-

=C2=A0

Following the subnet correction, the Virtual IP (VIP= ) 10.127.1.18 is now rea= chable only from the leader node (ha0002), while it = remains unreachable from the standby nodes (ha= 0001 and ha0003). Below are t= he details of the connectivity status and the commands executed:<= /p>

=C2=A0

Leader Node (ha0002)

=C2=A0

[root@staging-ha0002 PG_LOGS]# ping 10.127.1.18

PING 10.127.1.18 (10.127.1.18) 56(84) bytes of data.=

64 bytes from 10.127.= 1.18: icmp_seq=3D1 ttl=3D64 time=3D0.041 ms

64 bytes from 10.127.= 1.18: icmp_seq=3D2 ttl=3D64 time=3D0.058 ms

64 bytes from 10.127.= 1.18: icmp_seq=3D3 ttl=3D64 time=3D0.060 ms

--- 10.127.1.18 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, t= ime 2080ms

rtt min/avg/max/mdev =3D 0.041/0.053/0.060/0.008 ms<= span>

=C2=A0

[root@staging-ha0002 PG_LOGS]# ping 10.127.1.18

PING 10.127.1.18 (10.127.1.18) 56(84) bytes of data.=

64 bytes from 10.127.= 1.18: icmp_seq=3D1 ttl=3D64 time=3D0.041 ms

64 bytes from 10.127.= 1.18: icmp_seq=3D2 ttl=3D64 time=3D0.058 ms

64 bytes from 10.127.= 1.18: icmp_seq=3D3 ttl=3D64 time=3D0.060 ms

--- 10.127.1.18 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, t= ime 2080ms

rtt min/avg/max/mdev =3D 0.041/0.053/0.060/0.008 ms<= span>

=C2=A0

[pgbigboss@staging-ha0002 ~]$ pcp_watchdog_info -h 10.127.1.18 -p 9898 -U pgbigboss -W

Password:

3 3 YES ha0002:9999 Linux staging-ha0002 ha0002

ha0002:9999 Linux staging-ha0002 ha0002 9999 9000 4 = LEADER 0 MEMBER

ha0001:9999 Linux staging-ha0001 ha0001 9999 9000 7 = STANDBY 0 MEMBER

ha0003:9999 Linux staging-ha0003 ha0003 9999 9000 7 = STANDBY 0 MEMBER

=C2=A0

Standby Node (ha0001)

=C2=A0

[root@staging-ha0001 ~]# ping 10.127.1.18

PING 10.127.1.18 (10.127.1.18) 56(84) bytes of da= ta.

From 10.127.1.10 icmp_seq=3D1 Destination Host Un= reachable

From 10.127.1.10 icmp_seq=3D2 Destination Host Un= reachable

From 10.127.1.10 icmp_seq=3D3 Destination Host Un= reachable

--- 10.127.1.18 ping statistics ---<= /b>

5 packets transmitted, 0 received, +3 errors, 100= % packet loss, time 4126ms

pipe 3

=C2=A0

[pgbigboss@staging-ha0001 ~]$ pcp_watchdog_info -= h 10.127.1.18 -p 9898 -U pgbigboss -W

Password:

ERROR: connection to host "10.127.1.18"= failed with error "No route to host"

=C2=A0

The VIP 10.127.1.18 is accessible from the leader node (ha0002) but not from the standby nodes (= ha0001 and


Thanks=C2=A0

Vijay


On Tue, May 28, 2024 at 11:31=E2=80=AFPM Adr= ian Klaver <adrian.klaver@a= klaver.com> wrote:


On 5/28/24 1:31 AM, vijay patil wrote:
>
> HI Team,
>
> "I'm encountering challenges while configuring Pgpool with hi= gh
> availability. The initial setup is completed, and Pgpool is operationa= l
> on a single node, functioning without issues. However, upon attempting=
> to start Pgpool on any additional nodes, particularly node 2, it becom= es
> immediately unreachable.

And how we are supposed to arrive at an answer with essentially no
information provided?

Need:

1) Configuration for initial setup.

2) A more detailed explanation of what "... upon attempting
to start Pgpool on any additional nodes" means? Include configuration =
changes.

3) The error messages.

4) Where the nodes are located?


>
> I'm seeking assistance to address this issue. My setup consists of= three
> nodes, each hosting both PostgreSQL and Pgpool services."
>
>
> Thanks
>
> Vijay
>

--
Adrian Klaver
adrian.klave= r@aklaver.com
--00000000000011848f061990d87e--