postgres-xc-general Mailing List for Postgres-XC (Page 53)

On Tue, Oct 30, 2012 at 4:58 AM, Vladimir Stavrinov <vst...@gm...>wrote:

> On Mon, Oct 29, 2012 at 01:59:47PM -0700, Roger Mayes wrote:
>
> >    Restoring a virt from an image is one way of restoring from a
> >    backup.  It's a bit quicker and more thorough, unless you have
>
> Normally You are restoring database from sql dump. If You want to do
> this with data files, then You should synchronize all of them over the
> cluster.
>
> >    our hosting environment is limited.  They're inexpensive enough for
> >    us because they use commodity hardware, but using commodity
>
> But cloud infrastructure with all management tools and service itself
> costs money too. One of my providers offered me cloud instead of hardware
> rent. But calculation showed it's twice more expensive for the same
> capacity. Though it may be not a common case due to specific
> requirements, but nevertheless I think cloud is not suitable for
> cluster. Though I see the convenience for customers may overcome other
> factors.
>
> >    hardware means they can only give us so much cpu, ram, io, and
> >    network bandwidth on a single host.  Hence the need for clustering.
>
> First, You loose performance with additional level for virtual machine
> (though not so much). And second, You can't upgrade kernel running on
> hardware host, leaving it on providers own. But this impacts not only
> performance, but reliability too. Though I see it is not interesting for
> You as You are getting that capacity what You are paying for.
>
> >    Security became the victim of "speed" meaning system performance,
> >    or "speed" meaning expediency as far as getting it setup and
>
> First is right.
>
> >    running goes?  Nobody should ever run database processes as the
> >    root user.  And they should never open direct database access ports
> >    to the outside world.
>
> You are absolutely right here.
>
> >    The users themselves don't expect their posts to stay around forever.
>
> First, they prefer delete unneeded data them self, than loose what they
> need.
> Second, they can tolerate to loose old data, but just this data You can
> restore
> from backup. But they don't want to loose recent data, that they certainly
> lose
> at system crash. With lost data You can lose Your users, not only as
> records in
> database, that was dropped on crash, but existent users as persons, who
> don't
> want to use Your service any more, as well as new potential users, who will
> never uses Your service.
>
> >    As long as the downtime is not within the first few hours after
> >    Taylor makes her post, it's not a huge deal.
>
> But You can not plan the time of Your crash. More over under peak load
> chance
> to fail increased. And low probability of crash doesn't means it never
> occur.
> It happens at the "best" time when You don't expect. The Chernobyl disaster
> occured as result of overlapping of five events, every of which was low
> probability.
>
> >    I guess we have HA in the sense that we can continue to operate if
> >    one of our load balanced front end web servers goes down, as long
> >    as it doesn't happen right when we're at peak load.  But our
>
> There are no problems with HA for web servers as such. There are number of
> different solutions. But we are talking here about database and it is a
> quite different problem.
>
> >    memcached clusters and database clusters have never yet been really
> >    set up to continue running if we were to lose a node.  Although it
>
> Are You sleeping well? I was already scared.
>
> >    would help us a lot of we could, because then we could handle less
> >    risk-tolerant, higher dollar ventures without having to get into
> >    dealing with Oracle (which creates a lot of risk by itself, because
> >    of the high costs involved).
>
> As I mentioned early, even RAC may crash. Besides, it have no write
> scalability
> (Your lovely commercial software). In my practice in the past I did some
> fault
> tolerant setup based on Oracle Data Guard technology, but I was satisfied
> with
> it.
>
> OK, all Your arguments make some sense. I agree, in Your example there may
> be
> some tolerance for data lost and down time, in some sense and to some
> degree.
> But this is Your reasoning only. Can You imagine crash of Your system in
> reality? I would say, if You need scalability means You are running a big
> system. With big system You most likely will suffer big losses in case of
> disaster.
>
> P.S. Your last message did not arrived to mailing list. If it is not
> mistake, I
> will leave it untouched. But If You want, I can bounce both Your message
> and my
> response to mailing list as is, without modification. It is what my open
> source
> software can, but Your lovely commercial can not to do.


That's pretty funny.  That's a good point that there are some things open
source software can do that no currently available well-known commercial
software can.  The lack of write scalability in Oracle is a big one.

Odd that their list publishes our email addresses, and if I hit "reply" (in
gmail), it goes to the person who made the post rather than to the list.
 That's not the way most other email lists work.  I haven't used any
commercial software for several years now, unless you count gmail.  I guess
gmail is more-or-less commercial software, isn't it?  Lol.

It seems like our conversation has gone a bit afield of the list's topic,
anyway.

With virtual cloud servers, we can rent a bunch of hardware for the space
of a few hours, while most of the time renting such a small amount of
hardware that the cost is almost nothing.

No I don't sleep well, and I'd like to get out of my situation as soon as
possible, but at least I have a little food on the table for the moment.

So have you found any way to do get write scalability and high
availability?   I've not yet thoroughly investigated all of the NoSQL
systems yet.




> -----
> --
>
> ***************************
> ##  Vladimir Stavrinov
> ##  vst...@gm...
> ***************************
>
>

On Mon, Oct 29, 2012 at 01:59:47PM -0700, Roger Mayes wrote:

>    Restoring a virt from an image is one way of restoring from a
>    backup.  It's a bit quicker and more thorough, unless you have

Normally You are restoring database from sql dump. If You want to do
this with data files, then You should synchronize all of them over the
cluster.

>    our hosting environment is limited.  They're inexpensive enough for
>    us because they use commodity hardware, but using commodity

But cloud infrastructure with all management tools and service itself
costs money too. One of my providers offered me cloud instead of hardware
rent. But calculation showed it's twice more expensive for the same
capacity. Though it may be not a common case due to specific
requirements, but nevertheless I think cloud is not suitable for
cluster. Though I see the convenience for customers may overcome other
factors.

>    hardware means they can only give us so much cpu, ram, io, and
>    network bandwidth on a single host.  Hence the need for clustering.

First, You loose performance with additional level for virtual machine
(though not so much). And second, You can't upgrade kernel running on
hardware host, leaving it on providers own. But this impacts not only
performance, but reliability too. Though I see it is not interesting for
You as You are getting that capacity what You are paying for.

>    Security became the victim of "speed" meaning system performance,
>    or "speed" meaning expediency as far as getting it setup and

