Re: Slot issues - Mailing list pgsql-general

From Ravi Krishna
Subject Re: Slot issues
Date
Msg-id 36CCE7FA-BD81-409F-AE79-224C1FB68053@aol.com
Whole thread Raw
In response to Re: [External] Re: Slot issues  (Vijaykumar Jain <vjain@opentable.com>)
Responses Re: Slot issues  (Ravi Krishna <srkrishna1@aol.com>)
List pgsql-general
When I read all such posts related to replication I realize how backward is PG's replication architecture
specially when compared to DB2.

This is how it is done in Db2 to set up replication.

1. take a full backup on the primary.
2. restore the backup on the other machine (aka standby)
3. start the instance on the standby machine as a standby and point to primary as the master
4. that's it.  Db2 will fetch the relevant WAL (active) logs and start applying the logs to catch up.
5. Once it has caught up with the primary, it is in PEER mode.

To failover from master to slave

On the standby issue db2 takeover database dbname
that's it. it will flip master and standby and reverse their roles.
[ I am aware that why it is impossible in PG to reverse roles like this ]

Long time back I use to work in SQL Server and the setup of mirroring was as simple as DB2.

Negative of db2 replication:  In DB2 replication, lot of restriction on standby to be used as a read-only.
One DDL statement or stats collection in the primary will put the standby in replay only mode where
it will kick out all sessions on standby until DDL/stats is applied on standby also.
Note: My knowledge of db2 replication is bit dated as I have not worked on it since 2014.

I love PG, but definitely replication management can be better.

pgsql-general by date:

Previous
From: bhargav kamineni
Date:
Subject: Re: Slot issues
Next
From: Ravi Krishna
Date:
Subject: Re: Slot issues