Personal blog of Yzmir Ramirez

This blog is not intended to offer anything extraordinary; instead, consider it an anecdote, a lesson, or simply a proper way of doing things without the need to run a test when in doubt. That said, I must emphasize that, as always, testing everything before deploying to production is essential. Let’s dive into the story: […]

Historically, Percona has been providing our customers with enterprise-grade solutions for MySQL that meet the highest standards of compatibility and compliance. To follow this commitment, Percona now offers RHEL9-certified builds for the users of Percona software for MySQL. These builds have been rigorously tested and are available as rpm packages, ensuring seamless integration with your […]

At Percona, we have always prioritized database performance as a critical factor in selecting database technologies. Recently, we have observed a concerning trend in the community edition of MySQL, where performance appears to be declining across major releases, specifically MySQL versions 5.7, 8.0, and 8.4. If you’re interested in learning more about these observations, we […]

We’re excited to announce that both Percona Server for MySQL and Percona XtraBackup now support the ARM64 architecture on Red Hat Enterprise Linux (RHEL) 8/9 and Oracle Linux (OL) 8/9. The packages with the aarch64.rpm extension can be found on Percona Software Downloads. The aarch64.rpm file extension indicates that the RPM package is specifically built for the ARM64 architecture and intended […]

MySQL and MariaDB are two major open source database management systems that share a common codebase and history. MariaDB started as a MySQL fork in 2009 to provide an alternate database version following Oracle’s acquisition of MySQL.While MariaDB has many features and has grown in popularity among users seeking a more open and community-driven development […]

To be honest, the comparison between the two MySQL distributions is not something that excited me a lot. Mainly because from my MySQL memories, I knew that there is not a real difference between the two distributions when talking about the code base.To my knowledge the differences in the enterprise version are in the additional […]

In my previous article, Comparisons of Proxies for MySQL, I showed how MySQL Router was the lesser performing Proxy in the comparison. From that time to now, we had several MySQL releases and, of course, also some new MySQL Router ones.Most importantly, we also had MySQL Router going back to being a level 7 proxy […]

In this article, we will demonstrate how to achieve asynchronous replication automatic source failover when our replica is a Percona Server for MySQL (PS) and the source is a Percona XtraDB Cluster (PXC) cluster, using virtual IP (VIP) managed by Keepalived.

Let us consider our architecture below with async replication from PXC to Percona Server for MySQL:

PXC               PS-MySQL
==============    ==============
node1      +----> node4
node2      |       
node3 -----+

Our goal is to set node3 as the async replication primary source. Then, upon failure, VIP can move to node2 and then node1 when node2 also fails. Once node3 becomes available again, the virtual IP should come back to node3.

Why not use the below MySQL built-in functionality instead of Keepalived?

• Asynchronous Replication Connection Failover – Automatic source list 
  • Asynchronous_connection_failover_add_managed
    • managed_type: The type of managed service that the asynchronous connection failover mechanism must provide for this server. The only value currently accepted is GroupReplication.

• Automatic Asynchronous Replication Connection Failover
  • It stays connected to whatever host it was connected to, which will not work if PXC wsrep_local_state_comment is not in a “Synced” state like when we encountered this bug that it became an “inconsistent” state and the replica connected to it will not failover to other healthy PXC node. In this case PXC, clustercheck used by Keepalived can help us check the health of a node for proper failover.

Process

Assumptions:

• We already have a PXC cluster to PS async replication working with the below IPs:

| MySQL
Hostname | IP               | Node    | Remarks  | server_id
---------+------------------+---------+----------|-----
el9-171  | 192.168.122.171  | node1   | PXC      | 171
el9-172  | 192.168.122.172  | node2   | PXC      | 172
el9-173  | 192.168.122.173  | node3   | PXC      | 173
el9-174  | 192.168.122.174  | node4   | PS       | 174
         | 192.168.122.170  |         | VIP-PXC  |

