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

[Roger M. <rog...@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
>
>