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.96) (envelope-from ) id 1wQfde-001lIK-0f for pgsql-general@arkaria.postgresql.org; Sat, 23 May 2026 06:15:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wQfdc-00FMil-0K for pgsql-general@arkaria.postgresql.org; Sat, 23 May 2026 06:15:09 +0000 Resent-Message-Id: 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.96) (envelope-from ) id 1wQfdb-00FMic-1I for pgsql-general@lists.postgresql.org; Sat, 23 May 2026 06:15:08 +0000 Received: from mx3.edn2.eu ([49.13.39.158]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wQfdZ-00000000Nbg-1G9j for pgsql-general@lists.postgresql.org; Sat, 23 May 2026 06:15:07 +0000 Received: from smtpclient.apple (p200300fb4f0e390101bc046b89b2f4c0.dip0.t-ipconnect.de [IPv6:2003:fb:4f0e:3901:1bc:46b:89b2:f4c0]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx3.edn2.eu (Postfix) with ESMTPSA id 4gMsLn5VYbzjmq for ; Sat, 23 May 2026 08:14:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellael.org; s=dkim; t=1779516897; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: resent-to:resent-from; bh=nLHRms/3wiYNRGhZeXT1u4lNyXCngWe7UsHGSwy0GqU=; b=brE3bW5TagVHfyNxOnjdRUhnUCAM+RlPIgxRrINdr6MV+X0AE33X/vhKGiWFTZ3EN+nVG7 cwHpuNgdoUUfT2iP2E6KGWUM3flqtEVmAqvsWytHAyCid3AUPhjxVMS5XsWpCSAJgugDNL U6mlo8V6bFCJLuN9gVLm+jlzofL71paG8TiWfXJ6HUW9Fs8CF9w8pshan7Dw+cguZozkYL jl81fVrg1EFggitT92FJjU7AVh0Oh0PeQhEVn1LFGUxTT6K2ky+YntEhNZdc7wMLyr4QmP Obczc777XQxN/SiC+aIo5KYefiP5XIGj6/T3U+On+h/DOJ9w0OlvdKG8odm45w== From: Michael Grimm Content-Type: multipart/alternative; boundary="Apple-Mail=_7BD4F772-89D9-4A66-AEAA-B7DBA6173908" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\)) Date: Fri, 22 May 2026 15:18:35 +0200 Subject: Can logical replication be a solution to my current MariaDB/Galera setup? Resent-Date: Sat, 23 May 2026 08:14:47 +0200 Resent-From: Michael Grimm To: pgsql-general@lists.postgresql.org Resent-To: pgsql-general@lists.postgresql.org Message-Id: X-Mailer: Apple Mail (2.3864.600.51.1.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_7BD4F772-89D9-4A66-AEAA-B7DBA6173908 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, this is my first post to this mailing list, and I hope that I chose the = correct mailing list. I have never run a postgres server before, but I do run a mariadb galera = cluster [1] for storing emails by an IMAP server [2]. Distribution and = failover is dealt by haproxy [3]. This mail server setup has to deal = with less than 250 mails a day, a database size of under 6 GB, and a = handful of users. You see, that this system is bored to death ;-) =20 I have read a lot about replication in order to find something = comparable to a galera cluster with its multi master capabilities. Now, = I have learned that multi master can only be achieved by using third = party plugins. Not all of those are available for my FreeBSD systems, = though. As a newbie I do currently tend to use logical replication with mutual = publish and subscribe instead, either by pglogical2 or "self-made". I am = in the -probably naive- impression that this could work. As before, = failover will be handled by haproxy by simply directing read/write = access to another postgres node available. When a failed node will = become online again, logical replication should enable this node to = recover, right? Here are my questions: #) Is this feasible or nonsense? #) What would an alternatives for FreeBSD be (pgpool-II, repmgr, =E2=80=A6= )? Any input is highly appreciated. Thanks in advance and regards, Michael [1] 3 nodes, primary-primary replication. [2] https://dbmail.org/en/ [3] All incoming MUA requests are directed to a single node in order to = prevent split brain situations= --Apple-Mail=_7BD4F772-89D9-4A66-AEAA-B7DBA6173908 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

this is my first post to this mailing list, = and I hope that I chose the correct mailing list.

I have never run a postgres server before, = but I do run a mariadb galera cluster [1] for storing emails by an IMAP = server [2]. Distribution and failover is dealt by haproxy [3]. This mail = server setup has to deal with less than 250 mails a day, a database size = of under 6 GB, and a handful of users. You see, that this system is = bored to death ;-)  

I have = read a lot about replication in order to find something comparable to a = galera cluster with its multi master capabilities. Now, I have learned = that multi master can only be achieved by using third party plugins. Not = all of those are available for my FreeBSD systems, though.

As a newbie I do currently tend to use = logical replication with mutual publish and subscribe instead, either by = pglogical2 or "self-made". I am in the -probably naive- impression that = this could work. As before, failover will be handled by haproxy by = simply directing read/write access to another postgres node available. = When a failed node will become online again, logical replication should = enable this node to recover, right?

Here = are my questions:

#) Is = this feasible or nonsense?
#) What would an = alternatives for FreeBSD be (pgpool-II, repmgr, =E2=80=A6)?

Any input is highly appreciated.

Thanks in advance and regards,
Michael


[1] 3 nodes, primary-primary = replication.
[2] https://dbmail.org/en/
[3] All incoming MUA = requests are directed to a single node in order to prevent split brain = situations= --Apple-Mail=_7BD4F772-89D9-4A66-AEAA-B7DBA6173908--