On 10/28/21 3:08 PM, Bruce Momjian wrote:
On Thu, Oct 28, 2021 at 02:23:39PM -0500, Ron wrote:
On 10/28/21 2:06 PM, Adrian Klaver wrote:
On 10/28/21 11:48, Ron wrote:
On 10/28/21 1:00 PM, Adrian Klaver wrote:
On 10/28/21 10:51, Ron wrote:
Not doable in Postgresql because WAL files are global to cluster.
I've read multiple times that will not be changed.
Yet somehow logical replication does it:
https://www.postgresql.org/docs/14/logical-replication-architecture.html
"
Logical replication is built with an architecture similar to physical
streaming replication (see Section 27.2.5). It is implemented by
“walsender” and “apply” processes. The walsender process starts logical
decoding (described in Chapter 49) of the WAL and loads the
Scans the (global) WAL data for only the that portion from the relevant
database?
If so, definitely not the same as having per-database WAL files.
Just as importantly, replication is not, and never will be, a substitute for
backups.
Uh, for replication slots, we don't send the entire WAL stream to the
subscriber:
I meant scanning at the source.
https://www.postgresql.org/docs/14/logical-replication.html
Logical replication of a table typically starts with taking a snapshot
of the data on the publisher database and copying that to the subscriber.
Once that is done, the changes on the publisher are sent to the subscriber
as they occur in real-time. The subscriber applies the data in the same
order as the publisher so that transactional consistency is guaranteed for
publications within a single subscription. This method of data replication
is sometimes referred to as transactional replication.
It's still a bunch of transaction logs, whereas differential and incremental
backups only backup the changed pages, no matter how many times they've been
changed.
That's a serious reduction in disk space, and time to apply them.
--
Angular momentum makes the world go 'round.
