The Severalnines team is pleased to announce the release of ClusterControl 1.3.

This release contains key new features, such as Key Management for MySQL, MariaDB, Percona Server and PostgreSQL, improved security, additional Operational Reports, along with performance improvements and bug fixes.

Join us next week on Tuesday, May 24th, for a live demo!

Sign up for the webinar

Highlights

• New for MySQL, MariaDB, Percona Server & PostgreSQL
  • Key Management
  • Additional Operational Reports
  • Improved Security
  • Create/Mirror Repository
• New for MySQL
  • Deploy Production Setup of NDB/MySQL Cluster
• New for MongoDB
  • Deploy Percona for MongoDB ReplicaSet Node

For additional details about the release:

• 1.3 ChangeLog
• Installation Instructions for new Users
• ClusterControl Administration Guide
• Upgrade instructions

Key Management: This new feature allows you to manage a set of SSL certificates and keys that can be provisioned on your clusters. Users can now create certificate authority certificates or self-signed certificates and keys, as well as easily enable and disable SSL encrypted client-server connections for MySQL and Postgres based clusters.

Additional Operational Reports for MySQL, MariaDB, Percona, MongoDB & PostgreSQL: In addition to the Operational Reports introduced in 1.2.12, users can now generate an Availability Summary of uptime/downtime for their managed clusters and see node availability and cluster state history during the reported period. It is also possible to generate a backup summary of backup success/failure rates for your managed clusters.

Improved security: We are now enforcing a unique Controller RPC API Token, which enables token authentication for your managed clusters. No user intervention is needed when upgrading older ClusterControl versions. An unique token will be automatically generated, set and enabled for existing clusters. See the ChangeLog for more details.

Create/Mirror Repository: Mirror your database vendor’s software repository without having to actually deploy a cluster. A mirrored local repository is used in scenarios where you cannot upgrade a cluster and must lock the db versions to use.

Deploy Production Setup of NDB/MySQL Cluster: Users can now create a production setup of NDB/MySQL Cluster from ClusterControl and deploy management, SQL/API and data nodes.

Deploy MongoDB ReplicaSet Node: Support for Percona MongoDB 3.x. Please also note that as of this version of ClusterControl, MongoDb 2.x is no longer supported.

There is a bunch of other features and improvements that we have not mentioned here. You can find all details in the ChangeLog.

We encourage you to test this latest release and provide us with your feedback. If you’d like a demo, feel free to request one.

With over 8,000 users to date, ClusterControl is the leading, platform independent automation and management solution for MySQL, MariaDB, Percona, MongoDB and PostgreSQL.

Thank you for your ongoing support, and happy clustering!

For additional tips & tricks, follow our blog: http://www.severalnines.com/blog/

We’ve just announced the latest version of our flagship product, ClusterControl, this week and as our product grows, so does our team.

As a result, we’re now looking for a QA automation wizard, someone who’ll help us take our product development to where we want it to be: short, well-tested release cycles.

This role involves extensive programming, test execution, reporting, and setting technical direction for testing Severalnines software.

And it involves being part of a great (if we say so), distributed team of highly skilled and motivated colleagues building the next generation database cluster management applications.

These are some of the technologies that we currently use and that you’d be involved with:

• JavaScript, PHP, C++, Python, HTML, CSS, NodeJS, Grunt, NPM, CMake, Jenkins, Git
• CakePHP, jQuery, ExtJS4, Highcharts, AWS SDK
• Bootstrap and custom css
• PHP based REST API (db) and RPC based API (backend process)
• Classic LAMP stack

View the full job description here.

To apply, please email jobs@severalnines.com with your CV and links to your Github and/or LinkedIn profiles.

We look forward to hearing from you!

Welcome to this week’s Planets9s, covering all the latest resources and technologies we create around automation and management of open source database infrastructures.

	Download the new ClusterControl 1.3 for MySQL, MongoDB & PostgreSQL This week we were excited to announce the release of ClusterControl 1.3. This release contains key new features, such as Key Management for MySQL, MariaDB, Percona Server and PostgreSQL, improved security, additional Operational Reports, along with performance improvements and bug fixes. Do check it out if you haven’t downloaded it yet, and let us know your feedback. Download the new ClusterControl
Sign up for the ClusterControl 1.3 new features webinar Join us for our webinar next Tuesday, May 24th, on ClusterControl 1.3, the one-stop console for your entire database infrastructure. We’ll be introducing the new features of this release as well as demonstrating them during a live demo. Sign up for the webinar
	Learn the difference between Multi-Master and Multi-Source replication This new blog post discusses the lesser known Multi-Master and Multi-Source replication topologies. Even though they sound similar they are actually quite different. Here we illustrate their differences and provide insight into when to apply and how to best configure them. Read the blog

That’s it for this week! Feel free to share these resources with your colleagues and follow us in our social media channels.

Have a good end of the week,

Jean-Jérôme Schmidt
Planets9s Editor
Severalnines AB

The majority of DBA’s perform health checks every now and then. Usually, it would happen on a daily or weekly basis. We previously discussed why such checks are important and what they should include.

To make sure your systems are in a good shape, you’d need to go through quite a lot of information - host statistics, MySQL statistics, state of backups, logs and so forth. Such data should be available in every properly monitored environment, although sometimes it is scattered across multiple locations - you may have one tool to monitor MySQL state, another tool to collect system statistics, maybe a set of scripts, e.g., to check the state of your backups. This makes health checks much more time-consuming than they should be - the DBA has to put together the different pieces to understand the state of the system.

Integrated tools like ClusterControl have an advantage that all of the bits are located in the same place (or in the same application). It still does not mean they are located next to each other - they may be located in different sections of the UI and a DBA may have to spend some time clicking through the UI to reach all the interesting data. This is why we introduced operational reports in ClusterControl 1.3 - which you can discover live next Tuesday during our release webinar.

