Lightning Talk: Amazon RDS offers the ability to modify a production MySQL database with the click of a button. But even if the "modify" button is very tempting, it can easily backfire with unintended consequences. The talk will cover simple scenarios where you should hold your nerve and clicking that button should be the last option you consider.
We improved the connection rate of mysqld for both non-ssl and ssl-connections. We got a 2.5X improvement in improving connection rate non-SSL, and a 1.7X improvement on connection accept rate for SSL connections. We also ended up benchmarking and understanding the different SSL libraries and versions (OpenSSL 1.0, OpenSSL 1.1 and BoringSSL ). This improvement is deployed at scale at Facebook, and uses shared locking pattern to significantly reduce contention in mysqld global datastructures. It also uses advanced kernel features like SO_REUSEPORT to achieve these improvements. Implementing this has helped us handle connection surges in FB mysql tiers, more gracefully.
There are lots of database systems out there, and every year their number grows. Many of them were created with a great idea in mind. Sharding a relational database, implementing git capabilities in a database, designing data and queries around the actor model, building a single software which is both a database and an application server... are just some of these ideas. I will talk about my favourite ones.
ORMs solve some really annoying problems. But do they really simplify things... in all situations? And, if they do, what is the price of hiding complexity from those who work with a database? Let me show you what amazingly stupid things can happen under the hood, and how hard it can be to optimize a common query.
In the last two decades, both researchers and vendors have built advisory tools to assist database administrators (DBAs) in various aspects of system tuning and physical design. But these tools are incomplete because they still require humans to make the final decisions about any changes to the database and are reactionary measures that fix problems after they occur. What is needed is a truly "self-driving" database management system (DBMS) that is able to optimize the system for the current workload and predict future workload trends so that the system can prepare itself accordingly. It enables new optimizations that are not possible today because the complexity of managing these systems has surpassed the abilities of human experts. In this talk, I present Peloton, the first self-driving DBMS that we are building at CMU. Peloton's autonomic capabilities are now possible due to advancements in deep learning, as well as improvements in hardware and adaptive database architectures.
This lighting talk is a technical pitch why you should use OpenPOWER for MySQL/MariaDB/Percona Server or even MongoDB and if you want PostgreSQL. It explains how a fully open source stack can be build from the machine upto the application. It will also say why POWER is a better architecture to run bigger databases.
000webhost handles millions of user queries on close to million unique databases. In this talk we will present the obstacles we encountered on such scale. We will show why we moved away from the traditional webserver->dbserver to a more dynamic architecture using HAProxy, ProxySQL and MariaDB in LXC containers. We will present our model, query routing logic and the outcome from the collaboration with ProxySQL developer Rene.
Few of the problems faced by DBA’s while running alters using pt-online-schema-change are as follows: Creation of Triggers on Slave may get blocked due to a long running select query Rename of old and new table on slave may get blocked due to a long running select query This utility aims to support DBA's with the above problems.