postgres-xc-general Mailing List for Postgres-XC

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.