Re: Slot issues

From: Ravi Krishna <srkrishna1(at)aol(dot)com>
To: Vijaykumar Jain <vjain(at)opentable(dot)com>
Cc: bhargavpostgres(at)gmail(dot)com, andres(at)anarazel(dot)de, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Slot issues
Date: 2018-10-14 21:49:30
Message-ID: 36CCE7FA-BD81-409F-AE79-224C1FB68053@aol.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ravi Krishna 2018-10-14 21:52:30 Re: Slot issues
Previous Message bhargav kamineni 2018-10-14 21:48:35 Re: Slot issues