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.
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 |