The whole idea behind creating Operational Reports is to put all of the most important data into a single document, which can be quickly reviewed to get an understanding of the state of the databases.

See the Operational Reports live in action during our release webinar

Operational Reports are available from the menu Settings -> Operational Reports.

Once you go there, you’ll be presented with a list of reports created manually or automatically, based on a pre-defined schedule.

If you want to create a new report manually, you’ll use the ‘Create’ option. Pick the cluster, type of report, email recipients, and you’re pretty much done.

The reports can also be scheduled to be created on a regular basis.

At this time, three types of  reports are available  and we’ll show examples of these below.

Availability report

Availability reports focuses on, well, availability. It includes three sections. First, availability summary.

You can see information about availability statistics of your databases, the cluster type, total uptime and downtime, current state of the cluster and when that state last changed.

Another section gives more details on availability.

We can see when a node switched state and what the transition was. It’s a nice place to check if there were any recent problems with the cluster.

Similar data is shown in the third section of this report, where you can go through the history of changes in cluster state.

Backup report

The second type of the report is one covering backups.

It contains two sections and basically gives you a short summary of when the last backup was created, if it completed successfully or failed? You can also check the list of backups executed on the cluster with their state, type and size. This is as close you can get to be certain that backups work correctly without running a full recovery test. We definitely recommend that such tests are performed every now and then.

Default cluster report

This type of report contains detailed information about a particular cluster. It starts with a summary of different alerts which are related to the cluster.

Next section is about the state of the nodes that are part of the cluster.

You have a list of the nodes in the cluster, their type, role (master or slave), status of the node, uptime and the OS.

Another section of the report is the backup summary, same as we discussed above. Next one presents a summary of top queries in the cluster.

Finally, we see a “Node status overview” in which you’ll be presented with graphs related to OS and MySQL metrics for each node.

As you can see, we have here graphs covering all of the aspects of the load on the host - CPU, memory, network, disk, CPU load and disk free. This is enough to get an idea whether anything weird happened recently or not. You can also see some details about MySQL workload - how many queries were executed, which type of query, how the data was accessed (via which handler)? This, on the other hand, should be enough to pick most of the issues on MySQL side. What you want to look at are all spikes and dips that you haven’t seen in the past. Maybe a new query has been added to the mix and, as a result, handler_read_rnd_next skyrocketed? Maybe there was an increase of CPU load and a high number of connections might point to increased load on MySQL, but also to some kind of contention. An unexpected pattern might be good to investigate, so you know what is going on.

See the Operational Reports live in action during our release webinar

This is the first release of this feature, we’ll be working on it to make it more flexible and even more useful. We’d love to hear your feedback on what you’d like to have included in the report, what’s missing and what is not needed.

We’ve been gearing up for this in the past months and we’re delighted to announce the first dates of our European Polyglot Persistence Meetups this summer. We’re starting off with Amsterdam, then moving on to Dublin, Paris, Berlin, Stockholm and London.

Sign up for a Polyglot Persistence Meetup

Some of you may ask what Polyglot Persistence is all about …

Polyglot Persistence means that when storing data, it is best to use multiple data storage technologies, chosen based upon the way data is being used by the application. In a world where developers reign, these developers would choose the optimal programming language for the job - and this trickles down to the data tier. The former is often referred to as polyglot languages and the latter as polyglot persistence. However, this freedom comes at a cost - more complexity.

In our world of 9s, we like to look at the database aspects of DevOps and this is also where we’re focussing with this new meetups series.

Initially, the idea is to cover MySQL, PostgreSQL and MongoDB storage backends with the topics of deployment, scaling, configuration, management, backups and monitoring. And with time and as members suggest topics, the scope is likely to broaden.

Sign up for a Polyglot Persistence Meetup

Our meetups schedule so far:

• 06 June - Amsterdam
• 08 June - Dublin
• 16 June - Paris
• 17 June - Berlin
• Stockholm tbc
• London tbc

Please sign up for the meetup of your choice, as we’re announcing locations, speakers etc. via the Meetup platform.

For our kick-off in Amsterdam, we’re lucky to be sponsored by booking.com and we’ll be hosting the meetup in their offices.

We look forward to seeing you there and to the polyglot discussions ahead!

Thanks to everyone who joined us yesterday for our ClusterControl 1.3 release webinar!

Johan Andersson, CTO at Severalnines and creator of ClusterControl, walked us through the latest features of the 1.3 release and demonstrated them live as well. In addition to an overview of ClusterControl’s deployment, monitoring, management and scaling functionalities for MySQL, MariaDB, Percona Server, MongoDB and PostgreSQL, Johan focussed our attention on new features around key management, operational reports and more.

One feature-set that triggered particular interest in yesterday’s audience was the automated deployment of a production setup of NDB / MySQL Cluster: users can create a production setup of NDB/MySQL Cluster from ClusterControl and deploy management, SQL/API and data nodes - all via the ClusterControl interface.

The replay of this webinar and the slides are now available for viewing online:

Sign up for the the replayRead the slides

To get started with ClusterControl, download it today.

Webinar Agenda

• ClusterControl overview
• New features deep-dive
  • Key management and encryption
  • Additional operational reports
  • Improved security
  • Create / mirror repository
  • Create NDB / MySQL Cluster
• Live Demo
• Q&A

Speaker

Johan Andersson, CTO, Severalnines - Johan's technical background and interest are in high performance computing as demonstrated by the work he did on main-memory clustered databases at Ericsson as well as his research on parallel Java Virtual Machines at Trinity College Dublin in Ireland. Prior to co-founding Severalnines, Johan was Principal Consultant and lead of the MySQL Clustering & High Availability consulting group at MySQL / Sun Microsystems / Oracle, where he designed and implemented large-scale MySQL systems for key customers. Johan is a regular speaker at MySQL User Conferences as well as other high profile community gatherings with popular talks and tutorials around architecting and tuning MySQL Clusters.

