Re: [Postgres-xc-general] Some questions about postgres-XC

[Yehezkel H. <hor...@ch...>]

2nd try.
Can you please answer my questions below?

TIA

Yehezkel Horowitz

-----Original Message-----
From: Yehezkel Horowitz 
Sent: Tuesday, October 08, 2013 2:30 PM
To: 'Michael Paquier'; <pos...@li...>
Subject: RE: [Postgres-xc-general] Some questions about postgres-XC

>> My goal - I have an application that needs SQL DB and must always be 
>> up (I have a backup machine for this purpose).
>Have you thought about PostgreSQL itself for your solution. Is there any reason you'd need XC? Do you have an amount of data that >forces you to use multi-master architecture or perhaps PG itself could handle it?

I need multi-master capability, as clients might connect to both machines at the same time; Yes - my tables will be replicated.

>Yep, this is doable. If all your data is replicated you would be able to do that. However you need to keep in mind that you will not be able to write new data to node B if node A is not accessible. If you data is replicated and you need to update a table, both nodes need to work.

This is a surprise for me, this wasn't clear in the documentation I read nor at some PG-XC presentations I looked at in the internet.
Isn't this point one of the conditions for High-Availability of DB - allowing work to continue even if one of the machines failed?

>Or if you want B to be still writable, you could update the node information inside it, make it workable alone, and when server A is up again recreate a new XC node from scratch and add it again to the cluster.

What is the correct procedure for doing that? Is there a pgxc_ctl commands for doing that?

>> My questions:
>>
>> 1.       In your docs, you always put the GTM in dedicated machine.
>> a.       Is this a requirement, just an easy to understand topology or best
>> practice?
>GTM consumes a certain amount of CPU and does not need much RAM, while for your nodes you might prioritize the opposite.
>> b.      In case of best practice, what is the expected penalty in case the
>> GTM is deployed on the same machine with coordinator and datanode?
>CPU resource consumption and reduction of performance if your queries need some CPU with for example internal sort operations among other things.
O.K  got it; For now I'm trying to make it work, afterwards I'll take care for make it work faster.

>> 2.       What should I do after Machine A is back to life if I want:
>> a.       Make it act as a new slave?
>> b.      Make it become the master again?
>There is no principle of master/slave in XC like in Postgres (well you could create a slave node for an individual Coordinator/Datanode). >But basically in your configuration machine A and B have the same state.
>Only GTM is a slave.

Sorry, I meant in the context of GTM - how should I make MachineA a new GTM-slave or make it a GTM-master again?