How DatabaseCare solves the challenge of patching enterprise databases

TuxCare Team

October 12, 2021


Security vulnerabilities emerge everywhere – in applications, in operating systems, and in all the technology services that come together to form modern technology stacks. That includes the database services that applications rely on to store and retrieve information: security vulnerabilities affect both commercial database solutions as well as open-source solutions such as MySQL.

Of course, vulnerabilities don’t simply pile up, turning software into big blocks of Swiss cheese. Generally speaking, vendors and open-source development groups release patches for vulnerabilities. Apply patches promptly, and your services – such as your database – stays secure.

For some services, patching is straightforward, and that’s the case for many database services too. Indeed, there are a lot of best practice solutions out there that, in theory, should guide you through database parching.

But the reality can be very different because no two companies have the same technology configurations, with varying levels of knowledge. Different continuity requirements are also common. In this article, we outline why databases are also vulnerable, why database patching can be such a tough issue – and offer a solution in the shape of live patching for databases.


1. Databases are vulnerable too
2. What’s the problem with best practices?
3. Typical example – mySQL clusters
4. How does DatabaseCare work?
5. A solution for tough database patching challenges


Databases are vulnerable too

In some of our previous articles, we’ve highlighted how sometimes the less visible services that run in the background, quietly supporting our IT infrastructure, are just as vulnerable as any other part of the enterprise technology stack.

That includes databases too, and there is plenty of support for this suggestion. Take MySQL, for example, a popular open-source database. If you search the Mitre database for MySQL you’ll find over a thousand entries for vulnerabilities linked to MySQL, or affecting MySQL.

Let’s take some examples. CVE-2016-6662 was reported in September 2016 and affected most MySQL versions and forks of MySQL that were in use at the time. The vulnerability allowed attackers to remotely inject malicious MySQL settings into the MySQL configuration file. Of course, because MariaDB is a fork of MySQL, MariaDB was also vulnerable – and MariaDB users had to follow the steps outlined here.

To illustrate the complexity underlying database security vulnerabilities, consider this vulnerability identified in 2020 – specific to MariaDB. Here, a privilege escalation attack is possible because of the way that MariaDB 10.4.7 through 10.4.11 handheld “setuid” during installation. Again, users who upgraded to a newer version of MariaDB were not affected.

What’s the problem with best practices?

As we suggested earlier – vulnerabilities are commonplace, but cybersecurity provisions don’t necessarily fall apart because most enterprise users are reasonably good at patching. We say reasonably good because patching is rarely one hundred percent consistent.

Yes, patching best practices exist – and it does so for database services too. There are however a few caveats associated with patching best practice:

  • Downtime. Patching commonly leads to downtime, or at the very least service degradation during migrations. Planning can mitigate downtime, but inevitably a live service will experience some kind of impact.
  • An element of risk. Stopping and starting a service to patch it always carries a risk, whether it’s inaccurate planning for failover, or perhaps an unexpected consequence when the service fails to come back online and nobody knows what the cause is.
  • Time consumed. Particularly where database environments are complex, and where patching requires extensive migration procedures, the time consumed during the patching process can be excessive.
  • Lack of resources. Just like any other team, technology teams often run on a restricted budget – IT teams have sufficient, but not excessive resources. Oftentimes, due to competing requirements, patching can be neglected – leaving systems vulnerable during the delay in patching.
  • Complex patching instructions. Particularly when it comes to intricate, distributed database environments,  the associated patching instructions can be so tough to follow that many teams may well decide that it’s not even worth trying – or taking the risk.

So while patching is good practice, there are a whole range of reasons why databases may not be patched as frequently as needed – or patched on time.

Typical example – mySQL clusters

The last point is particularly important because it impacts patching best practices. Where instructions are incredibly complex the internal assessment could easily be that the risk of a failed patch – or the time spent trying to patch – outweighs the risk of a successful exploit.

You can see what can lead to this thinking by examining this official MySQL article which spends a whole section of the document to explain how to patch a MySQL cluster. Worse, in that document, MySQL addresses just one specific type of cluster, InnoDB. This isn’t the only strategy for clustering MySQL.

Neither does the document tell you how to deal with interruptions to other applications, or what the impacts are on your systems – in fact, it couldn’t, as each case is different. So while the document offers a guide, many sysadmin teams will still be left with their heads scratching. It may well lead to an extensive troubleshooting exercise. As a suggestion, if you do not have a replica of your production environment for use as testing and staging of this type of operations, you should seriously consider it.

We can offer many more examples. This free instruction guide on upgrading a MySQL cluster claims the process is simple, but goes ahead and offers more than five pages of instructions, which is hardly simple. It doesn’t matter which SQL database you use – for MariaDB and PostgreSQL the steps are set to be quite complex.

How does DatabaseCare work?

The premise behind DatabaseCare is simple. In complete contrast to manual, time-consuming patching that is disruptive and requires restarts, DatabaseCare is a live patching solution.

In other words, you can patch a database without the need to restart the database server – the patch is installed live, while your databases are running and actively serving data. The process is really simple:

  1. Servers running the database connect to DatabaseCare ePortal, which is your secure copy of the DatabaseCare patch repository
  2. The ePortal pulls the updates from the DatabaseCare main patch server through your firewall, keeping the infrastructure isolated from the outside world
  3. When a new update is applicable, DatabaseCare agent momentarily freezes the database processes in a ‘safe’ mode
  4. DatabaseCare applies the patch in memory and it all happens transparently to apps and users connected to the database and to the DB itself

When you deploy DatabaseCare you don’t need any complex processes to stop, patch, and restart databases that need to be orchestrated with other systems. Nor do you affect regular business processes.

You simply deploy the DatabaseCare agent and it will automatically update the running database with the latest security updates, without ever interrupting it or impacting its performance or usage in any way.

It’s easy to see that live patching produces a range of benefits over standard patching procedures. Some of the benefits of using automated patching via DatabaseCare include:

  • A single step. Instead of following complex, long-winded instructions for patching, users of DatabaseCare can choose to simply deploy the agent and not worry about it further. There’s no need for extensive downtime or migration planning either, and no risk that something will go wrong.
  • Time and cost saving. Instead of spending time trying to patch their Teams can devote their energy elsewhere. It’s a huge boost for IT efficiency in the broad given, how much time patching consumes.
  • Improved security. Because patching is a single-step and relatively risk-free process, and because teams don’t need to spend that much time performing patching processes, patching can happen in a timelier manner – with more frequent patching. The result is that there is a reduced window of opportunity for attackers to exploit a vulnerability.

These are important benefits that all work together to firm up the cybersecurity posture of companies who face an endless list of threats.

A solution for tough database patching challenges

If your company is using databases like MySQL, MariaDB or PostgreSQL for critical business operations, correctly securing your database should not be a guessing game. The complexity around these databases essentially turns matters into a guessing game – patching is risky, and patching is likely uneven too.

DatabaseCare in contrast assures that your patching regime is seamless and consistent. It saves you time and leads to significantly improved security and it’s easy to set up too. In other words, DatabaseCare delivers the breakthrough companies need to ensure consistent database security.

Stay in the Loop