postgres-xc-developers Mailing List for Postgres-XC

PGXC Hackers,

What is the simplest way to tell if the server one has connected to is XC? Try to call pgxc_version()? `SHOW gtm_host`? Or is there something else to check, maybe something that doesn't throw an exception?

Thanks,

David

Hi, Julian, 

> > I am thinking 3 choices as below:
> >
> > 1. Pacemaker and Corosync.
> > I have little experience on Linux HA, so one week passed, I even can
> > not install them successfully, including
Pacemaker/Corosync/crmsh/resouce
> agent.
> > There are some website mentioned Pacemaker/corosync can help PGXC to
> > build a HA infrastructure, but I can not find a comprehensive guide to
> > do it. There are much more commponents in PGXC than PG, I think I
> > should learn how to build it based on PG first.
> 
> I know separate XC project to provide Pacemaker/Corosync resource
> agent for XC.   Please let me push them to provide info.

We are planning to release resource agent for pacemaker/heartbeat within a
few months.
Basic idea is to manage pairs of Master-Slave for Datanode, Coordinator and
GTM at each server by pacemaker.
Hopefully this could be one of the solution to HA feature at XC.

> > 2. Zookeeper
> > It seems that Zookeeper has the ability to build a HA solution for
> > PGXC, which have the similar function with Pacemaker, but I have to
> > develop the heartbeat function for Zookeeper to
> > start/stop/monitor/failover PGXC. And I do not know if my understand is
> right.
> 
> Sorry, I'm not familiar with Zookeeper.
>
> > 3. PGXC support HA internally.
> > Because the table of pgxc_nodes in coordinator already have some
> > information about the cluster, it can be enhanced to save the
> > Master/Slave relations, it is replicated between all coordinators,
> > then it can used as a CRM(Cluster Resource Management, as Pacemaker)
> compoment.
> > And the coordinator will connect to datanode/gtm/other coordinator in
> > its regular work, so the heartbeat function exists natually. Even when
> > the database is in the spare time, the coordinator can send a simple
> > query as "select 1+1" to datanodes as the heartbeat ticks.
> > What need to do is that, the coordinator will start a new process when
> > starting, the new process will act as a heartbeat /resouce_agent to
> > monitor the cluster status, and restart/failover once one commponent
fails.

How about monitoring coordinator and GTM? Do you have any idea?

> > As my initial understanding, Choice 3 is better than Choice 2 which is
> > better than Choice 1. But for the development effort, the order is
> > reversed, Choice 1 is easy achieved based on current existing codes.

What do we mean by better?
My requirement is as follows : 

Availability :
 - Shorten Failure detection
 - Shorten downtime at Failover / Switchover

Node management usability : 
 - We can manage Slave node as well as Master node into XC Cluster
 - Enables node monitoring and management at psql
 - No need to install / configure external tools : pacemaker / colosync 

What else?

Regards,

Hisada

> > I am very appreciated that you can share your advice with me.
> 
> Yes, I do agree with this solution.   I'd like to have this as a part
> of XC release 1.3.



> PGXC internal HA should be integrated with other monitoring feature such
as
> server hardware, power and network.
> 
> It will be exciting to begin this discussion in this mailing list.
> 
> Regards;
> ---
> Koichi Suzuki
> 
> >
> > Thanks
> > Julian
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical
> > Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.
> > clktrk _______________________________________________
> > Postgres-xc-developers mailing list
> > Pos...@li...
> > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> >
> 
> -------------------------------------------------------------------------
> -----
> WatchGuard Dimension instantly turns raw network data into actionable
security
> intelligence. It gives you real-time visual feedback on key security
issues
> and trends.  Skip the complicated setup - simply import a virtual
appliance
> and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clk
> trk
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers

On Feb 3, 2014, at 5:06 PM, Koichi Suzuki <koi...@gm...> wrote:

> When you turn off enforce_two_phase_commit to off, you should be
> careful that if a transactions is involved with  one node (coordinator
> and/or datanode), commit is not associated with prepare transaction
> and you may need manual database recovery if one of the commits fails.
> 
> We're using this in the regression test mainly to maintain temporary
> object usage.    We can distinguish such implicit 2PC from explicit
> ones so we may be able to enable TEMP objects in such case in 1.3 or
> later.

Yeah, I just won’t ever be able to run pgTAP until proper temporary table and SAVEPOINT support is in. I can live with this, as I can always run my tests against Postgres, even if we deploy to XC.

Should get to loading more data into my test cluster this week or next!

Thanks,

David

When you turn off enforce_two_phase_commit to off, you should be
careful that if a transactions is involved with  one node (coordinator
and/or datanode), commit is not associated with prepare transaction
and you may need manual database recovery if one of the commits fails.

We're using this in the regression test mainly to maintain temporary
object usage.    We can distinguish such implicit 2PC from explicit
ones so we may be able to enable TEMP objects in such case in 1.3 or
later.

Regards;
---
Koichi Suzuki


2014-02-04 David E. Wheeler <DA...@ju...>:
> On Feb 3, 2014, at 6:20 AM, Koichi Suzuki <koi...@gm...> wrote:
>
>> Good news.   Then this restriction can be resolved in XC-1.3.
>
> Meanwhile, it looks like I can work around it by sticking this in the functions that create or drop temporary objects in EXECUTE statements:
>
>       SET LOCAL enforce_two_phase_commit = off;
>
> Now, if only SAVEPOINTS were supported (we use a lot of exception-handling in functions), we would be set! Is SAVEPOINT support on the road map? I only see it mentioned as unsupported.
>
> https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Roadmap
>
> Thanks,
>
> David
>

On Feb 3, 2014, at 6:20 AM, Koichi Suzuki <koi...@gm...> wrote:

> Good news.   Then this restriction can be resolved in XC-1.3.

Meanwhile, it looks like I can work around it by sticking this in the functions that create or drop temporary objects in EXECUTE statements:

      SET LOCAL enforce_two_phase_commit = off;

Now, if only SAVEPOINTS were supported (we use a lot of exception-handling in functions), we would be set! Is SAVEPOINT support on the road map? I only see it mentioned as unsupported.

https://sourceforge.net/apps/mediawiki/postgres-xc/index.php?title=Roadmap

Thanks,

David