For more information on ClusterControl 1.3:

• Release blog
• ChangeLog
• Documentation

To get started with ClusterControl, download it today.

Welcome to this week’s Planets9s, covering all the latest resources and technologies we create around automation and management of open source database infrastructures.

	Watch the replay: ClusterControl 1.3 webinar with new features for MySQL, MariaDB, Percona Server and PostgreSQL Thanks to everyone who joined our ClusterControl 1.3 release webinar this week. If you weren’t able to attend or would simply like to watch it again, the replay is now available online. Johan Andersson, CTO at Severalnines, gave an overview of ClusterControl’s deployment, monitoring, management and scaling functionalities for MySQL, MariaDB, Percona Server, MongoDB and PostgreSQL, as well as the new features around key management, operational reports and the new deployment tool for MySQL NDB Cluster … and more! Watch the webinar replay
Sign up for our European Polyglot Persistence Meetups Tour Polyglot Persistence means that when storing data, it is best to use multiple data storage technologies, chosen based upon the way data is being used by the application. We’re starting off with Amsterdam, then moving on to Dublin, Paris, Berlin, Stockholm and London. And for our kick-off in Amsterdam, we’re lucky to be sponsored by Booking.com. Please sign up for the meetup of your choice, as we’re announcing locations, speakers etc. via the Meetup platform. Sign up for a meetup
	Become a ClusterControl DBA: Operational Reports for MySQL and MariaDB Performing database health checks is a lot more time-consuming than it should be. As a DBA, you have to gather data from multiple places in order to understand the state of your databases. This is why we introduced operational reports in ClusterControl 1.3, where we gather some of the most important data into a single document, which can be quickly reviewed. This new blog post explains how you can make best use of this new functionality in ClusterControl. Read the blog

That’s it for this week! Feel free to share these resources with your colleagues and follow us in our social media channels.

Have a good end of the week,

Jean-Jérôme Schmidt
Planets9s Editor
Severalnines AB

Databases usually work in a secure environment. It may be a datacenter with a dedicated VLAN for database traffic. It may be a VPC in EC2. If your network spreads across multiple datacenters in different regions, you’d usually use some kind of Virtual Private Network or SSH tunneling to connect these locations in a secure manner. With data privacy and security being hot topics these days, you might feel better with an additional layer of security.

MySQL supports SSL as a means to encrypt traffic both between MySQL servers (replication) and between MySQL servers and clients. If you use Galera cluster, similar features are available - both intra-cluster communication and connections with clients can be encrypted using SSL.

A common way of implementing SSL encryption is to use self-signed certificates. Most of the time, it is not necessary to purchase an SSL certificate issued by the Certificate Authority. Anybody who’s been through the process of generating a self-signed certificate will probably agree that it is not the most straightforward process - most of the time, you end up searching through the internet to find howto’s and instructions on how to do this. This is especially true if you are a DBA and only go through this process every few months or even years. This is why we recently added a new ClusterControl feature designed to help you manage SSL keys across your database cluster. We based this blog post on ClusterControl 1.3.1.

Key Management in the ClusterControl

You can enter Key Management by going to Settings->Key Management section.

You will be presented with the following screen:

You can see two certificates generated, one being a CA and the other one a regular certificate. To generate more certificates, switch to the ‘Generate Key’ tab:

A certificate can be generated in two ways - you can first create a self-signed CA and then use it to sign a certificate. Or you can go directly to the ‘Client/Server Certificates and Key’ tab and create a certificate. The required CA will be created for you in the background. Last but not least, you can import an existing certificate (for example a certificate you bought from one of many companies which sell SSL certificates).

To do that, you should upload your certificate, key and CA to your ClusterControl node and store them in /var/lib/cmon/ca directory. Then you fill in the paths to those files and the certificate will be imported.

If you decided to generate a CA or generate a new certificate, there’s another form to fill - you need to pass details about your organization, common name, email, pick the key length and expiration date.

Once you have everything in place, you can start using your new certificates. ClusterControl currently supports deployment of SSL encryption between clients and MySQL databases and SSL encryption of intra-cluster traffic in Galera Cluster. We plan to extend the variety of supported deployments in future releases of the ClusterControl.

Full SSL encryption for Galera Cluster

Now let’s assume we have our SSL keys ready and we have a Galera Cluster, which needs SSL encryption, deployed through our ClusterControl instance. We can easily secure it in two steps.

First - encrypt Galera traffic using SSL. From your cluster view, one of the cluster actions is  Enable Galera SSL Encryption. You’ll be presented with the following options:

If you do not have a certificate, you can generate it here. But if you already generated or imported an SSL certificate, you should be able to see it in the list and use it to encrypt Galera replication traffic. Please keep in mind that this operation requires a cluster restart - all nodes will have to stop at the same time, apply config changes and then restart. Before you proceed here, make sure you are prepared for some downtime while the cluster restarts.

Once intra-cluster traffic has been secured, we want to cover client - server connections. To do that, pick ‘Enable SSL Encryption’ job and you’ll see following dialog:

It’s pretty similar - you can either pick an existing certificate or generate new one. The main difference is that to apply client - server encryption, downtime is not required - a rolling restart will suffice.

Of course, enabling SSL on the database is not enough - you have to copy certificates to clients which are supposed to use SSL to connect to the database. All certificates can be found in /var/lib/cmon/ca directory on the ClusterControl node. You also have to remember to change grants for users and make sure you’ve added REQUIRE SSL to them if you want to enforce only secure connections.

We hope you’ll find those options easy to use and help you secure your MySQL environment. If you have any questions or suggestions regarding this feature, we’d love to hear from you.