First is right.

>    running goes?  Nobody should ever run database processes as the
>    root user.  And they should never open direct database access ports
>    to the outside world.

You are absolutely right here.

>    The users themselves don't expect their posts to stay around forever.

First, they prefer delete unneeded data them self, than loose what they need.
Second, they can tolerate to loose old data, but just this data You can restore
from backup. But they don't want to loose recent data, that they certainly lose
at system crash. With lost data You can lose Your users, not only as records in
database, that was dropped on crash, but existent users as persons, who don't
want to use Your service any more, as well as new potential users, who will
never uses Your service.

>    As long as the downtime is not within the first few hours after
>    Taylor makes her post, it's not a huge deal.

But You can not plan the time of Your crash. More over under peak load chance
to fail increased. And low probability of crash doesn't means it never occur.
It happens at the "best" time when You don't expect. The Chernobyl disaster
occured as result of overlapping of five events, every of which was low
probability.

>    I guess we have HA in the sense that we can continue to operate if
>    one of our load balanced front end web servers goes down, as long
>    as it doesn't happen right when we're at peak load.  But our

There are no problems with HA for web servers as such. There are number of
different solutions. But we are talking here about database and it is a
quite different problem.

>    memcached clusters and database clusters have never yet been really
>    set up to continue running if we were to lose a node.  Although it

Are You sleeping well? I was already scared.

>    would help us a lot of we could, because then we could handle less
>    risk-tolerant, higher dollar ventures without having to get into
>    dealing with Oracle (which creates a lot of risk by itself, because
>    of the high costs involved).

As I mentioned early, even RAC may crash. Besides, it have no write scalability
(Your lovely commercial software). In my practice in the past I did some fault
tolerant setup based on Oracle Data Guard technology, but I was satisfied with
it.

OK, all Your arguments make some sense. I agree, in Your example there may be
some tolerance for data lost and down time, in some sense and to some degree.
But this is Your reasoning only. Can You imagine crash of Your system in
reality? I would say, if You need scalability means You are running a big
system. With big system You most likely will suffer big losses in case of
disaster.

P.S. Your last message did not arrived to mailing list. If it is not mistake, I
will leave it untouched. But If You want, I can bounce both Your message and my
response to mailing list as is, without modification. It is what my open source
software can, but Your lovely commercial can not to do.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

On Mon, Oct 29, 2012 at 4:56 AM, Vladimir Stavrinov <vst...@gm...>wrote:

> On Sun, Oct 28, 2012 at 5:35 AM, Shavais Zarathustra <sh...@gm...>
> wrote:
>
> > Well, the point would be to get a replacement server going, for the
> server
> > that died, with all the software installed and the configuration set up,
> > after which my hope has been that we'd be able to reinitialize the
> database
> > on that host and perform some kind of recovery process to get it back up
> and
> > working within the cluster.  But maybe that requires some of the HA
> features
> > that you're talking about that XC doesn't have working yet?
>
> With HA there will no down time, so You will have enough time for
> recovering failed node. Without HA You should recreate cluster from
> scratch from backup. In both cases virtual machine helps not so much.
>
>
Restoring a virt from an image is one way of restoring from a backup.  It's
a bit quicker and more thorough, unless you have something like Legato.

> clustering stuff, together with Oracle's database clustering, which was
> all
>
> I heard a story where whole bank was crashed on RAC. Even HA did not help.
>
> > of a brave new/old world for me, with all this poor man's Open Source
> stuff,
>
> "poor man's" ? Great!
>
>
There are a lot of sort of dirty gems scattered about the muddy, sea weed
and jelly fish-litered beach of Open Source software, which with a bit of
manual buffing, are quite beautiful in their particular ways - but that
landscape is not to be compared with the pristine, opulent castles and
treasure rooms of commercial software.  But then, neither is the price tag.


> > Well, the hardware they have at these pseudo-cloud datacenters is all
>
> What You are describing here and below is cloud infrastructure that
> itself has scalability and HA, what cluster must have too. So what for
> do You want one inside other? You loose efficiency and money.
>
>
As I explained before, the scalability offered by a single host in our
hosting environment is limited.  They're inexpensive enough for us because
they use commodity hardware, but using commodity hardware means they can
only give us so much cpu, ram, io, and network bandwidth on a single host.
 Hence the need for clustering.


> >> logs should be handled on every node, it is not so simple.
> >
> > Yeah, I was thinking this was probably the case.  So what I'm not sure
> of is
> > what you do after your datanode has been recovered as far as you can get
> it
> > recovered using the usual single database recovery techniques - how do
> you
>
> Without HA at this point down time started again. And if You succeed
> in recovering at some point in time where this node will consistent
> with cluster, then You will be happy, otherwise You will recreate Your
> cluster from scratch from backup again.
>
> > Unix Admin "is only as good as their backups".  That's certainly the
> truth.
>
> No doubt, definitely! Backup always and everywhere. But with backup
> You can recover Your system at some point in past. So you have both
> joys: down time and data lost in this case too. Backup is not
> alternative for HA and vice verse: we need them both.
>
> > But I'm not concerned about the security of my DBA role, in fact I've
> been
>
> One developer boasted me how he can do database user becomes unix user
> root and shuts down the system. The answer on my horror was something
> similar what we are reading here: the security there becomes the
> victim of speed. And it was very serious and responsible institution
> where this database was running.


Security became the victim of "speed" meaning system performance, or
"speed" meaning expediency as far as getting it setup and running goes?
 Nobody should ever run database processes as the root user.  And they
should never open direct database access ports to the outside world.


> > need a throat to cut before I can cut it.  The risk of a crash is small
> and
> > tolerable, but if I'm not convinced I'll be able to handle the load -
> that's
> > a show stopper.
>
> If You
> need cluster means You are doing something that require HA.

What data You are  processing that requires scalability?


As I mentioned before - one example has been forum posts from Taylor Swift
fans in reaction to Taylor Swift making a Facebook post or a Twitter Tweet.
 If we lose that data at some point in the future, it's not anywhere near
as important as being able to handle a whole lot of people making and
reading those posts all at once.  In fact, we eventually delete the data
our selves.  That's just one example.


> Is it garbage You willing to loose?


The users themselves don't expect their posts to stay around forever.