• We already have PXC-Keepalived set-up shown above with VIP that we will dedicate for replication use. The setup guide is in the blog Using Keepalived for HA on top of Percona XtraDB Cluster.
• Replica user was granted privilege from any of the PXC nodes.

Prerequisites:

• Enable log_replica_updates on all PXC nodes to ensure that all the transactions from all nodes will be written to all nodes’ binary log, making anynode qualified to act as async replication source.
• GTID enables replication for automatic replication positioning and correct failover.

Steps:

1) Edit then verify the priority with the highest to lowest value from node3, node2, node1:

node1> egrep 'priority' /etc/keepalived/keepalived.conf
  priority 101

node2> egrep 'priority' /etc/keepalived/keepalived.conf
  priority 102

node3> egrep 'priority' /etc/keepalived/keepalived.conf
priority 103

Sample configuration from node1:

node1> cat /etc/keepalived/keepalived.conf
vrrp_script chk_pxc {
  script  "/usr/bin/clustercheck"
  interval  1
  user    mysql
}
vrrp_instance PXC_as_async_master {
  state           MASTER
  interface       ens2
  virtual_router_id 51
  priority        101
  nopreempt
  virtual_ipaddress {
      192.168.122.170
  }
  
  track_script {
      chk_pxc
  }
}

2) Restart Keepalived on all nodes and check the status.

shell> systemctl restart keepalived

Check:

node1> journalctl -u keepalived.service -b | egrep ' systemd[1]: Starting | systemd[1]: Stopping | Entering | VRRP_Script' | tail -1
Nov 13 03:23:01 el9-171 Keepalived_vrrp[966]: (PXC_as_async_master) Entering BACKUP STATE

node2> journalctl -u keepalived.service -b | egrep ' systemd[1]: Starting | systemd[1]: Stopping | Entering | VRRP_Script' | tail -1
Nov 13 03:23:03 el9-172 Keepalived_vrrp[966]: (PXC_as_async_master) Entering BACKUP STATE

node3> journalctl -u keepalived.service -b | egrep ' systemd[1]: Starting | systemd[1]: Stopping | Entering | VRRP_Script' | tail -1
Nov 13 03:23:03 el9-173 Keepalived_vrrp[963]: (PXC_as_async_master) Entering MASTER STATE

node3> ip addr show dev ens2 | grep 'inet '
inet 192.168.122.173/24 brd 192.168.122.255 scope global noprefixroute ens2
inet 192.168.122.170/32 scope global ens2

We can see that node3 is the PRIMARY with VIP while the rest are in the BACKUP state.

3) Simulate a running write application.

node1> (set -e; while true; do mysql db1 -e"INSERT INTO t(s) VALUES('a');" ; sleep 5; done)

4) Check the replica’s current state using the below bash function:

node4> f_replica_status(){
mysql -e'SHOW REPLICA STATUSG' | sed '/,$/N;s/n/ /' | egrep 'Source_Host|Source_Log_File|Replica_IO_Running|Replica_SQL_Running|Last_IO_Error:|Last_SQL_Error:|Auto_Position|_Gtid_Set|Source_Server_Id|Source_UUID|Seconds_Behind_Source|Exec_Source_Log_Pos|Read_Source_Log_Pos'
}

Check replica status:

node4> f_replica_status
                  Source_Host: 192.168.122.173
              Source_Log_File: s173.000036
          Read_Source_Log_Pos: 102117
        Relay_Source_Log_File: s173.000036
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
          Exec_Source_Log_Pos: 102117
        Seconds_Behind_Source: 0
                Last_IO_Error:
               Last_SQL_Error:
             Source_Server_Id: 173
                  Source_UUID: f81e1079-7f00-11ee-849e-525400146f98
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Retrieved_Gtid_Set: 3d67d519-77d3-11ee-bcf4-8f28664ab56b:53752-53859
            Executed_Gtid_Set: 3d67d519-77d3-11ee-bcf4-8f28664ab56b:1-53859, c2982ae6-882c-ee11-430b-70d799b54a94:1-2222
                Auto_Position: 1