Welcome to this week’s Planets9s, covering all the latest resources and technologies we create around automation and management of open source database infrastructures.

	Sign up for our MySQL Database Performance Tuning webinar on June 14th You’re running MySQL as backend database, how do you tune it to make best use of the hardware? How do you optimize the Operating System? How do you best configure MySQL for a specific database workload? If these questions sound familiar, then this webinar is for you. We’ll discuss some of the settings that can bring you significant improvement in the performance of your MySQL database as well as some of the variables which are frequently modified even though they should not. Performance tuning is not easy, but you can go a surprisingly long way with a few basic guidelines. Sign up for the webinar
Join us for our European Polyglot Persistence Meetups Tour We’re delighted to announce the first dates of our European Polyglot Persistence Meetups this summer. We’re starting off with Amsterdam today, then moving on to Dublin next week, Paris, Berlin, Stockholm and London. We’ll cover MySQL, PostgreSQL and MongoDB storage backends with the topics of deployment, scaling, configuration, management, backups and monitoring. And with time and as members suggest topics, the scope is likely to broaden. Join the meetups
	Severalnines helps IIL handle over 100 million transaction per day This week we’re happy to announce our latest customer, IIL, a UK-based data and technology company. IIL specialises in providing pricing, fraud and compliance technology for insurance and credit providers. In their own words “ClusterControl gives us detailed insight into our database clusters in an intuitive format. Now we can see what is really going on under the hood quickly without a lot of time to go through the logs.” Read the press release
Become a ClusterControl DBA - SSL Key Management and Encryption of MySQL Data in Transit Anybody who’s been through the process of generating a self-signed certificate will probably agree that it is not the most straightforward process - most of the time, you end up searching through the internet to find howto’s and instructions on how to do this. This is especially true if you are a DBA and only go through this process every few months or even years. This is why we recently added a new ClusterControl feature designed to help you manage SSL keys across your database cluster. This new blog explains how. Read the blog

That’s it for this week! Feel free to share these resources with your colleagues and follow us in our social media channels.

Have a good end of the week,

Jean-Jérôme Schmidt
Planets9s Editor
Severalnines AB

Following the recent completion of our testers programme for NinesControl, we’re now happy to announce the public availability of NinesControl (beta), the database infrastructure management solution for the cloud.

Many thanks to our testers for participating in the NinesControl feedback programme. With the collective insight gained, we were able to fine-tune this initial public release and present it to you today.

With NinesControl, users can now easily and quickly deploy and monitor (MySQL) Galera clusters on DigitalOcean. Droplets are launched and managed using your own DigitalOcean account.

We encourage you to sign up on ninescontrol.com and try this new service out.

NinesControl is designed with developers in mind. Spend time developing your applications and let the service provision, monitor and manage your databases.

It is currently in beta for DigitalOcean and Galera cluster users, before we expand the service to other public cloud providers and databases.

With a couple of simple steps, you can deploy and manage MySQL Galera with Percona, MariaDB or Codership. We are currently underway of adding support for MongoDB and Amazon EC2 as a cloud provider.

Overtime more monitoring and management features will be added to the service such as:

• Automated backups, Schema and DB user management
• Health, query and performance monitoring
• Configuration management
• Scaling out and deploying load balancers like HAProxy and MaxScale
• Notifications through email and incident management services
• and more ...

Try it out today!

Welcome to this week’s Planets9s, covering all the latest resources and technologies we create around automation and management of open source database infrastructures.

	New blog series: Become a PostgreSQL DBA (if you’re really a MySQL DBA) MySQL and PostgreSQL - two open source relational database management systems, each with their own set of use cases and users. You may be asking - why use both of these databases in one environment? Is there any value in having a replicated PostgreSQL setup running alongside a MySQL / MariaDB Galera cluster? In this blog post, which is the first in this new series, we try to answer these questions from the MySQL DBA standpoint and discuss different methods of deploying PostgreSQL. Read the blog
Try the new NinesControl: deploy and monitor MySQL Galera clusters on Digital Ocean This week we’re happy to announce the public availability of NinesControl (beta), our new database infrastructure management solution for the cloud. Designed with the needs of developers in mind, NinesControl enables users to easily deploy and monitor (MySQL) Galera clusters on DigitalOcean. Droplets are launched and managed using your own DigitalOcean account. We’d love to get your feedback on this new solution, so please do check it out and let us know what you think. Try the new NinesControl
	Become a MongoDB DBA: the basics of configuration After covering the deployment of MongoDB in our previous blogpost in this series, we now move on to configuration basics. MongoDB is configured through both the config file (/etc/mongod.conf) and runtime. We discussed some of the configurables last month and now we go more in depth on each of them. Read the blog
Sign up for our MySQL Database Performance Tuning webinar next week There are still a few “seats” left for this popular new webinar on MySQL Database Performance Tuning, which takes place next Tuesday, June 14th. We’ll discuss some of the settings that can bring you significant improvement in the performance of your MySQL database as well as some of the variables which are frequently modified even though they should not. Performance tuning is not easy, but you can go a surprisingly long way with a few basic guidelines. Sign up for the webinar

That’s it for this week! Feel free to share these resources with your colleagues and follow us in our social media channels.

Have a good end of the week,

Jean-Jérôme Schmidt
Planets9s Editor
Severalnines AB

Welcome to this week’s Planets9s, covering all the latest resources and technologies we create around automation and management of open source database infrastructures.

	Watch the replay of our MySQL Database Performance Tuning webinar Thanks to everyone who participated in this week’s popular webinar on MySQL Database Performance Tuning, which discussed the following topics: database tuning overview, principles of the tuning process, tuning the Operating System configuration and the MySQL configuration, useful tools such as pt-summary and pt-mysql-summary and what to avoid when tuning OS and MySQL configuration. The replay of this webinar is now available online! Watch the replay