> What are those business processes that make Your
> heavy load?


Taylor Swift makes a Facebook post.  250 thousand Taylor Swift fans from
all over the country immediately jump onto our system and start messaging
each other, and posting videos, pictures, etc., and over the course of the
next several hours, several million other people eventually find their way
to the site.  We collect analytics on all that traffic and make (general
trend) reports to various commercial interests.


> Are they nonsense that can tolerate down time?


As long as the downtime is not within the first few hours after Taylor
makes her post, it's not a huge deal.


> Please
> tell me, do You have cluster that running without HA? Or do you know
> such?
>
>
We have HA in the sense that apart from the backplanes, there's no single
point of failure in our hardware setup.  And, I guess we have HA in the
sense that we can continue to operate if one of our load balanced front end
web servers goes down, as long as it doesn't happen right when we're at
peak load.  But our memcached clusters and database clusters have never yet
been really set up to continue running if we were to lose a node.

Although it would help us a lot of we could, because then we could handle
less risk-tolerant, higher dollar ventures without having to get into
dealing with Oracle (which creates a lot of risk by itself, because of the
high costs involved).

> I am sure you already know that a Postgres-XC cluster needs a unique GTM
> (global transaction manager) to feed global transaction ID values and
> global snapshots to each node of the cluster, the same GTM is used for the
> feed of sequence values in a global way.
> As a start if you want to have a look at how it is managed in XC, for the
> postgres backend side have a look at nextval_internal in
> src/backend/commands/sequence.c, we put in the PG code a hook called
> GetNextValGTM to get the next global sequence value from GTM. There are
> similar hooks for CREATE/ALTER/DROP SEQUENCE. All the backend-side client
> APIs related to GTM are located in src/backend/access/transam/gtm.c.
> 
> On the GTM side, I would recommend you to have a look at src/gtm/main,
> mainly gtm_seq.c which contains all the sequence-related APIs.
> Also, the message types exchanged between GTM and backend nodes are listed
> in src/include/gtm/gtm_msg.h. MSG_SEQUENCE_GET_NEXT is for example the
> message type used to get the next global value of a sequence. Look at how
> messages of this type are managed on backend and GTM side and you will
> understand easily the process flow.

Thanks for a quick response. I will take a look at the source code.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

On Fri, Nov 2, 2012 at 9:50 AM, Tatsuo Ishii <is...@po...> wrote:

> Hi,
>
> I'm wondering how sequences are handled in Postgres-XC. Could you
> please let me know where I can start with understanding this? Docs?
> Source code? Thanks in advance,
>
I am sure you already know that a Postgres-XC cluster needs a unique GTM
(global transaction manager) to feed global transaction ID values and
global snapshots to each node of the cluster, the same GTM is used for the
feed of sequence values in a global way.
As a start if you want to have a look at how it is managed in XC, for the
postgres backend side have a look at nextval_internal in
src/backend/commands/sequence.c, we put in the PG code a hook called
GetNextValGTM to get the next global sequence value from GTM. There are
similar hooks for CREATE/ALTER/DROP SEQUENCE. All the backend-side client
APIs related to GTM are located in src/backend/access/transam/gtm.c.

On the GTM side, I would recommend you to have a look at src/gtm/main,
mainly gtm_seq.c which contains all the sequence-related APIs.
Also, the message types exchanged between GTM and backend nodes are listed
in src/include/gtm/gtm_msg.h. MSG_SEQUENCE_GET_NEXT is for example the
message type used to get the next global value of a sequence. Look at how
messages of this type are managed on backend and GTM side and you will
understand easily the process flow.
-- 
Michael Paquier
http://michael.otacoo.com

Hi,

I'm wondering how sequences are handled in Postgres-XC. Could you
please let me know where I can start with understanding this? Docs?
Source code? Thanks in advance,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

Can't wait to get my hands on the
yet-to-be-finished-and-opened-to-the-world new features!

It was a good read, thanks!
PP

On 31/10/12 05:25, Koichi Suzuki wrote:
> Hi,
>
> My presentation material at PGconf.EU 2012 is available at
> http://wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf
> or
> http://wiki.postgresql.org/wiki/PostgreSQL_Conference_Europe_Talks_2012
>
> Enjoy.
> ----------
> Koichi Suzuki
>
> ------------------------------------------------------------------------------
> 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_sfd2d_oct
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general

-- 
Paulo Pires

On Wed, Oct 31, 2012 at 2:25 PM, Koichi Suzuki <koi...@gm...>wrote:

> Hi,
>
> My presentation material at PGconf.EU 2012 is available at
> http://wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf
> or
> http://wiki.postgresql.org/wiki/PostgreSQL_Conference_Europe_Talks_2012
>
Thx.
-- 
Michael Paquier
http://michael.otacoo.com

Hi,

My presentation material at PGconf.EU 2012 is available at
http://wiki.postgresql.org/images/4/44/Pgxc_HA_20121024.pdf
or
http://wiki.postgresql.org/wiki/PostgreSQL_Conference_Europe_Talks_2012

Enjoy.
----------
Koichi Suzuki

On Fri, Oct 26, 2012 at 12:50 PM, Vladimir Stavrinov
<vst...@gm...> wrote:
> On Fri, Oct 26, 2012 at 11:36:24AM -0400, Mason Sharp wrote:
>
>> > It is not the same. What about write? Then You should teach Your
>> > application where to read and where to write. What about transparency?
>>
>> You can get more write scalability with more data nodes.
>
> How it is related with cite above? It is not about scalability, it is
> about transparency. No matter how much nodes for writes we have. But if
> You have separate points for read and write, then You loose transparency.
>

In XC you just write to a coordinator, it interacts with the data
nodes where the actual user data is.

>> It took years until PostgreSQL itself had built-in replication.
>
> I don't blame You don't implement something yet. We have something other
> point of controversy here. The discussion in these two close threads is
> about what "must have" and what should not. It is about priority and
> concept.
>
>> I think most on here also feel strongly about having HA,
>
> But this discussion shows something else. All my opponents (and I still
> saw no one supporter ) here very strongly insists, that HA is not high
> priority for XC or should not be implemented in the core. But my
> endlessly repeated question "Who wants cluster without HA?" got never
> answered in any form. So it is become mystery question.
>

