 So good afternoon everybody. I'm here to talk to you about MariaDB 10.1 in particular. I'm obviously not going to talk about all the other features that came since the six years that we've made releases. I've been involved in the MySQL ecosystem for more than a decade, now probably close to 15 years. And before that I used to hack on OpenOffice and Fedora, none of which I am using at this very moment. So one thing that has changed a lot is the global top 20 sites by Alexa, which happens to be a live rating of what sites are being used around the world. For example, you can see it from up here that there are now two Microsoft-based sites that are actually sitting on the top. What's worth noting, if you minus those two sites, that means the top 18 websites that are most frequently visited, tend to be, in some way, shape or form, powered by a MySQL variant. In fact, if you look carefully at number two, which is Facebook, they pioneered something known as web-scale SQL alongside people like LinkedIn and Twitter to actually branch MySQL 5.6 and add a lot of additional features that a web-scale company would require. And all of that features tend to actually get merged back into MariaDB. People like Taobao have contributed tremendously from multi-source replication to instrumentation inside the information schema. Now, I'm guessing most of you probably at least use MySQL. Who here uses MySQL at least? MySQL 5.5 and greater, hopefully. OK. So if you use anything above 5.5, you're probably already familiar with the information schema and Alibaba have contributed tremendously to that. Very happy to say that Google, YouTube, Wikipedia, they're all happily powered by MariaDB server. And one thing on this slide has changed is that Amazon also now offers MariaDB. MariaDB is fully GPL v2 licensed, and for us, we believe communities are key. So we are on GitHub. You can submit patches to us with a BSD, new BSD license. So you never, ever have to sign a contributor agreement. And on February 1st, 2016, we actually celebrated our sixth birthday. So we have been around now for six years, making generally available releases. As for downloads, we do in excess of maybe 250,000 to 300,000 downloads a month from our website alone. And we have an estimated user base of over 8 to 12 million. And being an open source project, it's extremely difficult to keep track of. We are a feature-enhanced version of MySQL. We aim to always be application-compatible. So while we will add new features and we want to add features that MySQL eventually adds, we have to always ensure that your apps don't break, where we make new changes. And we always aim to be application-compatible. And we do this actively by having even more test cases and expanding the test suite. And our aim, obviously, is if you're upgrading today, we are always going to be a drop-in replacement. So an upgrade should be as easy as shutting down your MySQL server, installing MariaDB, and starting it up. We read the same data files. We use the same port. Nothing really is different, except the features that you're given access to and likely the performance. In six years, and a fairly small team of core developers that are paid on a daily basis to do this between the corporation and the foundation, maybe about 25 people in total and within the community people who are paid on a part-time basis to do this, another 20 people, we have made all those releases. We average about one release every month for a GA release and we support each and every GA release for five years. So today, that means we're supporting five, three, five, five, ten, zero and ten, one. So you're guaranteed to always get a release at least once a month. And I checked before giving this talk and we've had over 200 releases of the server and the connector since. Why is this important to you? Vendor independence and freedom from vendor lock-in, we think is extremely important. MySQL today has a single owner. If you go to the bugs database, you will see a lot of references to MySQL 5.8.0. But if you look for the source code for 5.8.0, it's not pushed to GitHub yet because they're not ready to release the code to the public. So MySQL is very much an open source product as opposed to being an open source project. MariaDB very much modeled after the Mozilla Foundation has a foundation and a corporation and everything is open, our roadmaps are open. You can know exactly when we're going to make a release. You can even tell if we're going to slip on a release because upon checkpoints, you will see that we're not fixing all the bugs in time. All that said, MySQL ecosystem is really at its most vibrant ever since Oracle has taken over. Oracle's making things better. Companies like Facebook are making things better. We are making things better. And for you, this is a win because you're getting a better database. I mean, MySQL is 21 years old and just getting better. As a community, you get features that are shipping inside shipping releases. So engines like Spyder would never have had a chance before to be shipped anywhere but now get distribution inside of MariaDB. So I mentioned, beside the server, we also make LGPL client libraries. I think this is pretty important because today, if you ever plan to embed MySQL connector, you're actually affected by what is known as the FOSS exception. So if you are making a commercial application, the FOSS exception doesn't apply and you will have to go and buy a license for your connector from the license holder. We develop LGPL client libraries, which means you can just use them and never have to pay anyone a license fee, not even us. We also like to focus on making enterprise features a lot more open. So we made the thread pool open source. We've made PAM plugins open source and so forth. And our knowledge base is fully open content and fairly well licensed. It's a GFDL and Creative Commons do a license. We also make something else called MaxScale. And this is a router that understands the SQL protocol. It also has a SQL pausa. So you can use it either for logging, you can write to backends. There are plugins that allow you to and people have written plugins that write to a Kafka back end, can write to an Avro back end so you can get that to consume data elsewhere. You can do regular expression filtering. You can use the database firewall module. Also more open source stuff. MariaDB is found pretty much everywhere in every Linux distribution that you happen to be using. In fact, more often than not, it is a default in many Linux distributions that you're using, except WN and Ubuntu where it is a choice. It is available in many of these clouds. Pivotal offers a highly available MySQL, which is really MariaDB Galera cluster. Rax-based cloud, Azure. And very interestingly, Amazon last year also announced that we are available on AWS RDS. So if you happen to want to run this as a service, now you have a choice even on Amazon to either run MySQL, MariaDB, or Postgres, and a few other commercial databases. And if you're looking carefully between MariaDB and MySQL on RDS, you will actually even see something simple. Like if you do show global variables, you will see things like access denied errors, busy times, CPU times. There are a whole bunch more extra variables that do not exist in the MySQL world that do exist inside of MariaDB. 10.1, the release that I'm here to talk to you about, is what we like to refer to as the community release. And I've put here a little roadmap as to give you an idea of how long it actually takes to develop a GA piece of database software, largely because we can't make releases that eat your data, because if it eats your data, you're unlikely to use us or trust us and you'll go and use another database. So it roughly takes 12 to 18 months to actually make database software usable. And in this room earlier, there were a lot of people talking about Google Summer of Code. And I'm really here to say thank you to Google for allowing us to participate in the Summer of Code, because a lot of the features that you see up here, and I've not even included all of them, actually come from Google Summer of Code students. So we do the mentorship and students are actually writing the code. And I'm really happy to say things like the Kerr-Bros authentication plug-in, for example, written by students running in financial institutions. So you're writing code that makes huge impact. So there are a few themes that TenOne is focused around, and I've divided them into security, HA, high performance, operational ease, and things that are just generally better for developers and DBAs. When it comes to security, a lot of this includes things like running better compiler options, not just compiling with GCC, but clang, also making sure that we don't have warnings any longer, but also doing things like running through the address sanitizer, the thread sanitizer. But it also means introducing something like encryption. Now, encryption is something that we thought would be extremely cool to have. We didn't write it, Google wrote it, Google contributed the code to the open source world, and then we integrated it. You can now encrypt at rest either a table or an entire table space, and without a decryption key, you will never be able to get access to the data. Now, in the examples that I will provide, the simple way to do it is to actually have an encryption key sitting on the file system created via OpenSSL. But as you all probably know, that's not a very secure way of doing things. So naturally, you'd have to use a key management server. This is obviously only available for extra DB, inner DB, as well as RAF or temporary tables. So, if you wanted to run encryption and create your keys, you just run a command like that, OpenSSL, and you create keys locally. If you're planning to ever encrypt a table as opposed to the entire table space, so this would be a little less insecure than encrypting the entire table space, you would have additional SQL, which is basically saying page encryption equals one, as well as there's an encryption key available. The entire table space encryption is obviously a lot more secure, and in our worst case benchmark scenarios, we have only seen a three to 5% performance drop when you're running fully encrypted. And that's when we're running things like sysbench and linkbench. When you're running real workloads, this is not even a percent, generally speaking. Now, there are a lot of options to make encryption work. Setting it up properly is very important. Also remembering that if you lose the key, you've lost your data. There's no way to recover it. So we decided that we don't want you to trip on yourselves. So we gave you an encryption preset. So you just have enable encryption.preset in your my.cnf, and it'll actually have turned on all the encryption modules for you. To use external key management, we highly recommend things like ePerry or the Amazon Key Management Service plugins that we include. Sad to say that external key management, there is no open source solution or HSM-based solution out there. Everything tends to be close to also commercial. Now, there are some caveats. For example, MySQL bin log at the moment cannot decrypt an encrypted binary log. This may be a problem for you if you needed to actually go and poke at the binary logs. If you happen to use Galera cluster, it'll also, it's not fully encrypted at the moment and it'll get better over time. Password validation for us is an extremely important thing. The pre-4.1 hashing algorithm was pretty bad, which is why you have a SHA-1 hashing algorithm now. And in fact, SHA-1 has been proven to also be broken so you can have a SHA-256 algorithm today. But to add all of that, we've also given you a simple password check to ensure that passwords fit a minimum set. So maybe you want a eight-character password that is alphanumeric and that can be given to you today. But then if you also happen to run on Linux, which presumably many of you do, you can run this against LibPam's Cracklib. So if someone enters the password A, B, C, D, E, one, two, three, it passes the simple password check, but it will fail the Cracklib password check because it's easy to break A, B, C, D, E, one, two, three. We also ship a SQL error logging plugin. So if you happen to have errors that are sent to the client that you want to trap somewhere, this is a great way for you to actually log into a file that you can then rotate. Obviously your application will encapsulate client errors to say that it has an error connecting to the database server, but you want to know why there was an error as a DBA. The logging plugin totally helps. We also ship an audit plugin, which allows you to log all kinds of server activity, basically any kinds of connects, disconnects, queries, anything that's failed. Anything that is touched is now available in an audit log. And with MariaDB, we give you an extension where you can also filter based on username. So if you want to know what this user did all of yesterday, or ever since they got employed, you can do that now as well. Auditing is not a free thing. Naturally, there will be something in terms of a performance hit when you're auditing. The plugin is obviously open source and free. So it's a performance that you get the hit at. So you may not want to log fully synchronously, but you may want to log asynchronously. So you don't call fsync each and every time when you're doing things in the audit log. For the longest time, we have shipped a PAM authentication plugin. So one of the common use cases that a lot of Postgres people tend to say is we don't have to maintain authentication inside of the server. We can do it externally via PAM. So we've been shipping that as well for a very long time. But I think the cool thing that we started shipping in 10.1 is the Kerberos authentication plugin. Because now you can authenticate against Kerberos if you happen to be like a financial institution, or if you happen to be in a Microsoft environment and need to authenticate against Active Directory, you can do that as well. So your Active Directory domain controller can handle it as well. You don't have to do grants inside of the server any longer. When it comes to HA, you can now totally have complex replication topologies that can do simple failover and slave promotion that does not require you to restart your servers. This is as simple as provisioning a new slave now because of something known as global transaction identifiers. You have GTID positions now. If you happen to upgrade and need to turn it on for some reason, this would be exactly how you do it. And we will just pick up from where the current position happens to be. Failover is a big deal in the MySQL world. If you run MySQL at scale, you will have some kind of failover solution that you are using. You're either using tungsten replicator, you're using MHA, or using your own custom bake solution. Because when the master goes down, you need to find the most current slave to promote it to become the new master and have all the other slaves reading off the new master. With GTIDs, doing this is now literally three commands. There's no longer need for you to differentiate or do a diff on the binary logs anymore and then apply changes like what MHA does. Master failovers are extremely quick now. And then because you're running multiple masters, you may want to eventually aggregate all the data from SID masters either in real time or later for doing backups because you don't want to backup from your master. You can use multi-source replication to get a complete snapshot of what your current database usage happens to be. MySQL only provides asynchronous replication, which is what makes replication extremely fast. Semi-synchronous replication, which is what makes replication actually work at scale. People at Facebook and Google use this at scale naturally so that the master gets a commit and one slave at least gets the same transaction as well before the client gets an OK. But if you happen to ever want fully synchronous replication, which means that all nodes get the same commit or a rollback, then you need to use Galera cluster or another product known as Pocona XDB cluster, another distribution of it. And it turns out that there always used to be a separate download, not anymore. Now if you want to start up a Galera cluster, you can do this with your regular MariaDB, which is integrated Galera cluster. You can start up a three node preset very easily and you can get going even on a laptop if you need to. We also now give you optimistic parallel replication. What that means is not only our SQL threads no longer single threaded, they can make use of multiple cores. You can have multiple parallel workers, one worker per core. If your query pattern will benefit from applying on the slave in a parallel fashion, we will detect it and actually apply it in a parallel fashion as opposed to a sequential pattern. This can give you huge performance boost as well. Naturally, your master also needs to support parallel replication, not just have mixed mode. In the MySQL world today, if you want to take a consistent backup, you will have to run flush tables with read lock. So you're now having a lock and then you will do a dump and then you will provision a new slave, not any longer. In MariaDB for quite some time now, you can do start transaction with the consistent snapshot and then do a MySQL dump, which will just act like one transaction and take a consistent backup of everything before you ran start transaction with consistent snapshot. This is an amazing way to provision new slaves and a great way for you to actually deploy additional nodes in your Galera cluster. We made a whole bunch of other changes to replication, largely contributions that have come out of Google and Facebook. So you know that this is obviously running at scale. We made some high performance changes as well. For one, we're giving you a full-on thread pool. We shipped the thread pool since 5.1, which is LibEvent-based. But now we use native thread pooling libraries. So if you happen to use Linux, it's EpoL. If you use the BSDs, it's cave-ends. If you use Windows, it uses the native thread pooling library. You need to turn on the thread pool. And why is the thread pool useful? Because many web apps or many chat apps and so forth, they make many small queries. And making small queries to MySQL or MariaDB basically involves you to actually start one thread per connection. If you could reuse those threads, you reduce CPU contention. You reduce new text locks. And this is actually really extremely useful for short-running queries, which tend to be most applications today. This is not good if you happen to run lots of business intelligence kind of queries. But for most use cases that MariaDB is used for, turning on the thread pool will actually give you an increased performance boost. As this graph will show you after you start hitting about 256 threads. We make huge amounts of improvements to InnoDB. And we also take the improvements that Oracle makes to InnoDB. And we now allow you to increase the page size of InnoDB, up to 64 kilobytes. It used to be 16 kilobytes. We also allow you to force a primary key. I think this is a very important feature to have, because when you don't force a primary key for InnoDB and you create a table, InnoDB will assign its own primary key internally to six bytes per record. And you can't change this unless you actually change the table. We also allow you to defragment InnoDB, as opposed to having to recreate new tables. So online defragmentation is a useful thing. And we didn't make that. That came straight out of Facebook, and then backported by Dom Kakao, the makers of the KakaoTalk application, if you happen to use that. We took a lot of changes from web scale. One of my favorites that I think even you would benefit from tremendously would be InnoDB idle flush percent, because when your server is relatively idle, you shouldn't be flushing the disk all the time, especially when you're using SSDs and flash. So you don't do unnecessary writes to your flash, expanding the life of your flash devices. All of these features basically came out of the web scale tree, and they've all made it into MariaDB as well. Two days ago in London, I met someone who says he's happily running MariaDB Galera cluster on Power 8. I don't actually know many people that willingly say they run stuff on Power 8 or buy IBM expensive hardware, but maybe you do too. We make improvements to run on Power 8 out of the box, as well as system Z out of the box. So if you happen to need running on these esoteric platforms, this will be good for you. We've noticed if you follow this graph, that's an 80% speedup using Sysbench on Power 8 as well. And we handle memory barriers correctly. So that's 80% over x86. But the costs on Power 8 are tremendous. Perquery variables. I state it's got a long history, which is why I also refer you to a blog post of mine that I wrote, because this started as a Google Summer of Code project back in 2008 when we ran this as part of MySQL, but it never made it into a shipping MySQL until recently. You can now actually set perquery variables on a basis. In this case, I've done set statement, max statement time equals 1000, which means this query will stop after 1000 seconds. And this is also a new feature. Max statement time will allow you to abort long running queries. So if you have bad developers or developers that like to trash your database from time to time, you can always just say here's the max statement time even in your mind on CNF and any query that exceeds the max statement time will be terminated. It's a query timeout. If you happen to be running a web hosting company, the kill syntax is quite useful because you can actually do something like kill user username. You can kill all queries of that user. So if a user is abusing MySQL or if a user has forgotten to pay their bills, you can now kill all their queries instantly. Besides also shutting down the account presumably. We also give you progress reporting. So if you do an alter table, a load data in file, you may now figure out if you should get a cup of coffee or go home for the weekend. This will tell you what the progress is. We've made a huge amount of optimizer enhancements, including making sure that we have all the same features that 5.6 has in terms of the optimizer in where you have the explained format coming out to you in JSON because you'll have other tools that maybe want to read the JSON and then keep it for logging purposes. We also give you additional tools like histograms. We also give you the explained analyze format which is not available inside of MySQL. We have the connect engine. The connect engine is kind of cool. It's like a Swiss army knife of engines. You can read and write XML. You can read and write JSON. You can read and write BSON. Why is reading and writing BSON important? Anybody here use MongoDB? No, wow, I'm surprised. MongoDB has their own binary JSON format. And if you use the connect engine and you think you want to migrate from MongoDB for some reason, you can read BSON. And you can then write back to BSON if need be. The other cool thing that this engine does is it has an ODBC driver. So you can connect to any database that allows you to connect via ODBC. So this means you can connect to Oracle, SQL server, Postgres, whatever, and actually join tables from another database with tables inside of MariaDB. Always connect as the glue. Not for OLTP, but more for business intelligence purposes. We want to give you more instrumentation. So in things like get lock, you now see micro second position everywhere. As I mentioned earlier, SQL standard roles came straight out of a Google Summer of Code student. And now you can also give default roles to people. So you can actually state, some people have the roles of an accountant. The accountants are allowed to read and write to these tables. Some people have the roles of an auditor. They're allowed to only read these tables. And we've also allowed you to now turn off the SQL slow query log on a session basis. So if you happen to know you're going to run a long query, why let this query go into a slow query log? If you have the permissions, you can just turn it off. And we also allow you to change your default temporary storage engine from ARIA to InnoDB if you want. If you want to run full InnoDB, this is totally possible as well. A lot of people love location-based applications today. And we can now fully import the OpenStreetMap database into MariaDB and it can actually run. In fact, that is our test use case as well. It's currently, it's like a 40 gigabyte database or something and you can actually totally do that easily. We've been shipping GIS functionality since MariaDB 5.3, but only with 10.1 are we fully open GIS compliant, which now means we follow the spec and we could probably give post-GIS a run for its money if people were wanting to do that. As I said, 10.1 was a release made of contributions from many, many, many people. Now on this slide include people like ownership that make us a gallery cluster who helped us integrate it into the server. IBM, who did a lot of stuff with us to make Power8 better. Oracle, who's made MySQL better so that we could actually take all those better stuff and give it to you as well. But all of these nice folk as well, including a GSOC student who I'd like to call out because Sri Ram Patil did GSOC with us twice, not just once, but twice. And both times he wrote good code that ships. MySQL 5.7 came out shortly after MariaDB 10.1 and they implemented a lot of the features that we had been shipping maybe even since 10.0, 5.5 and 5.3. Multisource replication was available in 10.0. So we had a good two-year head start there. Dynamic replication filters were shipping in 5.3 so we had a good four-year head start there. Show explain for thread ID. Again, we had a couple-year head start there. They now have GIS functionality as well and they use boost geometry as opposed to regular inside the server itself. And they have that as well and we've had a head start there too. Online GT ID implementation, that was our claim to fame for a very long time. And we are at least two years ahead in that sense. Virtual columns, we shipped in 2011 in 5.2 so many years ahead. But there are still features that the end user can see that ensure that we're still ahead and I presume that there are a lot of these features will appear in MySQL 5.8 which you can assume to see in about two and a half to three years from now. And we will make more features in that timeframe. Those are the ones that I was focusing on earlier as well. Extended regular expressions. If you ever use pull compatible regular expressions and find the need that you'd like to actually have better reg apps, we have a whole bunch more functionality now where you can just stream HTTP data, get HTML and then do reg apps inside of the database server if you ever needed to do that. Participate, because we're an open source project, you can contribute to the server. If you can write C or pull, we're always looking for more contributors. In fact, part of our roadmap is looking at making better stored procedures and we're thinking of external language stored procedures now, which is an active discussion we're having in the last couple of weeks. Should we make stored procedures available in either Lua or JavaScript? And this is something that's easy for all of you to think about and even vote on. You can write knowledge based articles. We have over 4,000 articles in the knowledge base today. You can report bugs. We have a fully public bug system. You can join us on IRC. We're not cool enough to be on Slack, but we are on IRC. You can enable the feedback plugin. Let us know you're using us. Join our mailing lists. They're fairly active. I estimate anywhere between five to 10 posts a day, so not so bad maybe. You can tweet us. We're on Facebook, Google+, and I guess the other really cool thing is that in earnest, we made our first release six years ago, and in six years, there are now nine books. And it seems like there are always more popping up, which means it's kind of impressive because back in the MySQL day, it took us six years to get our first book. So in six years, now we have nine. So in conclusion, MariaDB is fully GPL v2 licensed. We can't re-license the GPL v3 if that's a question you're going to ask because a lot of our call is also still MySQL. We want to guarantee your freedom. So even if MariaDB cooperation happens to be IPO, bot, whatever, the foundation is still going to be there just like the Mozilla Foundation. It's a feature complete with MySQL. We load it with extras. So in a way, it's kind of like a supersize-me version of MySQL. We also make enterprise features open. And I think the other really cool thing about MariaDB is that it's distributed everywhere. You get it standard on most Linux distributions, except Debian and Ubuntu. You get it on the cloud as a choice. You get it on a Mac if you happen to use that on Homebrew. It's really easy for you to get to. And with that, I'd like to say thank you for listening. And do you have any questions for me? Yes, question here first. OK, sure. Oh, the slides will be online as well. OK, question. So are we going to have a portable table space? Actually, MySQL, to be fair, also has portable table spaces if you're running in a DB. So you can actually still burn it onto a CD-ROM or DVD-ROM. And you can actually run it off such media if you need to. And that was introduced back in MySQL 5.6 again. So we have had portable table spaces too. So that's a need of yours. Like, there are many of these apps that allow you to run Wikipedia offline as well. And if you want to run the whole Wikipedia offline, MediaWiki will require you to use MariaDB. And yeah, you can totally run that on a disk as well. So just to be clear, and I don't know if that was not clear, everything I talked about is completely 100% open source. The enterprise release that we have is just you buying support. There is no difference from the version that we ship. So everything that you saw here is 100% open source. Encryption is been open source since we started. And we have no intention of ever making closed source things. Every time we see MySQL make something close source, we make an open source equivalent. So thread pool, PAM plugin, Active Directory plugin. Our aim is to open close things, never to close anything further. If your question is about the Amazon key management plugin, our plugin is open source. But Amazon's key management is not. And it starts at $5,000 for the Cloud HSM device. And it goes up. And you're not paying us. You're paying Amazon. And ePery is the cheapest of the options. But again, you have to pay money. And we will ship the plugins. But we're not charging you for the key management. That's something we don't want to do. And we hope that more people in the open source world make open source key management solutions. There is currently no good open source key management solution that we can hook into. We don't even mind a soft HSM solution. But there are none that we can use today. So that is actually a great project for someone to maybe get started. And this is something not only we face, by the way. If you happen to use MongoDB, I think MongoDB says in the enterprise version they have encryption available. But that's largely also because they want to sell you a key server of their own. And most people who want to give you at rest encryption have a key server to sell you. We don't have a key server to sell you. Maybe we should at some stage. But we don't. We just integrate with third party solutions, let someone else sell it to you. But the plugins are open. OK, last question. Oh, yeah, slideshare.dat. OK, that was not a question. But thank you anyway. One more, very quickly. Yes. Yes. And if you have a problem, like recently we saw these CloudStack users say they have a problem with the optimizer. And they reported a bug. And it was fixed fairly quickly. So yes, there should be no problem. In fact, if you use a Linux distribution, more often than not the older ones, you can just do an app get upgrade. But the newer ones, like if you use Fedora, CentOS, 7, and so on, they're all just shipping MariaDB as a default. So your application has most likely been running MariaDB if you have upgraded Linux without you even really realizing that it's there. So it should not break anything. And if it does, you should file a bug. And we keep on extending our test cases to make sure we test against the latest MySQLs. MySQL test cases are not as varied as ours. I think they have their own internal test suite now. But ours are all completely public, and we should break nothing. OK, thank you.