Upgrading to MySQL 5.7 - The Database Upgrade Guide During this week’s webinar on MySQL database performance tuning, a lot of participants expressed their interest in upgrading to MySQL 5.7. If that’s the case for you as well, then our new whitepaper on how to do so will hopefully be of help. Upgrading to a new major version involves risk, and it is important to plan the whole process carefully. In this whitepaper, we look at the important new changes in MySQL 5.7 and how to plan the test process, do a live system upgrade without downtime, avoid connection failures during slave restarts and switchover, or how to leverage ProxySQL to achieve a graceful upgrade process. Download the whitepaper
	Try NinesControl: deploy and monitor MySQL Galera clusters on Digital Ocean We recently announced the public availability of NinesControl (beta), our database infrastructure management solution for the cloud. Designed with the needs of developers in mind, NinesControl enables users to easily deploy and monitor (MySQL) Galera clusters on DigitalOcean. Droplets are launched and managed using your own DigitalOcean account. We’d love to get your feedback on this new solution if you haven’t tested it yet, so please check it out and let us know what you think. Try NinesControl
MySQL Docker containers: understanding the basics Welcome to our new blog series - “MySQL on Docker” - in which we will touch upon swarms, shared volumes, data-only-containers, security and configuration management, multi-host networking, service discovery and implications on monitoring when we move from host-centric to role-centric services with shorter life cycles. In this initial post, we cover some basics around running MySQL in a container. Read the blog

That’s it for this week! Feel free to share these resources with your colleagues and follow us in our social media channels.

Have a good end of the week,

Jean-Jérôme Schmidt
Planets9s Editor
Severalnines AB

Today we launch our live CrowdChat on everything #galera!

This CrowdChat is brought to you by Severalnines and is hosted by a community of subject matter experts. CrowdChat is a community platform that works across Facebook, Twitter, and LinkedIn to allow users to discuss a topic using a specific #hashtag. This crowdchat focuses on the hashtag #galera. So if you’re a DBA, architect, CTO, or a database novice register to join and become part of the conversation!

Join this online community to interact with experts on Galera clusters. Get your questions answered and join the conversation around everything #galera.

Register free

Meet the experts

	Art van Scheppingen is a Senior Support Engineer at Severalnines. He’s a pragmatic MySQL and Database expert with over 15 years experience in web development. He previously worked at Spil Games as Head of Database Engineering, where he kept a broad vision upon the whole database environment: from MySQL to Couchbase, Vertica to Hadoop and from Sphinx Search to SOLR. He regularly presents his work and projects at various conferences (Percona Live, FOSDEM) and related meetups.
Krzysztof Książek is a Senior Support Engineer at Severalnines, is a MySQL DBA with experience managing complex database environments for companies like Zendesk, Chegg, Pinterest and Flipboard.
	Ashraf Sharif is a System Support Engineer at Severalnines. He has previously worked as principal consultant and head of support team and delivered clustering solutions for big websites in the South East Asia region. His professional interests focus on system scalability and high availability.
Vinay Joosery is a passionate advocate and builder of concepts and businesses around Big Data computing infrastructures. Prior to co-founding Severalnines, Vinay held the post of Vice-President EMEA at Pentaho Corporation - the Open Source BI leader. He has also held senior management roles at MySQL / Sun Microsystems / Oracle, where he headed the Global MySQL Telecoms Unit, and built the business around MySQL's High Availability and Clustering product lines. Prior to that, Vinay served as Director of Sales & Marketing at Ericsson Alzato, an Ericsson-owned venture focused on large scale real-time databases.

Welcome to this week’s Planets9s, covering all the latest resources and technologies we create around automation and management of open source database infrastructures.

	New webinar on how to monitor MongoDB (if you’re really a MySQL DBA) As you may know, MongoDB offers many metrics through various status overviews and commands, but which ones really matter to you? How do you trend and alert on them? What is the meaning behind the metrics? In this new webinar on July 12th, we’ll discuss the most important ones and describe them in ordinary plain MySQL DBA language. And we’ll have a look at the (open source) solutions available for MongoDB monitoring and trending, including how to leverage ClusterControl’s MongoDB metrics, dashboards, custom alerting and other features to track and optimize the performance of your system. Sign up for the webinar
What to test before upgrading to MySQL 5.7 In this blog post, we look at some of the important things to keep in mind when preparing and performing tests for an upgrade to MySQL 5.7. As we saw in a previous post, there are some important changes between MySQL 5.6 and 5.7. Since the behaviour of some existing features been altered, some detailed testing of the upgrade is in order. This new blog post (and associated whitepaper) show you how. Read the blog
	Deploy & monitor MySQL Galera clusters on Digital Ocean with NinesControl Designed with the needs of developers in mind, NinesControl enables users to easily deploy and monitor (MySQL) Galera clusters on DigitalOcean. Droplets are launched and managed using your own DigitalOcean account. We’d love to get your feedback on this new solution if you haven’t tested it yet, so please check it out and let us know what you think. Try NinesControl
Become a PostgreSQL DBA: Provisioning & Deployment In this blog post, we address the following questions from the MySQL DBA standpoint: why use both MySQL and PostgreSQL in one environment? Is there any value in having a replicated PostgreSQL setup running alongside a Galera Cluster? We also discuss different methods of deploying PostgreSQL. Read the blog

That’s it for this week! Feel free to share these resources with your colleagues and follow us in our social media channels.

Have a good end of the week,

Jean-Jérôme Schmidt
Planets9s Editor
Severalnines AB

If you haven’t upgraded to ClusterControl 1.3.1, you should! It’s full of great new features and enhancements. We have lots of documentation to help you get started. Documentation on older versions is also available in our Github repository.

Wizard - Create Replication Setups for Oracle MySQL, MariaDB and Percona Server

It is now possible to create entire master-slave setups in one go via the deployment wizard. In previous versions, one had to first create a master, and afterwards, add slaves to it. Among other improvements, it is possible to encrypt client/server connections and let ClusterControl automatically set all slaves to read-only (auto_manage_readonly) to avoid accidental writes.