I think everyone is trying to be helpful, answer questions and provide
opinions. It is not that HA is not possible; HA can be provided
outside of the core and has been done by multiple people in different
ways.  There are probably varying opinions on how best to do this, but
perhaps the next step is to come up with best practices with the
current state of the code.

>> it is just not built into the core at present.
>
> "at present" means it will built or possible in the future. Good news.
> It is first ray of light in the darkness or the light at the end of the
> tunnel.  And it is more important that it come from "Architect and
> development leader" of XC. Though, it is characteristically, I am not
> surprised, something like this I expected. Thanks.
>

More than one person contributed to the original architecture.  The
project leader of Postgres-XC is Koichi Suzuki.

> --
>
> ***************************
> ##  Vladimir Stavrinov
> ##  vst...@gm...
> ***************************
>



-- 
Mason Sharp

StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Services

On Sat, Oct 27, 2012 at 04:23:12PM -0400, Mason Sharp wrote:

> In XC you just write to a coordinator, it interacts with the data
> nodes where the actual user data is.

Right. But we are talking here about standby. Do You remember? Would You
 say it is accessible via coordinator too?

> opinions. It is not that HA is not possible; HA can be provided
> outside of the core and has been done by multiple people in different
> ways.  There are probably varying opinions on how best to do this, but

I didn't mean "HA is not possible". But if You say "HA is not
implemented in core at present", that means it may be implemented there
in the future. And if no answer to question: "Who want XC without HA"
means there are no XC used without HA, i.e. it is "Must Have", then next
question should be: "Why HA should be outside XC?"

> More than one person contributed to the original architecture.  The
> project leader of Postgres-XC is Koichi Suzuki.

I know. My comment here was not about architecture. This is about people mentality.


***************************
###  Vladimir Stavrinov
###  vst...@gm...
***************************

On Sun, Oct 28, 2012 at 5:35 AM, Shavais Zarathustra <sh...@gm...> wrote:

> Well, the point would be to get a replacement server going, for the server
> that died, with all the software installed and the configuration set up,
> after which my hope has been that we'd be able to reinitialize the database
> on that host and perform some kind of recovery process to get it back up and
> working within the cluster.  But maybe that requires some of the HA features
> that you're talking about that XC doesn't have working yet?

With HA there will no down time, so You will have enough time for
recovering failed node. Without HA You should recreate cluster from
scratch from backup. In both cases virtual machine helps not so much.


> clustering stuff, together with Oracle's database clustering, which was all

I heard a story where whole bank was crashed on RAC. Even HA did not help.

> of a brave new/old world for me, with all this poor man's Open Source stuff,

"poor man's" ? Great!

> Well, the hardware they have at these pseudo-cloud datacenters is all

What You are describing here and below is cloud infrastructure that
itself has scalability and HA, what cluster must have too. So what for
do You want one inside other? You loose efficiency and money.

>> logs should be handled on every node, it is not so simple.
>
> Yeah, I was thinking this was probably the case.  So what I'm not sure of is
> what you do after your datanode has been recovered as far as you can get it
> recovered using the usual single database recovery techniques - how do you

Without HA at this point down time started again. And if You succeed
in recovering at some point in time where this node will consistent
with cluster, then You will be happy, otherwise You will recreate Your
cluster from scratch from backup again.

> Unix Admin "is only as good as their backups".  That's certainly the truth.

No doubt, definitely! Backup always and everywhere. But with backup
You can recover Your system at some point in past. So you have both
joys: down time and data lost in this case too. Backup is not
alternative for HA and vice verse: we need them both.

> But I'm not concerned about the security of my DBA role, in fact I've been

One developer boasted me how he can do database user becomes unix user
root and shuts down the system. The answer on my horror was something
similar what we are reading here: the security there becomes the
victim of speed. And it was very serious and responsible institution
where this database was running.

> need a throat to cut before I can cut it.  The risk of a crash is small and
> tolerable, but if I'm not convinced I'll be able to handle the load - that's
> a show stopper.

I don't understand such philosophy. Look into data center: it filled
by lot of rack mount servers either owned or rent by customers. Most
of them have no neither scalability nor HA and they are happy with it.
But this is quite another story: they have no cluster at all. If You
need cluster means You are doing something that require HA. What data
You are  processing that requires scalability? Is it garbage You
willing to loose? What are those business processes that make Your
heavy load?  Are they nonsense that can tolerate down time? Please
tell me, do You have cluster that running without HA? Or do you know
such?

> But it's seems like, for the most part, the important scalability features
> are there at this point, right?

I hope it is true.

> So very next on the list I would think would be HA.

Totally endorse.

>  And it sounds like the XC devs are working fairly feverishly on it.

Basing on what they are writing here, I am not sure about this.

> Without HA, we might someday go out of business - without some claim to
> scalability, we can't get into business to begin with.
>
>
Rightly said.


> Can you (1) do a full dump, then (2) kill, drop and rebuild the
> cluster, and then (3) restore the entire cluster using pg_restore (or psql
> .. < dumpfile) through a coordinator?  This would be a last resort,
> obviously, since I'd lose all the data on every datanode since the last
> full dump, but if I know I can do that, at least I know I have that option.
>
>
Yeah, this is possible and it works. Once I tested this by modifying
pg_hba.conf to disallow all application connections. Then a did a dump of
global objects like users, roles etc. followed by dumps of each of the
databases that I had in my XC cluster. One can also use pg_dumpall if the
current cluster size is not too large. And all this was done by pointing to
a single coordinator, but everything was consistent at the cluster level.

And a subsequent pg_restore/psql to populate a new cluster worked pretty
well.


> as long as I'm going through a coordinator, the effects of the sql
> statements should replicate or distribute across the cluster depending on
> how the table was set up.. right?
>
>
Yes, the above is correct.


> I can probably create a temporary table on a single datanode, through a
> coordinator, just by telling it to distribute that table, and only list the
> one datanode I want it on, right?  Then I can do a data-only restore, of
> just that table, then from there I can use it through a coordinator, and
> affect whatever other tables I need to.
>
>
Yeah, the above is very much possible. See Michael's blog on this:

http://michael.otacoo.com/postgresql-2/pgxc-data-distribution-in-a-subset-of-nodes/


> Hmm, so I wonder what I actually would do if a datanode went down, or if
> the gtm server went down.
>

GTM server can be configured with a GTM-standby and you can failover to the
same in case of issues with the GTM.

