Open Stack

Hi Matt,

Welcome to the list.
I shall try and do a brain dump, but it may end up throw more questions at you.

DB Migrations.
----------------------
Openstack is a very fast evolving project, which is great. However that means there are quite a lot of db migrations which add and remove  columns to existing tables and perform similar operations with indexes etc.

If you have a production environment that is heavily used like ours, you are looking at having millions of rows in each of these tables.

As a developer writing code and testing, these migrations work perfectly well.
Typical tests are performed with test databases containing only test data which never comes up to millions or records.
Further more there is no production load on the test database actively trying to write stuff when you are altering the tables.

Database abstraction with SQLAlchemy is great, but it generally mean your schema alterations end up having the standard ALTER TABLE syntax.

I have personally used Percona's pt-online-schema-change.html to get me out of some of these sticky situations.
http://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html
BTW, Thank you very much for the above tool.

There is a risk in using such approaches as you want to make sure that you are not deviating even in the slightest of manner from what would have been achieved using the standard alter table. There is some work being done to introduce archiving of data etc, which will help keep data growth in checks. Also using an online schema change becomes tricky when you have foreign key constraints on tables or if you have setup triggers for your table. (thankfully no triggers yet).

---------------------------------------------

High Availability is also something that that I think could so with some attention.
http://docs.openstack.org/trunk/openstack-ha/content/ch-intro.html
The above page does detail the current recommended approach for setting up highly available mysql database servers.
The current approach is great if you are using dedicated hardware and have separate physical switches etc.
It does work reasonably well in a virtualised environment too, but one needs to take into account several other factors.

With mysql 5.6 support global transaction ID, (GTID) and improvements in galera and PXC(percona xtradb cluster)
I think there is definitely room to review the current recommended solutions

----------------------------------

I guess that is enough of me rambling.

--
Regards
Sushil Suresh.


From: Matt Griffin <matt.griffin at percona.com<mailto:matt.griffin at percona.com>>
Subject: [Openstack-operators] operator challenges with MySQL
Date: July 6, 2013 2:05:47 PM CDT
To: <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>>

Quick introduction... I'm Matt Griffin, Percona's Director of Product Management, and I'm new to this list.

As I understand it, OpenStack operators have a few options when it comes to DBs - MySQL, PostgreSQL, and SQLite. I'd like to learn more about challenges and problems OpenStack operators face with MySQL. I've done a bit of searching on ask.openstack.org<http://ask.openstack.org/>, but I thought I'd ask this audience as well.

Best,
Matt Griffin
Director of Product Management
Percona
matt.griffin at percona.com<mailto:matt.griffin at percona.com>


Percona Live London MySQL Conference 2013
http://www.percona.com/live/london-2013/




Sushil Suresh
Linux Systems Engineer  [experience Fanatical Support]

Tel:    +442087344778
Mob:    +447720948522
Fax:    +44 208 734 6111
Web:    www.rackspace.co.uk<http://www.rackspace.co.uk>
        [Rackspace]




_______________________________________________

OpenStack-operators mailing list

OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Balz-Zimmerman Strasse 7, 8302 Kloten, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy
-
Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Suite 3, Level 7, 210 George Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php
-
Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States of America
Rackspace US, Inc privacy policy can be viewed at www.rackspace.com/information/legal/privacystatement
-
Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ.
Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy
-
Rackspace Benelux B.V. is a company registered in the Netherlands (company KvK nummer 34276327) whose registered office is at Teleportboulevard 110, 1043 EJ Amsterdam.
Rackspace Benelux B.V privacy policy can be viewed at www.rackspace.nl/juridisch/privacy-policy
-
Rackspace Asia Limited is a company registered in Hong Kong (Company no: 1211294) whose registered office is at 9/F, Cambridge House, Taikoo Place, 979 King's Road, Quarry Bay, Hong Kong.
Rackspace Asia Limited privacy policy can be viewed at www.rackspace.com.hk/company/legal-privacy-statement.php
-
This e-mail message (including any attachments or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com and delete the original message. Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130708/4b7d4313/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image391c11.JPG
Type: image/jpeg
Size: 3124 bytes
Desc: image391c11.JPG
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130708/4b7d4313/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image6a4c84.JPG
Type: image/jpeg
Size: 990 bytes
Desc: image6a4c84.JPG
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130708/4b7d4313/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image29eef4.JPG
Type: image/jpeg
Size: 6844 bytes
Desc: image29eef4.JPG
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130708/4b7d4313/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image8887cf.JPG
Type: image/jpeg
Size: 1074 bytes
Desc: image8887cf.JPG
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130708/4b7d4313/attachment-0003.jpe>