Apigee support for multiple postgres as stand by

Hi,

we are trying to have OPDK setup with 2 Data centers and in each DC we have 2 Postgres servers . so total of 4. we are now trying to setup the Apigee with one master and the remaining 3 postgres as slaves. so do Apigee supports installing of multiple stand by or does it take only one IP address as stand by.

for Eg: if IP1 - Master , IP2,IP3,IP4 as stand by. then below configuration works ? or it is smilar to LDAP_PEER where it take only one IP address.

PG_MASTER=$IP1

PG_STANDBY="$IP2 $IP3 $IP4"

1 6 1,312
6 REPLIES 6

As far as i know, such a configuration is not officially supported.

Officially, you can run a couple of postgres instances in a master/slave setting in a single data center/across data centers.

Hi @Rajesh Kumar

I would say we can do it as long as the servers are talking to each other but most importantly ,by design how feasible it is for production environment ?

As per the documentation , during the upgrade process (in case of upgrading the Postgres) we create the new stand-by(slave) node to the existing master/slave nodes. This clears that we can have the setup with multiple slave nodes. So far with my experience I have seen the data being synced on all the stand-by nodes.

But how to achieve with the new installation setup is key factor to determine ; whether to use

PG_STANDBY = $IP2 $IP3 $IP$ // with spaces between IP address  or 

Node2:
PG_STANDBY = $IP2 //Changes the stand-by instance on respective nodes

Node3:
PG_STANDBY= $IP3

Node4:
PG_STANBY= $IP4 

If you have test machines , you can install it with both the configurations and observe the behavior .

Most importantly verify the configuration file after the installation ( if you are willing to setup)

/opt/apigee/apigee-postgresql/conf/pg_hba.conf 

with entries starting with "host replication "
 

I have a curious question , Why do you need master slave in one data center and other slave in different different data center; instead you can master in one data center and slave in other data center as in below

7025-postgres.png

Thanks,

Latheef D

Hi All, has anyone tested this scenario? is it feasible? just wanted to know whether below combination is possible or not?

I am trying to setup DR for existing DC, so i'm planing to setup a separate master slave for Postgres.

would it be possible?

.

Hi @Mallikarjuna pikkili , As per the initial question posted by me we wanted one master and multiple slaves where DC1 should have master and slave and DC2 should have 2 slaves but when i had tried during that time it was not achievable as configuration file used to take only one slave IP only , so finally what we had gone with was DC1 is having master and DC2 is having slave. so we have only 2 postgres servers in total ( master and slave ) instead of initial thought of having 4 postgres. Currently this setup is running fine in production for us from past 1 year. Hope this as answered your question.


HI Rajesh, Thanks for your quick response. Even I though same for my first question. With respect to my second question, I'm not sure whether we can achieve or not, but analytics data will not sync between two DC's if we set up a separate master slave Postgres.

Hi Mallikarjuna , i feel its achievable For your scenario we should be having the design where DC 1 should have PG Master and DC 2 which is your DR should be having PG slave .In the event of DC1 down then you need to switch your PG slave to master (for this you can refer apigee doc) for this switch to happen it can be either manual way or programmatic way by this apigee will be able to capture analytics data and once your DC 1 is back you need to make DC 1 PG firstly to slave and make it as master next which will restore all your data. we had done this kind of experiment in our beta boxs before moving to prod.

And there will be no data loss during the time of switch as the apigee has the capability to hold the analytics data with qpid server until PG is available( note this data which qpid server can hold is of limited in size based on your configuration settings).