Analyzing tricky database problems

Set Theory

Conclusions

The lesson learned after troubleshooting is that database performance problems can sometimes be serious and can be caused by very simple errors in the infrastructure. The tools used play a key role in troubleshooting.

Additionally, you should remember that a MySQL proxy like MaxScale does not always execute a query the way it's intended. With database proxies, which serve as a mediating instance between database and client, it helps to think like the proxy you are using (i.e., MaxScale here) and to follow its logic, because it is also true that queries that cause the problem do not always appear in the slow query log. They might not even be in the slow lane; instead, small inefficiencies can add up to great delays.

Infos

Switch: https://www.switch.ch
MariaDB: https://mariadb.org
Galera Cluster: http://galeracluster.com
Redis: https://redis.io
Graphite: https://graphiteapp.org
Elasticsearch: https://www.elastic.co/de
Logstash: https://www.elastic.co/products/logstash
Kibana: https://www.elastic.co/products/kibana
Docker: https://www.docker.com
OpenStack: https://www.openstack.org
Performance Schema overview: https://mariadb.com/kb/en/library/performance-schema-overview
"MySQL Performance Schema Statement Digests" by Mark Leith: http://www.markleith.co.uk/2012/07/04/mysql-performance-schema-statement-digests

The Author

Greg Vernon has been involved with databases since he started working with Oracle DBs at Boeing in the late 1990s. He has also worked with MySQL and PostgreSQL. Since his move to Switzerland, he has been working as a system engineer at Switch, where he is mainly involved with the Switch Drive service, the foundation's ownCloud-based file-sharing system.

« Previous 1 2