A datanode can be configured with synchronous/asynchronous replicas and
again one can failover to the same in case of issues.

Using an HA framework and some PGXC tools that are being worked upon will
help automate this in the coming days.

HTH,
Nikhils


>
> On Fri, Oct 26, 2012 at 10:54 AM, David Hofstee <pg...@c0...> wrote:
>
>> **
>>
>>    1. No cluster without HA option; I agree.
>>    2. Integrate XC into PG; In the future I would like to think of a
>>    single PG instance as a 1-node cluster-able db.
>>
>> I think PGXC is the best thing that is happening. PGXC deserves to be the
>> most usable in the world too (instead of mysql). Gtx,
>>
>>
>> David
>>
>> Vladimir Stavrinov schreef op 2012-10-26 14:46:
>>
>> On Thu, Oct 25, 2012 at 4:13 AM, Michael Paquier
>> <mic...@gm...> wrote:
>>
>> 1) It is not our goal to oblige the users to user an HA solution or
>> another,
>>
>> Sounds fine. Where are those users? Who wants cluster without HA?
>> Everybody when hears word "cluster" implies "HA"
>>
>> Postgres code with XC. One of the reasons explaining that XC is able to
>> keep up with Postgres code pace easily is that we avoid to implement
>> solutions in core that might impact unnecessarily its interactions with
>> Postgres.
>>
>>  You are heroes.  How long You can continue "code pace" on this hard
>> way? This paradigm prevents You do not implement not only HA but lot
>> of other things that is necessary for cluster. I never saw this type
>> of fork. I believe at some point You will either become a part of
>> Postgres or  totally come off and go Your own way. The only question
>> is when? And best answer is "right now".
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> The Windows 8 Center
>> In partnership with Sourceforge
>> Your idea - your app - 30 days. Get started!
>> http://windows8center.sourceforge.net/
>> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
>>
>> _______________________________________________
>> Postgres-xc-general mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>>
>>
>
>
> ------------------------------------------------------------------------------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>


-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

On Fri, Oct 26, 2012 at 4:01 PM, Vladimir Stavrinov <vst...@gm...>wrote:

> On Fri, Oct 26, 2012 at 12:36:25PM -0700, Roger Mayes wrote:
>
> >    they ever were to, I can press a button and have another server up,
> >    of the exact same configuration, in minutes flat, restored,
> >    potentially, to an image created the previous night.  We can
>
> This is good for standalone system, but with cluster those images of all
> nodes should be synchronized.
>
>
Well, the point would be to get a replacement server going, for the server
that died, with all the software installed and the configuration set up,
after which my hope has been that we'd be able to reinitialize the database
on that host and perform some kind of recovery process to get it back up
and working within the cluster.  But maybe that requires some of the HA
features that you're talking about that XC doesn't have working yet?

In the 90's I was an "master's certified" Oracle DBA / Unix Admin, with
special training on "tuning the whole system", blah blah blah.  I setup and
managed various HA clusters, like HP's MC Service Guard, and Sequent's HA
clustering stuff, together with Oracle's database clustering, which was all
based on shared scsi, and fddi and all that.  Ancient history, yes, but I'm
not completely without any clue about HA concepts in general, it's just
kind of a brave new/old world for me, with all this poor man's Open Source
stuff, and with rented cloud servers and so on.


> More over cluster inside virtual machines is something exotic. If all
> Your nodes are running on the same hardware host, what for You need
> cluster?


Well, the hardware they have at these pseudo-cloud datacenters is all
sitting on a combination of copper and fiber backplanes, that connect a
number of cpu's, drives, power supplies, memory boards, et etc.  They try
to eliminate single points of failure except for the backplanes; they can
do more-or-less transparent hot swapping of drives, power supplies, maybe
even cpu boards, depending on which phase of their whole set up your hosts
are running on.  (They're always upgrading and moving their stuff forward,
and once in a while they'll coordinate with you to move your hosts off of
older hardware onto their newer stuff.)  We have QOS guarantees for a
certain amount of processing capacity, IO bandwidth, and Network bandwidth
and so on per host, depending on how we configure them, and our experience
so far with these virtual hosts has been that the TPS and bandwidth levels
are pretty consistent.  It's measurable, we occasionally run some
(sometimes very quick and dirty) benchmarks to make sure, because once or
twice (in 3 years) we've caught them in a misconfiguration in their
equipment, after some maintenance they did, that was limiting us
incorrectly.

But they have a maximum amount of processing, memory, and IO bandwidth that
they can give us per host, and sometimes we need more than that in order
handle the response to something like, say, a Facebook post by Taylor
Swift.  (Boom - millions of hits in the space of a few minutes.
 Unbelievable.  Quite a spectacular thing to watch.)

[ Can you imagine being so famous that with a one-line facebook wall post,
you can single-handedly crash (well, load down to the point of being
essentially halted) any single host setup?  hahaha jeezuz h.  It's a good
thing I'm not, I think it would Drive Me Nutz.  Look out, don't have a bad
facial expression on for 1 second where any camera might happen to catch
you.  Millions of teenagers will have their idealic image of you shattered.
 The men in white coats would come for me after about a week.  (They
probably should have long since dragged me away, actually, but thankfully
I'm not famous enough for them to know it.  I'm whistling dixie at the
moon, waving my arms maniacally and dancing by under their radar, lol.

http://www.youtube.com/watch?v=GUfS8LyeUyM
http://www.youtube.com/watch?v=5yO_P0ZmuBc
http://www.youtube.com/watch?v=uq-gYOrU8bA

YouTube.  Ok, it's awash in visual, symantic and synaptic spam, but it's
infinitely better than the old juke box, and for practically no cost at
all.  We truly do live in the "age of miracles and wonders".  Hey, what
better place than here to share bizarre play lists with a select group of
complete strangers?  I remind you of a song?  Bring it on.) ]

Anyway, ideally what we'd like is to have a nominal setup that we run most
of the time, that we can expand as quickly and as transparently as possible
to a much larger setup that we run for a few hours or a few days at a time,
that we then shrink back to our "business as usual" setup.  But if we have
to, we can have a bunch nominally configured hosts, that we can scale up
(in terms of the number of cpu's, the memory size, the network and io
bandwidth, etc) in advance of a marketing blitz (.ie, one Taylor Swift
facebook post, lol), and then back down afterwards, and if it costs us an
hour or so of down time in each direction, that's not too big of a deal for
us.



