The world of open source databases is rapidly evolving. It seems like every day brings a new release of an open source technology that might make a database administrator's life easier, if only he or she knew about it.
Fortunately, there are many ways to stay on top of what's going on with open source database technology. One such way is the Percona Live Open Source Database Conference, taking place next week in Dublin, Ireland. We've covered Percona Live before, and invite you to take a look back at some of our previous stories. From IoT to big data to working with the cloud, there's plenty to keep up with. Here are a look at a couple of the sessions you might enjoy, as described by the speakers.
NoSQL best practices for PostgreSQL
My talk is NoSQL Best Practices for PostgreSQL. One of PostgreSQL's most attractive features is the Jsonb data type. It allows efficient work with semi-structured data without sacrificing strong consistency and ability to use all the power of proven relational technology.
The great thing is that you don't need any special supernatural powers to get it to work efficiently with semi-structured data. Jsonb is already effective enough right out of the box. But as always there are some limitations, implementation details, and tricks.
PostgreSQL has an awesome community that is ready to tackle any issue. There are a lot of people that are excited about databases and possess valuable expertise in this area. My most vivid memory so far about the community was someone asking a question in the hackers mailing list that got answered within minutes, even before I started to type my own reply. I grew extremely interested in databases not so long ago, mostly due to the influence of Oleg Bartunov, who is a longtime contributor to PostgreSQL. Initially, I just implemented one patch for the Jsonb data type that was eventually included in the core. After that I couldn't stop. So I still try to help the PostgreSQL community as much as I can.
The biggest idea behind this talk is to show that we live in interesting times. It's not that easy to stick with only one data model/data storage. And to mitigate this issue, most modern databases are trying to provide more that one approach. We have to evaluate them each carefully.
Don’t attend if you expect a holy war of PostgreSQL vs. MongoDB vs. MySQL vs. whatever else. You won't see anything like that, because we're all grown-ups.
Orchestrating ProxySQL with Orchestrator and Consul
I'll be discussing how to orchestrate ProxySQL with Orchestrator and Consul. The combination of ProxySQL and Orchestrator solves many problems, but still requires some manual labor when the configuration changes when there is a network split (and other scenarios).
ProxySQL is supposed to help you out with high availability (HA) and disaster recovery (DR) for MySQL servers, but it still requires some manual labor when the configuration change, as a result of a network split, for example. Somehow all ProxySQL servers need to get the new MySQL cluster topology. So to automate all that, I added two more parts: a Consul KV store and a Consul template, which are responsible for updating ProxySQL on every architecture change in the MySQL cluster.
As a DevOps practitioner, I prefer not to do anything manually. What’s more, no one wants to wake up in the middle of the night because one of their database servers fails. Most everyone will have more than one ProxySQL server in their system at some point, so this solution can help them use ProxySQL and Orchestrator.
In this talk I will discuss the standard architecture, the solutions it provides, and what it's missing. I will then share an automation solution developed at Wix that solves those problems using Consul to combine everything together. If as a result of my talk someone will earn even one minute of downtime, I’ll be happy.
To see any of these talks in person, register for the Percona Live Europe Open Source Database Conference 2017, and use the code SeeMeSpeakPLE17 to get 10% off your registration.