MariaDB Enterprise Server 10.6 is now available for our customers as part of MariaDB Enterprise. Besides new features, MariaDB Enterprise Server 10.6 continues in the path set out by previous Enterprise Server releases with a focus on quality, robustness and stability. Enterprise Server is MariaDB’s flagship technology and it is geared towards enterprise-grade workloads and must stand up to everything that can be thrown at it. Hence, it goes through extensive testing and QA to ensure that we can meet the requirements of the largest and most demanding environments. MariaDB Enterprise Server also has a predefined release schedule so that potential upgrades can be planned well ahead of time.
MariaDB Enterprise Server 10.6 has lots of exciting new features, and I will outline a few of the more exciting ones below. For a more detailed list, please look at our release notes.
This is a journey that started a long time ago. In MariaDB 10.3, we added a new SQL mode (
sql_mode=ORACLE) for compatibility with a subset of PL/SQL. Using
sql_mode=ORACLE lets customers migrate existing code without having to make changes to the procedures. With Enterprise Server 10.6, we add both improvements to Oracle compatibility as well as a new compatibility mode for Sybase SQL Anywhere:
- Oracle compatibility: With the 10.6 release, we added several new functions (such as
TO_CHAR()) that are commonly used, taking us another step further in allowing easy migrations and subsequent cost savings. We also continue to be the only database with open source Oracle compatibility features.
- SQL Anywhere extends the SQL/2008 Standard by allowing the use of an alias anywhere in the
SELECTblock. The new SQL mode called
EXTENDED_ALIASESallows similar alias use. With that mode, an alias can be used in a
SELECTlist. Aliases are forward resolved and an alias definition has priority over a column name. This should help with migrations from SQL Anywhere to MariaDB where the usage of this extension is widespread.
Improved semi-synch replication
MariaDB supports multiple ways of creating “clusters” of MariaDB Servers working together. Semi-synch replication is one of these technologies. Semi-synch replication gives guarantees that data changes when committed on the primary should always be replicated to at least one replica before a transaction is acknowledged as committed on the primary. However, prior to 10.6, a crashed primary could return to the cluster in a state not consistent with the rest of the cluster causing issues. This is no longer the case. In Enterprise Server 10.6 failed primaries that return to the cluster will be fully consistent with the rest of the cluster. This is a key advance in semi-sync replication technology that we’ve implemented in response to customer requests. This feature will also be backported to older release series of MariaDB Enterprise Server (10.5 etc) as this has been requested by several customers. More about that in the coming months.
Storage Engine Agnostic Atomic DDL
MariaDB supports a wide variety of storage engines for different workloads and purposes – InnoDB, ColumnStore, MyRocks, Aria and Spider. Having engine independent Atomic DDL is really complex and impacts the fundamentals of our code. What is Atomic DDL? There are many features that are storage engine dependent and depend on how data is stored and organized inside the engine. DDL operations (
CREATE INDEX etc.) are operations that can sometimes take a really long time (depending on the engine). Before 10.6, a crash during a DDL operation could lead to undetermined results – especially in replication setups where the information in the binary log needs to be consistent with what happens in the engine. In MariaDB Enterprise Server 10.6, we made DDL operations atomic and consistent with the binlog. This means that a DDL operation will always be either fully done or not done at all – even if the server crashes in the middle of the operation. This will be done independently of which storage engine you use, starting with Aria and InnoDB now, and adding support for our other storage engines soon. Furthermore, we now guarantee that the binary log will be consistent with whether the operation took place or not. This is a huge improvement over previous versions.
We started our journey of bringing structured and non-structured data together back in MariaDB 10.2 when we added our first set of JSON functions. Being able to combine the two by having tables with clear structure (with defined columns) but allowing rows to store unstructured data in JSON strings brings you the benefit of both worlds. With this release, we have taken a large step in bringing this full circle with the addition of JSON_TABLE which allows you to create table-like structures directly based on JSON strings. This allows JSON strings to be used in any part of a SQL statement where a table could be used – in the
FROM clause, in CTEs, subqueries etc. We are very excited about this feature and expect it will prove productive in use.
In addition to the features discussed above, there are many new usability features, such as a SYS_SCHEMA, a new version of ColumnStore, and more. For information on all the new features in MariaDB Enterprise Server 10.6, take a look at the What’s New in MariaDB Enterprise Server 10.6.