Open Stack

Hello,

New questions below

---
Best regards
Sławek Kapłoński
slawek at kaplonski.pl

Dnia czwartek, 18 września 2014 09:45:21 Clint Byrum pisze:
> Excerpts from Sławek Kapłoński's message of 2014-09-18 09:29:27 -0700:
> > Hello,
> > 
> > Is anyone here using openstack with mysql galera and haproxy? Have You got
> > any problems with that?
> > I was today installed such ha infra for database (two mysql servers in
> > galera cluster and haproxy on controller and neutron node, this haproxy
> > is connecting to one of galera servers with round robin algorithm).
> > Generally all is working fine but I have few problems:
> > 1. I have a lot of messages like:
> > WARNING neutron.openstack.common.db.sqlalchemy.session [-] Got mysql
> > server
> > has gone away: (2006, 'MySQL server has gone away')
> > 2. I have (most on neutron) many errors like:
> > OperationalError: (OperationalError) (2013, 'Lost connection to MySQL
> > server during query') 'UPDATE ml2_port_bindings SET vif_type=%s,
> > driver=%s, segment=%s WHERE ml2_port_bindings.port_id =
> 
> 1 and 2 look like timeout issues. Check haproxy's timeouts. They need
> to be just a little longer than MySQL's connection timeouts.

After I made ACTIVE/PASSIVE cluster and change sql_idle_timeout in neutron and 
nova problem 1 looks that is solver. Unfortunatelly I found that when I'm 
deleting port from neutron I still sometimes have got errors like in 2. I 
don't check exactly nova logs yet so I'm not sure is it only in neutron or in 
both. 
Do You maybe know why it happens in neutron? It not happend when I have single 
mysql node without haproxy and galera so I suppose that haproxy or galera is 
responsible for that problem :/

> 
> > 3. Also errors:
> > StaleDataError: UPDATE statement on table 'ports' expected to update 1
> > row(s); 0 were matched.
> > 4. and errors:
> > DBDeadlock: (OperationalError) (1213, 'Deadlock found when trying to get
> > lock; try restarting transaction') 'UPDATE ipavailabilityranges SET
> > first_ip=%s WHERE ipavailabilityranges.allocation_pool_id =
> 
> 3 and 4 are a known issue. Our code doesn't always retry transactions,
> which is required to use Galera ACTIVE/ACTIVE. Basically, that doesn't
> work.
> 
> You can use ACTIVE/PASSIVE, and even do vertical partitioning where
> one of the servers is ACTIVE for Nova, but another one is ACTIVE for
> Neutron. But AFAIK, ACTIVE/ACTIVE isn't being tested and the work hasn't
> been done to make the concurrent transactions work properly.
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140920/bbf69c0d/attachment.pgp>