> Run standalone system without virtual machine and You've got
> more capacity. Or simply pay for more resources for single virtual
> machine. The same if Your XC nodes are running on different hardware
> nodes: You will use small part of its resources for which You have paid.
> What for do You need virtual machines there? They are needed for Your
> provider to share resources with his customers, but not for You.
>
> I am running XC on virtual machines but for testing and debugging only.
>
> >    HA is important for us, scalability is definitely the more pressing
> >    matter:  Without HA, we might someday go out of business - without
> >    some claim to scalability, we can't get into business to begin
> >    with.
>
> I really enjoy with Your maxim. Your philosophy is applicable for
> everything existing in this wonderful world. We can't loose something we
> don't have. So first we want to have, then we don't want to loose. And
> it is not about priorities, it is about "be or not to be". There even
> nice song exists about this. But what You wrote below proves: You need
> HA first of all.
>
> >    Can you do log shipping, hot backups, and recover a cluster to a
> >    point in time?  If not what is the quickest/best backup/recovery
> >    procedure?  Whatever it is, it is something I'll need to get
> >    scripted and working (I mean I'll write
>
> logs should be handled on every node, it is not so simple.
>
>
Yeah, I was thinking this was probably the case.  So what I'm not sure of
is what you do after your datanode has been recovered as far as you can get
it recovered using the usual single database recovery techniques - how do
you then get it back into the cluster, and get it up to speed and running
in the cluster, etc.  I'm imagining it can be done?  Hopefully it's just a
matter of reading some docs and doing some experimentation.

But I don't think that proves we need HA more than we need scalability, or
even as much.  We can launch without any working recovery plan if we have
to.  But it does us no good to launch if we can't handle the load.  If I'm
wearing my old DBA hat, I know I'm slitting my throat saying that - a DBA /
Unix Admin "is only as good as their backups".  That's certainly the truth.
 But I'm not concerned about the security of my DBA role, in fact I've been
trying hard to cast it off for ages, actually.  But as a business man - I
need a throat to cut before I can cut it.  The risk of a crash is small and
tolerable, but if I'm not convinced I'll be able to handle the load -
that's a show stopper.

But it's seems like, for the most part, the important scalability features
are there at this point, right?  So very next on the list I would think
would be HA.  And it sounds like the XC devs are working fairly feverishly
on it.

On Fri, Oct 26, 2012 at 12:36:25PM -0700, Roger Mayes wrote:

>    they ever were to, I can press a button and have another server up,
>    of the exact same configuration, in minutes flat, restored,
>    potentially, to an image created the previous night.  We can

This is good for standalone system, but with cluster those images of all
nodes should be synchronized. 

More over cluster inside virtual machines is something exotic. If all
Your nodes are running on the same hardware host, what for You need
cluster?  Run standalone system without virtual machine and You've got
more capacity. Or simply pay for more resources for single virtual
machine. The same if Your XC nodes are running on different hardware
nodes: You will use small part of its resources for which You have paid.
What for do You need virtual machines there? They are needed for Your
provider to share resources with his customers, but not for You. 

I am running XC on virtual machines but for testing and debugging only.

>    HA is important for us, scalability is definitely the more pressing
>    matter:  Without HA, we might someday go out of business - without
>    some claim to scalability, we can't get into business to begin
>    with.

I really enjoy with Your maxim. Your philosophy is applicable for
everything existing in this wonderful world. We can't loose something we
don't have. So first we want to have, then we don't want to loose. And
it is not about priorities, it is about "be or not to be". There even
nice song exists about this. But what You wrote below proves: You need
HA first of all.

>    Can you do log shipping, hot backups, and recover a cluster to a
>    point in time?  If not what is the quickest/best backup/recovery
>    procedure?  Whatever it is, it is something I'll need to get
>    scripted and working (I mean I'll write

logs should be handled on every node, it is not so simple.

>    Can you (1) do a full dump, then (2) kill, drop and rebuild the
>    cluster, and then (3) restore the entire cluster using pg_restore
>    (or psql .. < dumpfile) through a coordinator?  This would be a

Yes, without this it become inviable. The only question is about size of
data base and level of load. Depend on this backup procedure may impact
production operation. I am doing such things piping dump directly to
network without any temporary files on intermidiate storage.

>    found myself doing things with dump files, like pulling pieces of
>    them into temporary tables and then deleting and/or updating rows
>    in existing tables based on the data in the dump-loaded temporary
>    tables.  I'm imagining that these general recovery scenarios are
>    not particularly complicated by the fact that I'm working with an
>    xc cluster - as long as I'm going through a coordinator, the
>    effects of the sql statements should replicate or distribute across
>    the cluster depending on how the table was set up.. right?

You are right. This is usual data manipulation with sql and if XC claims
it is transparent, as long as it is true it should working.

>    I can probably create a temporary table on a single datanode,
>    through a coordinator, just by telling it to distribute that table,
>    and only list the one datanode I want it on, right?  Then I can do

No difference, sure.

>    Hmm, so I wonder what I actually would do if a datanode went down,
>    or if the gtm server went down.  Obviously I wouldn't want to lose
>    all the data in the other nodes.  I wonder how complicated it would
>    be and how long it would take

At this point HA comes to help. But it is not alternative for backup. We
should do usual backup always.

>    to get things back up and running again.  I guess I'd better
>    familiarize myself with the docs on backup and recovery.
>    Are they up to date with pgxc 1.0.1?

Yes, You can see this on top of every page. But name of link pointing to
it is wrong.


***************************
###  Vladimir Stavrinov
###  vst...@gm...
***************************

While catching up with this thread I've been thinking about what the lack
of current HA capability means for my company's project.

The virtual cloud server hosting we use is quite robust, they almost never
have any visible hardware problems, and if they ever were to, I can press a
button and have another server up, of the exact same configuration, in
minutes flat, restored, potentially, to an image created the previous
night.  We can probably have 99% up time without HA, so while HA is
important for us, scalability is definitely the more pressing matter:
 Without HA, we might someday go out of business - without some claim to
scalability, we can't get into business to begin with.

I guess for us the important thing is to be able to recover quickly in the
(hopefully very unlikely) event of a crash, and to be able to restore data
from daily exports if someone accidentally deletes or changes something
important.

So here are my questions -

Can you do log shipping, hot backups, and recover a cluster to a point in
time?  If not what is the quickest/best backup/recovery procedure?
 Whatever it is, it is something I'll need to get scripted and working (I
mean I'll write scripts and test and debug them) for us, at some point
before we go live.

Can you (1) do a full dump, then (2) kill, drop and rebuild the
cluster, and then (3) restore the entire cluster using pg_restore (or psql
.. < dumpfile) through a coordinator?  This would be a last resort,
obviously, since I'd lose all the data on every datanode since the last
full dump, but if I know I can do that, at least I know I have that option.

Sometimes I've found myself doing things with dump files, like pulling
pieces of them into temporary tables and then deleting and/or updating rows
in existing tables based on the data in the dump-loaded temporary tables.
 I'm imagining that these general recovery scenarios are not particularly
complicated by the fact that I'm working with an xc cluster - as long as
I'm going through a coordinator, the effects of the sql statements should
replicate or distribute across the cluster depending on how the table was
set up.. right?

I can probably create a temporary table on a single datanode, through a
coordinator, just by telling it to distribute that table, and only list the
one datanode I want it on, right?  Then I can do a data-only restore, of
just that table, then from there I can use it through a coordinator, and
affect whatever other tables I need to.

Hmm, so I wonder what I actually would do if a datanode went down, or if
the gtm server went down.  Obviously I wouldn't want to lose all the data
in the other nodes.  I wonder how complicated it would be and how long it
would take to get things back up and running again.  I guess I'd better
familiarize myself with the docs on backup and recovery.  Are they up to
date with pgxc 1.0.1?


-rm


On Fri, Oct 26, 2012 at 10:54 AM, David Hofstee <pg...@c0...> wrote:

> **
>
>    1. No cluster without HA option; I agree.
>    2. Integrate XC into PG; In the future I would like to think of a
>    single PG instance as a 1-node cluster-able db.
>
> I think PGXC is the best thing that is happening. PGXC deserves to be the
> most usable in the world too (instead of mysql). Gtx,
>
>
> David
>
> Vladimir Stavrinov schreef op 2012-10-26 14:46:
>
> On Thu, Oct 25, 2012 at 4:13 AM, Michael Paquier
> <mic...@gm...> wrote:
>
> 1) It is not our goal to oblige the users to user an HA solution or
> another,
>
> Sounds fine. Where are those users? Who wants cluster without HA?
> Everybody when hears word "cluster" implies "HA"
>
> Postgres code with XC. One of the reasons explaining that XC is able to
> keep up with Postgres code pace easily is that we avoid to implement
> solutions in core that might impact unnecessarily its interactions with
> Postgres.
>
> You are heroes.  How long You can continue "code pace" on this hard
> way? This paradigm prevents You do not implement not only HA but lot
> of other things that is necessary for cluster. I never saw this type
> of fork. I believe at some point You will either become a part of
> Postgres or  totally come off and go Your own way. The only question
> is when? And best answer is "right now".
>
>
>
>
> ------------------------------------------------------------------------------
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>
>

 

 	* No cluster without HA option; I agree.
 	* Integrate XC into PG;
In the future I would like to think of a single PG instance as a 1-node
cluster-able db.

I think PGXC is the best thing that is happening. PGXC
deserves to be the most usable in the world too (instead of mysql). Gtx,


David 

Vladimir Stavrinov schreef op 2012-10-26 14:46: 

> On Thu,
Oct 25, 2012 at 4:13 AM, Michael Paquier
> <mic...@gm...>
wrote:
> 
>> 1) It is not our goal to oblige the users to user an HA
solution or another,
> 
> Sounds fine. Where are those users? Who wants
cluster without HA?
> Everybody when hears word "cluster" implies "HA"
>