5) Reconfigure the replica to use the VIP(192.168.122.170):

node4-mysql> STOP REPLICA;
node4-mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST = '192.168.122.170';
node4-mysql> START REPLICA;

6) Verify the replica. Source_Host is now set to VIP:

node4> f_replica_status
                  Source_Host: 192.168.122.170
              Source_Log_File: s173.000036
          Read_Source_Log_Pos: 107494
        Relay_Source_Log_File: s173.000036
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
          Exec_Source_Log_Pos: 107494
        Seconds_Behind_Source: 0
                Last_IO_Error:
               Last_SQL_Error:
             Source_Server_Id: 173
                  Source_UUID: f81e1079-7f00-11ee-849e-525400146f98
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Retrieved_Gtid_Set: 3d67d519-77d3-11ee-bcf4-8f28664ab56b:53875-53878
            Executed_Gtid_Set: 3d67d519-77d3-11ee-bcf4-8f28664ab56b:1-53878, c2982ae6-882c-ee11-430b-70d799b54a94:1-2222
                Auto_Position: 1

7) Test failover

7.1) Stop mysqld

node3> mysqladmin shutdown

7.2) Check the Keepalive state:

node1> journalctl -u keepalived.service -b | egrep ' systemd[1]: Starting | systemd[1]: Stopping | Entering | VRRP_Script' | tail -1
Nov 13 03:23:01 el9-171 Keepalived_vrrp[966]: (PXC_as_async_master) Entering BACKUP STATE

node2> journalctl -u keepalived.service -b | egrep ' systemd[1]: Starting | systemd[1]: Stopping | Entering | VRRP_Script' | tail -1
Nov 13 03:35:03 el9-172 Keepalived_vrrp[966]: (PXC_as_async_master) Entering MASTER STATE

node3> journalctl -u keepalived.service -b | egrep ' systemd[1]: Starting | systemd[1]: Stopping | Entering | VRRP_Script' | tail -1
Nov 13 03:35:02 el9-173 Keepalived_vrrp[963]: (PXC_as_async_master) Entering FAULT STATE

Node2 is the new PRIMARY while node3 changed to FAULT state.

7.3) Check the VIP transferred to node2:

node2> ip addr show dev ens2 | grep 'inet '
inet 192.168.122.172/24 brd 192.168.122.255 scope global noprefixroute ens2
inet 192.168.122.170/32 scope global ens2

7.4) Check the replica. You may have to wait for at least the value of SOURCE_CONNECT_RETRY, which is, by default, 60 seconds.

The Source_Server_Id, Source_Log_File, Relay_Source_Log_File, and Source_UUID have changed.

node4> f_replica_status
                  Source_Host: 192.168.122.170
              Source_Log_File: s172.000033
          Read_Source_Log_Pos: 198793
        Relay_Source_Log_File: s172.000033
           Replica_IO_Running: Yes
          Replica_SQL_Running: Yes
          Exec_Source_Log_Pos: 198793
        Seconds_Behind_Source: 0
                Last_IO_Error: 
               Last_SQL_Error: 
             Source_Server_Id: 172
                  Source_UUID: 6534a3eb-77d3-11ee-9870-52540028fd18
    Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
           Retrieved_Gtid_Set: 3d67d519-77d3-11ee-bcf4-8f28664ab56b:53875-53973
            Executed_Gtid_Set: 3d67d519-77d3-11ee-bcf4-8f28664ab56b:1-53973, c2982ae6-882c-ee11-430b-70d799b54a94:1-2222
                Auto_Position: 1

The replica now has a successful failover to the new source (node2).

When node3 comes back online again, the VIP will also move back to node3 since it has the highest Keepalived priority, making it the asynchronous replication source again.

