From: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
---|---|
To: | Hannu Krosing <hannuk(at)google(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Middleware Messages for FE/BE |
Date: | 2021-08-19 16:08:06 |
Message-ID: | CANbhV-E0XHgdQdQiw=EZrndo+Mk-+aiiii9jP3+0M6VaM83aAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 19 Aug 2021 at 10:58, Hannu Krosing <hannuk(at)google(dot)com> wrote:
>
> Actually the way I have been thinking about this would be a message
>
> "Hey replica x.x.x.x, please take over the write head role"
>
> Which would
>
> 1. cause the replica x.x.x.x to self-promote at this point-in-WAL
> 1A - optionally the old write head becomes a replica (it should
> mention it in message if it plans to stay around as a replica)
> 2. tells other replicas to switch over and start replicating from it
> 3. tells all connected clients to switch, if they need read-write access.
>
> This could be even done without timeline switch, as it should
> guarantee that there is no split brain writing
> Of course there are (and should be) ways to still use the WALs
> normally for cases where replica x.x.x.x does not exists, like PITR
>
> And making this play nicely with Logical Decoding is another can of
> worms needing to be solved, but it is a start to becoming "Cloud
> Native" :)
Good ideas!
--
Simon Riggs http://www.EnterpriseDB.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2021-08-19 16:12:11 | Re: RFC: Logging plan of the running query |
Previous Message | Simon Riggs | 2021-08-19 16:07:25 | Re: Middleware Messages for FE/BE |