>> Postgres code with XC. One of the reasons explaining that XC is able
to keep up with Postgres code pace easily is that we avoid to implement
solutions in core that might impact unnecessarily its interactions with
Postgres.
> 
> You are heroes. How long You can continue "code pace" on
this hard
> way? This paradigm prevents You do not implement not only HA
but lot
> of other things that is necessary for cluster. I never saw
this type
> of fork. I believe at some point You will either become a
part of
> Postgres or totally come off and go Your own way. The only
question
> is when? And best answer is "right now".

 

On Fri, Oct 26, 2012 at 11:36:24AM -0400, Mason Sharp wrote:

> > It is not the same. What about write? Then You should teach Your
> > application where to read and where to write. What about transparency?
> 
> You can get more write scalability with more data nodes.

How it is related with cite above? It is not about scalability, it is
about transparency. No matter how much nodes for writes we have. But if
You have separate points for read and write, then You loose transparency.

> It took years until PostgreSQL itself had built-in replication. 

I don't blame You don't implement something yet. We have something other
point of controversy here. The discussion in these two close threads is
about what "must have" and what should not. It is about priority and
concept.

> I think most on here also feel strongly about having HA, 

But this discussion shows something else. All my opponents (and I still
saw no one supporter ) here very strongly insists, that HA is not high
priority for XC or should not be implemented in the core. But my
endlessly repeated question "Who wants cluster without HA?" got never
answered in any form. So it is become mystery question.

> it is just not built into the core at present.

"at present" means it will built or possible in the future. Good news.
It is first ray of light in the darkness or the light at the end of the
tunnel. And it is more important that it come from "Architect and
development leader" of XC. Though, it is characteristically, I am not
surprised, something like this I expected. Thanks.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

On Fri, Oct 26, 2012 at 10:59 AM, Vladimir Stavrinov
<vst...@gm...> wrote:
> On Fri, Oct 26, 2012 at 08:03:54PM +0530, Nikhil Sontakke wrote:
>
>>    Using a standby is not an external solution. I wrote that PGXC is
>>    an ongoing project and will surely use them for reads
>
> It is not the same. What about write? Then You should teach Your
> application where to read and where to write. What about transparency?

You can get more write scalability with more data nodes.

The project has made a lot of progress since its inception and for a
long time a lot of the focus needed to be on just making sure the core
database worked. :-)  I suspect read balancing for data node standbys
will happen at some point.