Percona Distribution for MySQL is the most complete, stable, scalable, and secure open source MySQL solution available, delivering enterprise-grade database environments for your most critical business applications… and it’s free to use!

 

Try Percona Distribution for MySQL today!

Sometimes, there is a need to update the table and index statistics manually using the ANALYZE TABLE command. Without going further into the reasons for such a need, I wanted to refresh this subject in terms of overhead related to running the command on production systems. However, the overhead discussed here is unrelated to the usual cost of diving into table rows to gather statistics, which we can control by setting the number of sample pages. 

Five years ago, my colleague Sveta posted a nice blog post about an improvement introduced in Percona Server for MySQL to address unnecessary stalls related to running the command:

ANALYZE TABLE Is No Longer a Blocking Operation

Historically, the problem with running the ANALYZE TABLE command in MySQL was that the query needed an exclusive lock on the table definition cache entry for the table. This makes the query wait for any long-running queries to finish but also can trigger cascading waiting for other incoming requests. In short, ANALYZE could lead to nasty stalls in busy production environments.

A lot has changed since then, but many production systems alive today still run with affected versions. Let’s recap how the situation has evolved over the years. 

MySQL Server – Community Edition

The problem applies to all versions of the upstream MySQL Community up to 8.0.23. There were no improvements in the 5.7 series (btw, EOL will be reached this month!), which means even the latest 5.7.43 is affected. Here is an example scenario you may end up here:

mysql > select @@version,@@version_comment;
+-----------+------------------------------+
| @@version | @@version_comment            |
+-----------+------------------------------+
| 5.7.43    | MySQL Community Server (GPL) |
+-----------+------------------------------+
1 row in set (0.00 sec)

mysql > show processlist;
+----+----------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------+
| Id | User     | Host      | db   | Command | Time | State                   | Info                                                           |
+----+----------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------+
|  4 | msandbox | localhost | db1  | Query   |   54 | Sending data            | select avg(k) from sbtest1 where pad not like '%f%' group by c |
| 13 | msandbox | localhost | db1  | Query   |   29 | Waiting for table flush | analyze table sbtest1                                          |
| 17 | msandbox | localhost | db1  | Query   |    0 | starting                | show processlist                                               |
| 18 | msandbox | localhost | db1  | Query   |   15 | Waiting for table flush | select * from sbtest1 where id=100                             |
+----+----------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------+
4 rows in set (0.00 sec)

One long query made the ANALYZE wait, but another, normally very fast query, is now waiting, too.

The same situation may happen in MySQL 8.0 series, including 8.0.23. Fortunately, there was a fix in version 8.0.24 addressing this problem. We can only read a bit restrained comment in the release notes about the “wait eliminated”:

https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-24.html

Indeed, since version 8.0.24, a similar test during a long-running query results in instant query execution:

mysql > select @@version,@@version_comment;
+-----------+------------------------------+
| @@version | @@version_comment            |
+-----------+------------------------------+
| 8.0.24    | MySQL Community Server - GPL |
+-----------+------------------------------+
1 row in set (0.00 sec)

mysql > analyze table sbtest1;
+-------------+---------+----------+----------+
| Table       | Op      | Msg_type | Msg_text |
+-------------+---------+----------+----------+
| db1.sbtest1 | analyze | status   | OK       |
+-------------+---------+----------+----------+
1 row in set (0.00 sec)

However, we can still find a warning in the official documentation, even for the 8.1 version, like this:

ANALYZE TABLE removes the table from the table definition cache, which requires a flush lock. If there are long running statements or transactions still using the table, subsequent statements and transactions must wait for those operations to finish before the flush lock is released. Because ANALYZE TABLE itself typically finishes quickly, it may not be apparent that delayed transactions or statements involving the same table are due to the remaining flush lock.

I requested an update of the related bug report as well as the documentation problem accordingly:

