From: Bei Xu <be...@ad...> - 2013-03-21 15:13:51
|
Hi, Koichi: Base on your reply, Since slave is a copy of master, the slave has the same GTM_proxy listed in postgresql.conf as the master, it will connect to server3's proxy AFTER SLAVE IS STARTED, And we will only change the slave's proxy to server 4 AFTER promotion, correct? Thus, looks like SLAVE needs to connect to A PROXY at ALL TIME: before promotion is server3's proxy, after promotion is server 4's proxy. Please take a look at following 2 senarios: Senario1: If slave was configured with server4's proxy AFTER SLAVE IS STARTED, upon server 3 failure, we will do : 1) promote on slave Since slave is already connect server 4's proxy, we don't have to do anything here. senario2: If slave was configured with server3's proxy AFTER SLAVE IS STARTED, upon server 3 failure, we will do: 1) restart slave to change proxy from server3's proxy value to server4's proxy value 2) promote on slave Obviously, senario1 has less steps and simpler, senario2 is suggested by you. Is there any reason you suggested senario2? My concern is, If a slave is connect to any active proxy (the proxy is started and pointing to the GTM), will the transaction be applied TWICE? One from proxy, one from the master? On 3/21/13 12:40 AM, "Koichi Suzuki" <koi...@gm...> wrote: >Only after promotion. Before promotion, they will not be connected >to gtm_proxy. > >Regards; >---------- >Koichi Suzuki > > >2013/3/21 Bei Xu <be...@ad...>: >> Hi Koichi: >> Thanks for the reply. I still have doubts for item 1. If we setup >> proxy on server 4, do we reconfigure server 4's coordinator/datanodes to >> point to server 4's proxy at ALL TIME(after replication is setup, I can >> change gtm_host to point to server4's proxy before I bring up slaves) or >> only AFTER promotion? >> >> >> On 3/20/13 11:08 PM, "Koichi Suzuki" <koi...@gm...> wrote: >> >>>1. It's better to have gtm proxy at server 4 when you failover to this >>>server. We need gtm proxy now to failover GTM while >>>coordinators/datanodes are running. When you simply make a copy of >>>coordinator/datanode with pg_basebackup and promote them, they will >>>try to connect to gtm_proxy at server3. You need to reconfigure them >>>to connect to gtm_proxy at server4. >>> >>>2. Only one risk is the recovery point could be different from >>>component to component, I mean, some transaction may be committed at >>>some node but aborted at another because there could be some >>>difference in available WAL records. It may possible to improve the >>>core to handle this to some extent but please understand there will be >>>some corner case, especially if DDL is involved in such a case. This >>>chance could be small and you may be able to correct this manually or >>>this can be allowed in some applications. >>> >>>Regards; >>>---------- >>>Koichi Suzuki >>> >>> >>>2013/3/21 Bei Xu <be...@ad...>: >>>> Hi, I want to set up HA for pgxc, please see below for my current >>>>setup. >>>> >>>> server1: 1 GTM >>>> server2: 1 GTM_Standby >>>> server3 (master): 1 proxy >>>> 1 coordinator >>>> 2 datanode >>>> >>>> Server4: (stream replication slave) : 1 standalone proxy ?? >>>> 1 replicated coordinator (slave of >>>> server3's coordinator) >>>> 2 replicated datanode (slave of >>>> server3's datanodes) >>>> >>>> >>>> server3's coordinator and datanodes are the master of the server4's >>>> coordinator/datanodes by stream replication. >>>> >>>> Question. >>>> 1. Should there be a proxy on server 4? If not, which proxy should >>>>the >>>> server4's coordinator and datanodes pointing to? (I have to specify >>>>the >>>> gtm_host in postgresql.conf)/ >>>> 2. Do I have to use synchronous replication vs Asynchrous replication? >>>>I am >>>> currently using Asynchrnous replication because I think if I use >>>> synchronous, slave failour will affect master. >>>> >>>> >>>>----------------------------------------------------------------------- >>>>-- >>>>----- >>>> Everyone hates slow websites. So do we. >>>> Make your web apps faster with AppDynamics >>>> Download AppDynamics Lite for free today: >>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>> _______________________________________________ >>>> Postgres-xc-developers mailing list >>>> Pos...@li... >>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >>>> >>> >> >> > |