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

[Roger M. <rog...@gm...>]

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...
> ***************************
>
>