https://bugs.mysql.com/bug.php?id=87065
https://bugs.mysql.com/bug.php?id=112670

Percona Server for MySQL

As mentioned above, Percona introduced a fix and removed unnecessary table definition cache lock as a result of solving this bug report:

https://jira.percona.com/browse/PS-2503

When using the Percona variant, running ANALYZE TABLE was safe already since versions 5.6.38 and 5.7.20, as these were the active development series at the time. You may read the announcement in the release notes here:

https://docs.percona.com/percona-server/5.7/release-notes/Percona-Server-5.7.20-18.html#bugs-fixed

Percona Server for MySQL version 8.0 has been free from the issue since the very first release (I tested back, including the first GA release 8.0.13-3), as the improvement was merged from the Percona Server for MySQL 5.7 series.

MariaDB server

The locking ANALYZE TABLE problem applies to all MariaDB versions up to 10.5.3. In version 10.5.4, the solution from Percona was implemented as described in the following report:
https://jira.mariadb.org/browse/MDEV-15101

Therefore, when you run the query in 10.5.3 or lower, and in any previous series, like even the latest 10.4.31, a similar situation may occur:

mysql > select @@version,@@version_comment;
+----------------+-------------------+
| @@version      | @@version_comment |
+----------------+-------------------+
| 10.5.3-MariaDB | MariaDB Server    |
+----------------+-------------------+
1 row in set (0.000 sec)

mysql > show processlist;
+----+----------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------+----------+
| Id | User     | Host      | db   | Command | Time | State                   | Info                                                           | Progress |
+----+----------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------+----------+
|  4 | msandbox | localhost | db1  | Query   |   18 | Sending data            | select avg(k) from sbtest1 where pad not like '%f%' group by c |    0.000 |
| 13 | msandbox | localhost | db1  | Query   |   16 | Waiting for table flush | analyze table sbtest1                                          |    0.000 |
| 14 | msandbox | localhost | db1  | Query   |   14 | Waiting for table flush | select * from sbtest1 where id=100                             |    0.000 |
| 15 | msandbox | localhost | NULL | Query   |    0 | starting                | show processlist                                               |    0.000 |
+----+----------+-----------+------+---------+------+-------------------------+----------------------------------------------------------------+----------+
4 rows in set (0.000 sec)

mysql > select @@version,@@version_comment;
+-----------------+-------------------+
| @@version       | @@version_comment |
+-----------------+-------------------+
| 10.4.31-MariaDB | MariaDB Server    |
+-----------------+-------------------+
1 row in set (0.000 sec)

mysql > show processlist;
+----+-------------+-----------+------+---------+------+--------------------------+----------------------------------------------------------------+----------+
| Id | User        | Host      | db   | Command | Time | State                    | Info                                                           | Progress |
+----+-------------+-----------+------+---------+------+--------------------------+----------------------------------------------------------------+----------+
|  1 | system user |           | NULL | Daemon  | NULL | InnoDB purge coordinator | NULL                                                           |    0.000 |
|  2 | system user |           | NULL | Daemon  | NULL | InnoDB purge worker      | NULL                                                           |    0.000 |
|  3 | system user |           | NULL | Daemon  | NULL | InnoDB purge worker      | NULL                                                           |    0.000 |
|  4 | system user |           | NULL | Daemon  | NULL | InnoDB purge worker      | NULL                                                           |    0.000 |
|  5 | system user |           | NULL | Daemon  | NULL | InnoDB shutdown handler  | NULL                                                           |    0.000 |
|  9 | msandbox    | localhost | db1  | Query   |   18 | Sending data             | select avg(k) from sbtest1 where pad not like '%f%' group by c |    0.000 |
| 18 | msandbox    | localhost | db1  | Query   |   16 | Waiting for table flush  | analyze table sbtest1                                          |    0.000 |
| 19 | msandbox    | localhost | db1  | Query   |   12 | Waiting for table flush  | select * from sbtest1 where id=100                             |    0.000 |
| 22 | msandbox    | localhost | NULL | Query   |    0 | Init                     | show processlist                                               |    0.000 |
+----+-------------+-----------+------+---------+------+--------------------------+----------------------------------------------------------------+----------+
9 rows in set (0.000 sec)

