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

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