As for HA, I think on this mailing list different ideas were discussed
to achieve HA. Koichi Suzuki just did a presentation this week in
Prague about HA. Someone else mentioned they are using pgbouncer. We
are using Corosync/Pacemaker and have two synchronous replicas per
data node.  It took years until PostgreSQL itself had built-in
replication. Perhaps hooks will be made within XC to help with HA,
perhaps there will be an add-on that can be downloaded, perhaps basic
data node failover from coordinators could be done (but other
components would need failover too). I think most on here also feel
strongly about having HA, it is just not built into the core at
present.


-- 
Mason Sharp

StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Services

On Fri, Oct 26, 2012 at 08:03:54PM +0530, Nikhil Sontakke wrote:

>    Using a standby is not an external solution. I wrote that PGXC is
>    an ongoing project and will surely use them for reads

It is not the same. What about write? Then You should teach Your
application where to read and where to write. What about transparency?

No, standby is crutches, it is surrogate. It is not for cluster, it is
for standalone database. If You have cluster, You don't need standby.
Cluster is best replacement for standby.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

> >    It looks like you like the Mysql Cluster product a lot and are
> >    trying to force fit PGXC within its parameters. So going back to
> >    your favorite Mysql Cluster product. The group has to contain at
>
> Again! I have wrote a lot here about mysql. Please, read before write.
> I don't like mysql, but even enemies may be right. Where this
> intolerant fanaticism from here where I expect intelligent people?
> Especially I like "Go away!". You don't want discussion? Then what are
> You doing here?
>
>
Calm down Vladimir. No one is demonstrating any fanaticism here. I was just
pointing out that the group in a Mysql cluster appears similar to a PG
server and its replica, just that :)


> >    least two nodes for redundancy, right?  Why is that ok and having a
> >    replica not ok or not similar? PGXC can/will certainly provide read
>
> The difference You are pointed out on Yourself in Your next sentences: In
> an cluster all redundant data are under work load, they are available for
> read and write, i.e. they are working. But in any external solutions
> they are sleeping.
>
>
Using a standby is not an external solution. I wrote that PGXC is an
ongoing project and will surely use them for reads in the future. Why is
that difficult to understand?

Anyways, I guess enough on this from my side.

Regards,
Nikhils
-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service

On Fri, Oct 26, 2012 at 05:52:33PM +0530, Nikhil Sontakke wrote:

>    Why is that a problem? The standby can run on nodes which are part
>    of your cluster itself.

It is already answered many times: because it is extra management, extra
recourses and dead weight.

>    HA for datanodes can be provided by using standy nodes as well.

The same as above.

>    It looks like you like the Mysql Cluster product a lot and are
>    trying to force fit PGXC within its parameters. So going back to
>    your favorite Mysql Cluster product. The group has to contain at

Again! I have wrote a lot here about mysql. Please, read before write.
I don't like mysql, but even enemies may be right. Where this
intolerant fanaticism from here where I expect intelligent people?
Especially I like "Go away!". You don't want discussion? Then what are
You doing here?

>    least two nodes for redundancy, right?  Why is that ok and having a
>    replica not ok or not similar? PGXC can/will certainly provide read

The difference You are pointed out on Yourself in Your next sentences: In
an cluster all redundant data are under work load, they are available for
read and write, i.e. they are working. But in any external solutions
they are sleeping.

>    capabilities from replicas in coming versions.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

On 26 October 2012 23:06, Nikhil Sontakke <ni...@st...> wrote:
>
>>
>> But where is war? It is simply question. With low priority You have no
>> neither knowledge nor HA itself. But if every XC accompanied with HA
>> then it is high priority. And question is what is true here?
>>
>
> Vladimir, I guess you are getting the impression that PGXC has de-emphasized
> HA, that's certainly not the case.
>
> For a distributed database, the HA aspects are really important. As you have
> mentioned elsewhere there needs to be a solution in place with something
> like CoroSync/PaceMaker and it's been looked into.
>
> Regards,
> Nikhils
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service
>
> ------------------------------------------------------------------------------
> 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_sfd2d_oct
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>

For those interested I have been playing with something similar (you
could probably see my previous discussion on list).

I have been building a a prototype using external scripting that
allows PG-XC to use the inbuilt streaming replication to HA datanodes.
This has great HA properties but can't currently distribute read
queries to the slaves nicely.
I have been evaluating how to do this but after looking at the GTM etc
I have decided it's beyond my limited knowledge of PG/PG-XC for now.

The basic setup uses pgbouncer infront of PG-XC on a virtual IP so the
path a query takes looks something like this:
virtual-ip -> pgbouncer primary -> coodinators -> virtual-ip -> datanode master.
The virtual IP infront of the datanode pair failsover over
automatically and repmgr then instructs the slave to become writeable.
There is also secondary pgbouncer server that fails over automatically
too, this allows clients to just reconnect on anything bad happening.
This causes a very slight service disruption but overall is pretty
ok... considering for anything to happen a physical server has to
fail.

Ideally I would like to integrate the failover detection and
management into the coordinator cluster along with beign able to
service read queries from my datanode slaves.
However I am quite happy with this setup and am able to scale write
capacity with ease with a fully HA setup. (minus a disconnect on
something bad happening which is OK)

Joseph.


-- 
CTO | Orion Virtualisation Solutions | www.orionvm.com.au
Phone: 1300 56 99 52 | Mobile: 0428 754 846

On Fri, Oct 26, 2012 at 05:36:52PM +0530, Nikhil Sontakke wrote:

>    Vladimir, I guess you are getting the impression that PGXC has
>    de-emphasized HA, that's certainly not the case.

Very interesting! Everybody here try to convince me in that and it is not
expression.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************

On Fri, Oct 26, 2012 at 10:15:45PM +0900, Michael Paquier wrote:

>    And you have the same notion with PG itself, you create 2 database

The only a small difference: PG is not a cluster.

>    servers if you use a slave with a master, so I do not see your
>    point,  and people live and appreciate such a robust solution.. If
>    you are so of using slaves, you could also use archive files for a
>    recovery, or take periodic dumps of each Datanode if you do not
>    want to lose data, then replay it on a new node if necessary.

All these things needs extra resources while cluster itself should have
enough redundancy for fail-over. The difference is that those redundant
data in cluster are under work load, i.e. are working, while all other
external solutions are dead weight.

-- 

***************************
##  Vladimir Stavrinov
##  vst...@gm...
***************************