Summary

As long as your database runs on the most recent version of MySQL or MariaDB variant, running ANALYZE TABLE should be absolutely safe and not cause any unexpected stalls.

Users of all three major Percona Server for MySQL series – 5.6.38+, 5.7.20+, and 8.0.x are all safe.

When, for any reason, you are not able to upgrade the community variant to the latest MySQL 8.0.24+ version yet and have to stick with 5.6 or 5.7 series for now, you may just swap MySQL Community binaries to Percona Server for MySQL ones, which are 100% compatible yet free from the problem. At the same time, you may check our post-EOL support for Percona Server for MySQL 5.7.

MariaDB users must upgrade to 10.5.4 or later to avoid the locking problem.

Percona Distribution for MySQL is the most complete, stable, scalable, and secure open source MySQL solution available, delivering enterprise-grade database environments for your most critical business applications… and it’s free to use!

 

Try Percona Distribution for MySQL today!

In this blog post, we will look at the lifecycle and release management for MySQL and MariaDB servers —  where we are now and relevant historical background.

It is worth noting both MySQL and MariaDB have Community and Enterprise versions.  For MySQL, both releases are made by the same company (Oracle), follow the same version numbering, and the Enterprise version is a superset of what is available in Community. For MariaDB, the Community version is provided by MariaDB Foundation, while Enterprise is provided by MariaDB PLC, following its own lifecycle, and has a different feature set. To keep things simple, we will focus our attention on the Community versions. 

MariaDB

As you probably are well aware, MariaDB started as a MySQL fork, and in the early days, things were rather similar. Things were starting to significantly diverge back in 2014 when MariaDB 10 was released.   This was a departure from matching MySQL versions, as was happening with MySQL 5.1 and MySQL 5.5.

Getting its own versions tracked allowed MariaDB to innovate at its own (faster) pace without confusing users who, because of shared roots, expected some kind of compatibility for MySQL and MariaDB of the same version. (It is worth noting that MariaDB 5.2 and MariaDB 5.3 existed, too, while there were no matching MySQL versions.)

MariaDB started to move fast. MariaDB 10.1 was released the next year in 2015, and MariaDB 10.2 in 2017; after that, major releases came every one to two years, with MariaDB 10.6 released in 2021. This fast pace of development, however, was combined with long-term support of five years for all releases, which meant many releases to maintain created an undue burden for the engineering team.

To address this burden, the new Innovation Release Model launched at the end of 2021, similar to how Ubuntu Linux is developed — quarterly releases are maintained for one year only while there are select long-term support releases, which are to be supported for at least five years as before.  Short-term and long-term support releases follow the same version pattern, and you really need to know which is which.

Additionally, MariaDB recently changed the leading version from 10 to 11. As Kaj Arno explains, expensive changes to Optimizer and its cost model are the main reason for this change.

The MariaDB 11 series did not yet have any long-term supported (LTS) releases,  which are the releases most would consider for running mission-critical databases in production. The latest long-term support (LTS) release is MariaDB 10.11, to be supported until February 2028.

MySQL

Under Oracle’s leadership, at first, MySQL continued to be following the lifecycle it had followed for a while. Every couple of years, there would be feature releases, and then there would be binary-compatible “bugfix only” minor releases. This was the case for MySQL 5.5, MySQL 5.6, and MySQL 5.7.

This release cycle had the benefit of stability; minor release upgrades were rather low risk, and if you needed to roll back, you could do it by quickly swapping out the binary without needing to do anything to your data. As with everything, though, there are tradeoffs — and the downside of this approach was the slow rollout of new features and big changes between major releases, making upgrades potentially messy and time-consuming.

