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

[Paulo P. <pj...@ub...>]

Hi,

Summing, I've found Postgres-XC to be quite easy to install and
configure in a 3 coordinators + 3 data-nodes (GTM all over them and
GTM-Proxy handling HA). A little Google and command-line did the trick
in *a couple hours*!

Now, the only downside for me is that Postgres-XC doesn't have a
built-in way of load-balancing between coordinators. If the coordinator
your app is pointing to goes down, your app goes down - your application
can target all of them, but in my experience, your application will
*always* target a host. So, ATM my solution is:
  1) Define a DNS FQDN like coordinator.mydomain pointing to an IP
(i.e., 10.0.0.1)
  2) Point my app to work with that FQDN
  3) On every coordinator, configure keepalived with one shared-IP
(10.0.0.1)
  4) Install haproxy in every coordinator and have it load-balance with
the other coordinators

This way, keep-alived will always choose the first coordinator (based on
its priority) and then haproxy (running on that machine) will
load-balance with others. If this coordinator goes down, the second host
in keepalived priority list will replace it and not only is it a valid
coordinator, but also it will be able to load-balance with other
coordinators.

My only doubt is, if you get a data-node offline and then bring it up,
will the data in that data-node be synchronized?

And that's it. I'm in now way a DB-expert and I felt quite confused by
reading the previous thread. But as a developer, Postgres-XC has been a
huge upgrade for me. (Now, if only RETURN ID was to be implemented, mr.
Abbas ;-)).

Sorry for being a little off-topic, but wanted to share my _little_
experience with this wonderful piece of software.

Cheers,
PP

On 10/24/12 9:41 PM, David Hofstee wrote:
> Hi,
> 
> I've been reading the '*ERROR: Failed to get pooled connections*' thread
> about what XC should and should not do. I opted to start a new thread
> (instead of replying) about how I would like XC to be.
> 
> Some background. I work for a SaaS company (mostly dev, some ops) which
> has to be online 24/7. We are now running apache/tomcat/mysql for each
> set of customers on about 30 nodes and we want to centralize and make
> our application more robust, efficient and simple. It basically means
> creating layers: LB, webservers, application servers, database cluster.
> Some easy parts are already done (haproxy, nginx). Our 'platform' is
> pretty complex and I have so many tasks, I prefer to /not/ dig into
> details. We are now discussing the db issue (mysql cluster is not that
> great).
> 
> My dream DB cluster:
> 
> Scalability - that means read and write scalability. XC should do that
> right now. Nice.
> 
> High availability - a node can go offline and it should not hinder
> availability (only processing capacity)
> 
> Maintainability - Since maintenance/change is our primary cause of
> downtime, it should be possible to kill a node and add it later. This
> can be because the VM is being moved, the OS is updated/upgraded, etc.
> Also, think about how a cluster is updated from major version to major
> version (lets say 9.x to 10.x). Maybe that is not an issue (but I don't
> know about it yet).
> 
> Simplicity - It would be nice if the default package+config file is all
> I need. If it is too complex I cannot go on holidays. Some points:
> 
>   * I read that /'...even the stock postgresql.conf configuration file
>     is pretty conservative and users tweak it as per their
>     requirements.../'. For me that translates as 'if you are new to
>     Postgres it works bad'. Not simple (for e.g. some of our dev-ers).
>   * For HA/'...Like Postgres, you need an external application to
>     provide it'/. When using a cluster I think HA is very often wanted.
>     I need to explain all this to every ops-colleague of mine and some
>     are not very accurate. Not simple again.
> 
> Quick setup - I want to setup an NxM cluster quickly (N times
> duplication for HA, M times distributed writes for performance). I
> prefer to setup a single node with a given config file, add nodes and be
> ready to go. Maybe an hour in case of disaster recovery?
> 
> Managability - I want to manage a cluster easily (add node, remove node,
> spare nodes, monitoring, ...). It cannot be simple enough.
> 
> Backup - I'm not familiar with running backups on Postgres but we
> currently run a blocking backup on the mysql, for consistency, and it
> causes issues. We use Bacula on a file level. Which brings up a
> question: How do you backup a cluster (if you don't know which nodes are
> hot)?
> 
> Logging - Yes...
> 
>  
> 
> Some may respond that things are not that simple. I know. But I still
> want it to be simple. It would make PGXC a no-brainer for everyone.
> Thanks for listening and keep up the good work! I appreciate it.
> 
>  
> 
> David H.
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> 
> 
> 
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
> 

-- 
Paulo Pires
Ubiwhere