After pondering this for awhile, I think the easiest solution would be
to do this:
1. Have it connect to a hardware vip that manages failovers etc to my
2 servers.
2. Have 1 dedicated pool, when the connect occurs on the vip, the vip
will evenly distribute.
3. Set the pool to have idle recycle timeouts
This would probably be the easiest and best way. Sacrifice trying to
set connection limits per host, and just let the connections recycle
thesmelves so that it eventually just 'fixes' itself.
This would work also for when you need to take hosts out of rotation
for maintenance, the VIP will notice this, and then the app servers
will eventually knock the connections off with the recycle.
-Chris
On Nov 4, 3:39 pm, Lenn0x <[EMAIL PROTECTED]> wrote:
> Again that is like a hardware vip (that solution is a bit more
> complex) but the same issue still comes up. If the app connects to a
> mysql load balancer, and it goes down. Now the app can't connect to
> the other mysql servers. A hardware vip works fine but I am curious
> how others might be handling this? Since I don't want extra load on 1
> particular server since I am using persistent connections.
>
> On Nov 4, 2:40 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> > On Nov 4, 2008, at 4:10 PM, Lenn0x wrote:
>
> > > Hi
>
> > > I have 2 sessions created:
>
> > > a_engine = create_engine('mysql:///host1', echo=True)
> > > a_session = scoped_session(sessionmaker(autoflush=True,
> > > transactional=True, bind=a_engine))
>
> > > b_engine = create_engine('mysql:///host2', echo=True)
> > > b_session = scoped_session(sessionmaker(autoflush=True,
> > > transactional=True, bind=b_engine))
>
> > > The issue I run into is, what happens when b_session's server crashes?
> > > I am looking at this from a high availability standpoint. I want to
> > > round-robin between 2 pools of persistent connetions. Both hosts share
> > > the same data. If b_session is down, don't use that session until its
> > > recovered.
>
> > > In my cases using a hardware vip would probably make this easier, but
> > > since we're dealing with persistent connections -- it makes it a tad
> > > more complex. I *could* create 1 pool thats connected directly to a
> > > hardware vip and let that round-robin through the DBs on the initial
> > > 'connect'. But if I start adding more servers that host my application
> > > I could run into a scenario of more connections living on A vs B and
> > > it becomes unpredictable. Managing 2 pools allows me to control X
> > > connections per host and adjust as I add more servers.
>
> > how is your own in-application round robining going to do a better job
> > than an existing load balancing solution , such
> > ashttp://dev.mysql.com/doc/refman/5.0/en/load-balancer.html
> > ?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
