Re: [Postgres-xc-general] Our general use case

[Vladimir S. <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.