Wizard - Add Existing MySQL Cluster (NDB)

We recently added support for deployment of MySQL Cluster (NDB), and it is now also possible to import existing NDB Cluster deployments (2 MGMT nodes, x SQL nodes and y Data nodes).

Official Changelog

We now have two Changelog pages, one in our support forum (this is mostly for our development reference) and a new official one in the documentation. You can now easily browse all the changes between each release, including release features, type of release and package build numbers.

Check out the new Changelog page.

ClusterControl troubleshooting with debug package

ClusterControl Controller (cmon) now comes with a debuginfo package to help trace any crashes. It produces a core dump of the working memory of the server at the time the program crashed or terminated abnormally.

ClusterControl Controller (CMON) package comes with a cron file installed under /etc/cron.d/ which will auto-restart if the cmon process is terminated abnormally. Typically, you may notice if cmon process has crashed by looking at the “dmesg” output.

Check out the new debugging steps here.

Standby ClusterControl

It is possible to have several ClusterControl servers to monitor a single cluster. This is useful if you have a multi-datacenter cluster and need to have ClusterControl on the remote site to monitor and manage local nodes if the network connection between them goes down. However, the ClusterControl servers must be configured to be working in active/passive mode to avoid race conditions when digesting queries and recovering a failed node or cluster.

Check out the updated instructions to install the ClusterControl Standby server.

ClusterControl RPC key

ClusterControl v1.3.1 introduces and enforces an RPC key for any communication request to the RPC interface on port 9500. This authentication string is critical and must be included in any interaction between CMON controller and the client to obtain a correct response. The RPC key is distinct per cluster and stored inside CMON configuration file of the respective cluster.

ClusterControl Domain Specific Language (CCDSL)

The DSL syntax is similar to JavaScript, with extensions to provide access to ClusterControl’s internal data structures and functions. The CCDSL allows you to execute SQL statements, run shell commands/programs across all your cluster hosts, and retrieve results to be processed for advisors/alerts or any other actions.

Our javascript-like language to manage your database infrastructure has now been updated with several new features, for example:

• Types:
  • CmonMongoHost
  • CmonMaxscaleHost
  • CmonJob
• Functions:
  • JSON
  • Regular Expression
  • CmonJob
  • Cluster Configuration Job
• Examples:
  • Interact with MongoDB

Check out the ClusterControl DSL page here.

We welcome any feedback, suggestion and comment in regards to our documentation page to make sure it serves the purpose right. Happy clustering!

Backups - one of the most important things to take care of while managing databases. It is said there are two types of people - those who backup their data and those who will backup their data. In this blog post, we will discuss good practices around backups and show you how you can build a reliable backup system using ClusterControl.

Backup types

There are two main types of backup:

• Logical backup - backup of data is stored in a human-readable format like SQL
• Physical backup - backup contains binary data

Both complement each other - logical backup allows you to (more or less easily) retrieve up to a single row of data. Physical backups would require more time to accomplish that, but, on the other hand, they allow you to restore an entire host very quickly (something which may take hours or even days when using logical backup).

ClusterControl supports both types of backup: mysqldump for logical backup and xtrabackup for physical backup.

Backup schedule

Obviously, you’d want to have a fixed schedule for your backups. How often you want the backup to execute? It depends on your application, importance of data, time needed to take the backup and so on. We’d recommend to take a backup at least daily. When possible, you’d want to take both mysqldump and xtrabackup backups on a daily basis. To cover even more bases, you may want to schedule several incremental xtrabackup runs per day.

In ClusterControl you can easily schedule these different types of backups. There are a couple of settings to decide on. You can store a backup on the controller or locally, on the database node where the backup is taken. You need to decide on the location in which the backup should be stored, and which databases you’d like to backup - all data set or separate schemas? Depending on which backup type you’ve chosen, there are separate settings to configure. For Xtrabackup and Galera Cluster, you may choose if a node should be desynced or not. Are you going to use backup locks or maybe ‘FLUSH TABLES WITH READ LOCK’ should be used instead? Should the backup be compressed or not?

Which options to use will depend on your particular setup and hardware. For Galera Cluster, to avoid impact on the rest of the cluster, we’d suggest at least to think about desyncing the node for the duration of the backup. Please keep in mind this may also remove your backup node from rotation, this is especially true if you use HAProxy or MaxScale proxies.

Another popular way of minimizing the impact of a backup on a Galera Cluster or a replication master is to deploy a replication slave and then use it as a source of backups - this way Galera Cluster will not be affected at any point.

You can deploy such a slave in just a few clicks using ClusterControl.

Checking backup status

Taking a backup is not enough - you have to check if it actually completed correctly. ClusterControl can help with this. You can go to the Backup -> Reports tab and check the status of your backups. Have they completed successfully? What’s their size - is it as expected? This is a good way to do a quick sanity check - if your dataset is around 1GB of size, there’s no way a full backup can be as small as 100KB - something must have gone wrong at some point. To dig even deeper, you can take a look at the backup log and look for any errors.

Disaster Recovery

Storing backups within the cluster (either directly on a database node or on the ClusterControl host) comes in handy when you want to quickly restore your data: all backup files are in place and can be decompressed and restored promptly. When it comes to disaster recovery, this may not be the best option. Different issues may happen - servers may crash, network may not work reliably, even whole data centers may not be accessible due to some kind of outage. It may happen whether you work with a small service provider with a single data center, or a global vendor like Amazon or Rackspace. It is therefore not safe to keep all your eggs in a single basket - you should make sure you have a copy of your backup stored in some external location. ClusterControl supports Amazon S3 and Glacier services for that .

For those who would like to implement their own DR policies, ClusterControl backups are stored in a nicely structured directory. So it is perfectly fine to build and deploy your own set of scripts and handle DR according to your exact requirements.

