MySQl in the cloud, As A Service
There is no one magic solution to having MySQL As A Service work well, it’s a lot of small moving parts and options that need to be set, monitored and configured. We may wish it was different, or look at other database technologies, but there is a lot of legacy code that talks to MySQL, with all it’s idiosyncrasies – and we need to be able to support this code.
In this talk, we’ll cover many of the problem areas and what you can do to avoid them. We’ll cover stock Oracle MySQL, Percona Server and MariaDB. Where suited, Drizzle will also be discussed.
A key focus area will be how to run MySQL As A Service. This makes sense even in smaller organisations, providing database services to various apps, not just in big cloud providers.
Some areas we’ll examine:
- IOPs. IOPS are eaten by database sytems for breakfast, MySQL is no exception. We’ll look at a crash safe server with replication, how many fsync()s a single transaction causes (hint: greater than 1) and how that number can be reduced.
- ENOSPC. MySQL traditionally handles ENOSPC very, very poorly. We’ll look at new features we’ve implemented to help avoid ENOSPC. This includes replication logs, UNDO logs and temporary files.
- Flexibility in users/admin. We’ll also cover ways to provide users with the root MySQL user while not giving them access to the underlying Virtual Machine – enabling a more standardized Database As A Service platform yet giving users a lot of flexibility in how they use their database.
- Backup/restore/spawning slaves. Backup and restore is also integral to a good database server, so we’ll examine backup options that work for streaming directly into cloud storage rather than local disk.
The Agony and Ecstasy of Continuous Integration
This a tale of the introduction of continuous integration testing into a well established development team. It covers both the highs and lows and discusses strategies to deal with both the positives and negatives and in turn improve your own software engineering practices.
While setting up a Jenkins instance off in the corner somewhere is relatively simple, changing the organisation and development practices can be much harder while at the same time throwing adequate resources at CI when your budget is nowhere near infinite.
While projects such as OpenStack get a lot of coverage for their continuous integration work, they also have a non-trivial number of people exclusively working on it. In this sesison, I’ll cover how to do something really close with approximately zeno spare hours in your day and near zero spare dollars in your budget.
We’ll talk Jenkins, parameterized builds, gated trunk, code review, development processes, automatic deployment, release checklists and a 3.7GB java process.
Stewart Smith is the Director of Software Architecture at Percona. He joined Percona in 2011 with a deep background in database internals including MySQL, MySQL Cluster, Drizzle, InnoDB and HailDB.
Prior to joining Percona, Stewart worked at Rackspace on the Drizzle database server focusing on getting it through a critical milestone of a stable Generally Available (GA) release. Prior to Rackspace, he worked on Drizzle as a member of the CTO Labs group inside Sun Microsystems.
As one of the founding core developers of the Drizzle database server Stewart has deep expertise in the code base. He had direct involvement in significant refactoring of the database server including removing the FRM, the InnoDB storage engine, xtrabackup, the storage engine API, CATALOG support and countless bug fixes. He also maintains HailDB, a shared library offering a NoSQL C API directly to InnoDB.
At Sun Microsystems, and MySQL before that, Stewart was a Senior Software Engineer in the MySQL Cluster team working on core code and features inside the MySQL Server and the Cluster codebase working on projects such as: geographical asynchronous replication, online add node, online backup, NDBINFO for improved monitoring and the Win32 port.