With MySQL 8, this approach has drastically changed.  MySQL 8 became what seemed like a “forever release.”  While the initial GA release came out in April 2018, we have not seen a new major release for five years!  This does not mean there’s no innovation in MySQL 8; on the contrary, MySQL 8 now is very different from the one released back in 2018 because, in every minor release, new features were introduced together with bug fixes.

If you are someone who loves getting new features faster, you would love this new approach. In theory, this also means less risk with those “feature releases” upgrades, which contained a few months of development work as compared to years of work for major releases in the past. This is not how things work out in practice, though, as some of the releases contained new features with bugs critical enough to warrant release recalls.  What is worse, MySQL 8 also maintained only roll-forward binary compatibility, so once you upgrade to the new MySQL version, there is no guarantee the previous version will be able to operate on the same data.

It took a while, but the MySQL team recognized the MySQL 8 approach is not something you just need to get used to but rather something which does not work for some database environments; so moving forward, the New Release Model is introduced.  This model introduces “Innovation Releases,” which are released approximately quarterly and where only the latest Innovation Release is supported (i.e., any bug fixes will be rolled with new features and rolled out as the next innovation release, similarly to how MySQL 8.0 operates now). Another kind of release will be Long Term Supported (LTS) Releases, which will come out every couple of years and will be supported by Oracle for eight years (five Standard + three Extended).

MySQL LTS Releases will operate similarly to how MySQL operated before MySQL 8. The Innovation Releases are somewhat similar to the “milestone releases” the MySQL team used at some point, but where Milestone Releases were not considered “Production Ready” and were intended for Development and Preview,  Innovation Releases are considered “production-grade quality.”

MySQL 8.0 has a special place in this release model. Currently, it is basically an Innovation Style release, but with MySQL 8.0.34, it will become an LTS Release getting bug fixes only.

Differences between MySQL and MariaDB approaches

It is interesting to see both communities seem to have come to the understanding we need both a high pace of innovation AND stability.  You also can’t really have it both ways in the same release series.  You also need to keep support and maintenance costs under control; hence, you can’t have too many actively-supported releases.

Both MariaDB and MySQL came to the conclusion they need LTS versions and releases which focus on the speed of Innovation at the same time.

The cadence of LTS Releases is likely to be similar between MySQL and MariaDB, too.  MySQL expects LTS Releases to come out approximately every two years,  which is similar to MariaDB “at least every other year.” The difference is that MariaDB also collaborates with major Linux distributions to align MariaDB LTS releases to Linux Distribution LTS release plans, while MySQL did not state any such goals.

Where a difference exists is how Non-LTS Releases are approached. Where MariaDB goes the “Short Term Support” route when there are “bugfix only” releases for a limited time, MySQL chooses a path of supported rolling Innovation releases where bug fixes are included only with the latest Innovation release.  It will be interesting to see how those choices work out — the MariaDB approach is more “user friendly” as it gives users more control over when to upgrade to the next feature release, whereas the MySQL approach reduces the effort needed to support releases.

Another important difference is what kind of upgrades are supported. Where MySQL supports upgrades to the next major version only (i.e., you can’t upgrade from MySQL 5.6 to MySQL 8 directly), MariaDB supports skipping major versions in an upgrade.

Percona plans

As you read this on the Percona Blog, you may be interested in Percona’s plan for Percona Server for MySQL regarding announced changes.  The short answer is that we will follow the newly announced Innovation Release model and will produce LTS and Innovation releases, too. For more details, check out the blog post, LTS and Innovation Releases for Percona Server for MySQL.

Percona Distribution for MySQL is the most complete, stable, scalable, and secure open source MySQL solution available, delivering enterprise-grade database environments for your most critical business applications… and it’s free to use!

 

Try Percona Distribution for MySQL today!