Finally, another great way of implementing a Disaster Recovery policy is to use an asynchronous replication slave - something we mentioned earlier in this blog post. You can deploy such asynchronous slave in a remote location, some other data center maybe, and then use it to do backups and store them locally on that slave. Of course, you’d want to take a local backup of your cluster to have it around locally if you’d need to recover the cluster. Moving data between datacenters may take a long time, so having a backup files available locally can save you some time. In case you lose the access to your main production cluster, you may still have an access to the slave. This setup is very flexible - first, you have a running MySQL host with your production data so it shouldn’t be too hard to deploy your full application in the DR site. You’ll also have backups of your production data which you could use to scale out your DR environment.

We hope this gives you enough information to build a safe and reliable backup system.

Those of you who already follow us know that we’ve been running a number of blog series for some time now that we also deliver as webinar series.

These blog series include:

• Become a MySQL DBA
• Become a MongoDB DBA
• Become a PostgreSQL DBA

And for those who are looking to automate the management of all of the above, we also have:

• Become a ClusterControl DBA
• ClusterControl Developer Studio
• ClusterControl Tips & Tricks

These blog series as well as related topics are covered monthly in our live webinars, which are available to view as replays.

Watch our webinar replays

So whether you’re interested in open source datastores such as MySQL, MariaDB, Percona, MongoDB or MySQL; load balancers such as HAProxy, MaxScale or ProxySQL; whether you’re in DB Ops or DevOps; looking to automate and manage your databases… Chances are that we have a relevant webinar replay for you!

These are the categories you can select from:

• ClusterControl
• DB Ops
• DevOps
• Galera
• MongoDB
• MySQL
• PostgreSQL
• Tips & Tricks

Or just perform a search for the topic or keyword of your choice and see what comes up.

We trust that these resources are useful!

If you have a topic you’d like to see covered that we haven’t dealt with yet, please do let us know.

ClusterControl provides centralized backup management and it supports the standard mysqldump and Percona Xtrabackup backup methods. We believe the chosen command line arguments for the respective methods are optimal for most database workloads, and comply to the MySQL backup best practices. We are influenced by all the feedback we have received over the years, when working with DBAs and sysadmins. However, you might still want to customize your backup. In this post, we will show you how to do this.

By default, ClusterControl will append the following MySQL backup-related lines inside the my.cnf if they aren’t already in there:

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
user=backupuser
password=[random password]

[xtrabackup]
user=backupuser
password=[random password]

The above might not be enough in some circumstances. Let’s see how we customize this for our environment, using the respective backup method.

mysqldump

By default, ClusterControl creates 4 mysqldump files with the following suffix:

• _triggerseventroutines - Triggers, event and routines
• _data - Database data
• _schema - Database schema
• _mysql - MySQL system database

Let’s say we have 5 databases and we chose to backup all of them. Here is what ClusterControl will execute when performing the backup using mysqldump method (commands are trimmed with backslash for readability):

• Triggers, event and routines dump file:

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/mysql/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --no-create-info \
  --no-data \
  --set-gtid-purged=OFF \
  --triggers \
  -R --events \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables  \
  --skip-add-locks \
  --databases accounting mydb s9s_cmon sakila sbtest

• Data dump file:

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --no-create-info \
  --master-data=2 \
  --set-gtid-purged=OFF \
  --skip-triggers \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --skip-add-locks \
  --databases accounting mydb s9s_cmon sakila sbtest

  *master-data=2 is included only if the MySQL node is generating binary log.

• Schema dump file:

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt  \
  --no-data \
  --set-gtid-purged=OFF  \
  --add-drop-table \
  --skip-triggers \
  --single-transaction \
  --skip-comments  \
  --skip-lock-tables \
  --databases accounting mydb s9s_cmon sakila sbtest

• Mysql database dump file:

  $ /usr/bin/mysqldump \
  --defaults-file=/etc/mysql/my.cnf \
  --flush-privileges \
  --hex-blob \
  --opt \
  --set-gtid-purged=OFF \
  --single-transaction \
  --skip-comments \
  --skip-lock-tables \
  --skip-add-locks \
  --databases mysql

From the above command lines, we can see that on each mysqldump command, ClusterControl includes the MySQL configuration file into its --defaults-file argument. By having this, the mysqldump process is able to read the content of the mysqldump directive. By default ClusterControl configures the backup user credentials together with max_allowed_packet, similar to the following:

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
user=backupuser
password=[random password]

The advantage of this is that we can include some extra options for mysqldump. Unfortunately, the --defaults-file argument can only be specified as the foremost argument. Pay attention that the latter command line arguments take precedence on what have been configured inside my.cnf under [mysqldump] directive based on the order they appear. For example, if we add skip-comments=0 inside my.cnf, while at the end of the mysqldump command, there is a --skip-comments (or --skip-comments=1), the former will be ignored and the latter will be used.

Nevertheless, we can still use it as part of our backup customization by using other mysqldump backup options. For example, we can exclude tables that we don’t want to backup by using ignore-table parameter (with “database.table” formatting). Add the following lines into the MySQL configuration file:

[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
user=backupuser
password=[random password]
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1

Once configured, we can just trigger a new mysqldump job from ClusterControl and we will have those tables skipped by mysqldump. No MySQL restart is required.

Percona Xtrabackup

ClusterControl executes the Xtrabackup depending on the options you chose. Consider the following:

Based on the above options, the complete Xtrabackup command would be:

$ ulimit -n 256000 && LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf  --galera-info --parallel 1 --stream=xbstream --no-timestamp .

The first command “ulimit  -n 256000” is to ensure that Percona Xtrabackup has sufficient privileges to access a huge number of file descriptors (in case the databases contain many tables). Take note of the --defaults-file=/etc/mysql/my.cnf, which is similar to mysqldump, where innobackupex reads the content of MySQL configuration on the following directives and variables:

[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]

[xtrabackup]
user=backupuser
password=[random password]

If you would like to customize the backup options for Percona Xtrabackup, you can add them directly under [xtrabackup] directive. For example, let’s say we want Xtrabackup to print the binary log position when the backup is taken, we can add something like this:

[xtrabackup]
user=backupuser
password=[random password]
slave-info=1

Triggering the xtrabackup job will then include a file called xtrabackup_slave_info file. No MySQL restart is required.

We hope this helps you better manage your MySQL backups!

Join us for the first part of our upcoming webinar trilogy on MySQL Query Tuning. Over the course of three in-depth webinar sessions led by Krzysztof Książek, Senior Support Engineer at Severalnines, we’ll cover SQL tuning, indexing, the MySQL optimizer and how to leverage EXPLAIN to gain insight into execution plans.

Tuning MySQL queries and indexes can significantly increase the performance of your application as well as decrease response times, when done right. This is why we’re covering this complex topic over the course of three webinars of 60 minutes each.

This first part of the trilogy focuses on the query tuning process and related tools. Building, collecting, analysing, tuning and testing will be discussed in detail as well as the main tools involved, tcpdump and pt-query-digest.

Date & Registration

Part 1: Query tuning process and tools

Tuesday, August 30th

Register

Feel free to also register for Parts 2 & 3.

Agenda

• MySQL Query Tuning Trilogy: Process and tools
• Query tuning process
  • Build
  • Collect
  • Analyse
  • Tune
  • Test
• Tools
  • tcpdump
  • pt-query-digest

Speaker

Krzysztof Książek, Senior Support Engineer at Severalnines, is a MySQL DBA with experience in managing complex database environments for companies like Zendesk, Chegg, Pinterest and Flipboard. He’s the main author of the Severalnines blog and webinar series: Become a MySQL DBA.

We look forward to “seeing” you there!

In our previous blog post we covered the deployment of four types of clustering/replication: MySQL Galera, MySQL master-slave replication, PostgreSQL replication set and MongoDB replication set. This should enable you to create new clusters with great ease, but what if you already have 20 replication setups deployed and wish to manage them with ClusterControl?

This blog post will cover adding existing infrastructure components for these four types of clustering/replication to ClusterControl and how to have ClusterControl manage them.

Adding an existing Galera cluster to ClusterControl

Adding an existing Galera cluster to ClusterControl requires: mysql user with the proper grants and a ssh user that is able to login (without password) from the ClusterControl node to your existing databases and clusters.

Install ClusterControl on a separate VM. Once it is up, open the two-step dialogue for adding an existing cluster. All you have to do is to add one of the Galera nodes and ClusterControl will figure out the rest:

After this behind the scenes, ClusterControl will connect to this host and detect all the necessary details for the full cluster and register the cluster in the overview.

Adding an existing MySQL master-slave to ClusterControl

Adding of an existing MySQL master-slave topology requires a bit more work than adding a Galera cluster. As ClusterControl is able to extract the necessary information for Galera, in the case of master-slave, you need to specify every host within the replication setup.

After this, ClusterControl will connect to every host, see if they are part of the same topology and register them as part of one cluster (or server group) in the GUI.

Adding an MySQL NDB Cluster to ClusterControl

Adding an existing MySQL NDB Cluster takes four steps in total: defining SSH, management nodes, data nodes and finally the MySQL nodes.

After this ClusterControl will connect to the management, data and MySQL nodes and see if they are indeed part of the cluster. Then it will register the cluster, start monitoring and managing it.

Adding an existing PostgreSQL replication set to ClusterControl

Similar to adding the MySQL master-slave above, the PostgreSQL replication set also requires to fill in all hosts within the same replication set.

After this, ClusterControl will connect to every host, see if they are part of the same topology and register them as part of the same group.

Adding an existing MongoDB replica set to ClusterControl

Adding an existing MongoDB replica set is just as easy as Galera: just one of the hosts in the replica set needs to be specified with its credentials and ClusterControl will automatically discover the other nodes in the replica set.

Adding an existing MongoDB sharded cluster set to ClusterControl

Adding an existing MongoDB sharded cluster is almost as easy as a MongoDB replica set: all shard routers in the cluster need to be specified with its credentials, and ClusterControl will automatically discover all shards and replica sets in the cluster.

Expanding your existing infrastructure

After adding the existing databases and clusters, they now have become manageable via ClusterControl and thus we can scale out our clusters.

For MySQL, MongoDB and PostgreSQL replication sets, this can easily be achieved via the same way we showed in our previous blogpost: simply add a node and ClusterControl will take care of the rest.

For Galera, there is a bit more choice. The most obvious choice is to add a (Galera) node to the cluster by simply choosing “add node” in the cluster list or cluster overview. Expanding your Galera cluster this way should happen with increments of two to ensure your cluster always can have majority during a split brain situation.

Alternatively you could add a replication slave and thus create asynchronous slave in your synchronous cluster that looks like this:

Adding a slave node blindly under one of the Galera nodes can be dangerous since if this node goes down, the slave won’t receive updates anymore from its master. We blogged about paradigm earlier and you can read how to solve this in this blog post:

http://severalnines.com/blog/deploy-asynchronous-replication-slave-mariadb-galera-cluster-gtid-clustercontrol

Final thoughts

We showed you how easy it is to add existing databases and clusters to ClusterControl, you can literally add clusters within minutes. So nothing should hold you back from using ClusterControl to manage your existing infrastructure. If you have a large infrastructure, the addition of ClusterControl will give you more overview and save time in troubleshooting and maintaining your clusters.

Now the challenge is how to leverage ClusterControl to keep track of key performance indicators, show the global health of your clusters and proactively alert you in time when something is predicted to happen. And that’s the subject we'll cover next time.

Read also in the same series: Become a ClusterControl DBA - Deploying your Databases and Clusters