After some final testing and polishing, the MariaDB project and Codership are pleased to announce the release of MariaDB Galera Cluster 5.5.29. This is a Stable (GA) release. MariaDB Galera Cluster links:
About MariaDB Galera Cluster
MariaDB Galera Cluster is made for today’s cloud based environments. It is fully read-write scalable, comes with synchronous replication, allows multi-master topologies, and guarantees no lag or lost transactions. Some of its features & benefits are listed below.
- Synchronous replication
- Active-active multi-master topology
- Read and write to any cluster node
- Automatic membership control, with failed nodes dropped from the cluster
- Automatic node joining
- True row-level parallel replication
- Direct client connections, native MariaDB/MySQL look & feel
The above features yield several benefits for a database clustering solution, including:
- No slave lag
- No lost transactions
- Both read and write scalability
- Smaller client latencies
MariaDB Galera Cluster uses the Galera library for the replication implementation. To interface with Galera replication, we have enhanced MariaDB to support the replication API definition in the Write Set REPlication (wsrep API) project. The implementation of the replication API in MariaDB happens in the open source MySQL-wsrep project.
User Feedback plugin
MariaDB Galera Cluster includes a User Feedback plugin. This plugin is disabled by default. If enabled, it submits basic, completely anonymous usage information. This information is used by the developers to track trends in usage to better guide development efforts. If you would like to help make MariaDB Galera Cluster better, please add “feedback=ON” to your my.cnf file! See the User Feedback Plugin page for more information.
The project always strives for quality, but in reality, nothing is perfect. Please take time to report any issues you encounter at: http://mariadb.org/jira. We hope you enjoy MariaDB Galera Cluster!
Once you run MariaDB Galera Cluster in production you want to make sure there is a helping hand available whenever needed. We’re happy to inform you that our partner SkySQL offers 24-hour support also for the MariaDB Galera Cluster, see SkySQL’s page about Galera Cluster.
The MariaDB Java Client 1.1.1 has been released. You can download it here.
See the Release Notes and Changelog for detailed information on this release and the About the MariaDB Java Client page in the AskMonty Knowledgebase for general information about the client.
New functionality in this release
- Implement tcpAbortiveClose option, for “hard” socket close (CONJ-27)
- This option can be used in environments where connections are created and closed in rapid succession. Often, it is not possible to create a socket in such environment after a while, since all local “ephemeral” ports are used up by TCP connections in TCP_WAIT state. Using tcpAbortiveClose works around this problem by resetting TCP connections rather (abortive or hard close) than doing an orderly close. It is accomplished by using socket.setSoLinger(true,0) for abortive close.
Bugs fixed in this release
- MySQLStatement will now indicate there are no more results by returning -1 from getUpdateCount() and null from getResultSet(),as mandated by the standard (CONJ-14)
- Introduced nullCatalogMeansCurrent parameter for compatibly with ConnectorJ, and make it default (CONJ-16)
- Prior to this change, DatabaseMetadata.getTables() or other methods of DatabaseMetaData that accept catalog names and return result sets would treat null as prescribed by the JDBC standard (null means no restriction which catalog is used). This behavior is now changed for the sake of compatibility. Starting with 1.1.1 , null for catalog name will mean current catalog. To get JDBC standard behavior, one needs to set nullCatalogMeansCurrent=false.
- DatabaseMedataData.getColumns() returned incorrect values in the “COLUMN_SIZE” column for character data.(CONJ-15))
- Prior to the change, octet size was returned (length in bytes). Depending on the character set used, it could be 3 times bigger than the length in characters that was specified by CREATE or ALTER table. This behavior is corrected in 1.1.1
- DatabaseMetaData.getColumns() always handled MySQL YEAR datatype as SMALLINT. (CONJ-19)
- The behavior is now fixed and getColumns returns either DATE or SMALLINT depending on how the ‘yearIsDateType’ parameter is set.
- ResultSetMetaData.getColumnName() returned an empty string in special cases (CONJ-17)
- ResultSetMetaData.getColumnName() returned and empty string for “non-columns” in a result set (functions, aggregates like count(*), and so on). The fix is to return the column label to be returned if the column name is empty.
- Ensure that getObject() returns byte array for CHAR BINARY.(CONJ-20)
- Also make sure that getColumnType(),getColumnClassName(),getColumnTypeName() return values indicate BINARY for fixed binary type.
- JVM does not exit if statement timeout is used.(CONJ-23)
- Constructor for Timer was corrected to ensure that the Timer thread has type background thread. Thus Timer won’t prevent JVM from exiting.
- Calling first() on “streaming” result set and using the result set afterwards generated NullPointerException (CONJ-24)
- Now a SQLException is thrown early on, in the first() call, since streaming results sets are not scrollable.
- Connection.close() hangs if there is an open streaming result set, and next() was not called on this result set (CONJ-25)
First, congratulations Oracle on the GA of MySQL 5.6! Well done!
In this post I walkthrough the features of the first two alpha versions of MariaDB 10.0. The first, 10.0.0-alpha, which was made available in November, and 10.0.1-alpha that saw daylight yesterday. I will go through the features by placing them in the following categories:
- MariaDB 10.0-only Features (features that aren’t in MySQL 5.6)
- MariaDB 10.0 Merged Features (features merged from MySQL 5.6)
- MariaDB 10.0 Reimplemented Features (features reimplemented from features in MySQL 5.6)
- MariaDB 5.x Features now in MySQL 5.6 (features introduced in earlier MariaDB versions which have now been introduced in MySQL 5.6)
- MariaDB 5.x Features Backported from MySQL 5.6 (features introduced in earlier MariaDB versions which were backports of features from MySQL 5.6 development versions)
Some of the features will have links to the MySQL manual for the documentation Oracle has made available on the feature.
MariaDB 10.0-only Features
Features in this section are unique to MariaDB 10.0 and aren’t found in MySQL 5.6.
Available since 10.0.0
- Multi-source replication (MDEV-253)
- Multi-source replication is a longtime wish of many users. In scenarios where you partition your data over many masters you can then replicate the data from all masters onto one slave. Typical use cases are:
- Data partitioned over many masters can be pulled together onto one slave for analytical queries
- Many masters can replicate to the same slave and a complete backup can be done on the slave
- Newer hardware usually provides more performance. Usually all hardware isn’t upgraded at once and multi-source can be used for replicating many masters to a powerful new slave.
- Original code from Taobao
- Even faster Group Commit
- Further enhancements have been made to group commit. A couple of blog posts about the improvements by the developer, Kristian Nielsen, can be found here.
- SHOW EXPLAIN
- Get the query plan of a running statement.
Now available in 10.0.1
- Cassandra Storage Engine
- An integration of the NoSQL database Apache Cassandra. Cassandra is seen as a storage engine to MariaDB. The integration enables:
- Combining data from Cassandra and MariaDB
- Reading and writing to Cassandra from MariaDB. SQL’s SELECT, INSERT, UPDATE and DELETE all work.
- Engine independent statistics
- Optimizer statistics is the collection of data that describe more details about the database and the objects in the database.
- Statistics are now provided separately from storage engines. Before, statistics were supplied by the storage engines themselves and the quality of the statistics were usually quite poor. Also, since before this they were provided through the storage engine interface, a lot of restrictions were put on them.
- These statistics are used by the query optimizer to choose the best execution plan for each SQL statement. Better statistics results in better execution plans and end users will experience faster results in general.
- Statistics are collected also for non-indexed columns. InnoDB’s statistics, for example, were previously only for indexes.
- Improved Dynamic Columns
- Dynamic Columns has been in MariaDB for a while already. This feature allows you to store a different set of columns for every row in a table. In that manner Dynamic Columns can be called NoSQL-like.
- Since MariaDB introduced Dynamic Columns there has been user feedback and research going on to improve it further. Dynamic Columns has some new capabilities that now are in mainline MariaDB:
- Database interoperability: It’s pretty rare that companies use only a single type of database and even critical business systems are often built on several different types of databases. Usually the data from those different databases is combined in an upper application level. MariaDB introduces the possibility of doing this at a low level inside the MariaDB database. The first implementation of this is integration with Cassandra. With Dynamic Columns and the Cassandra Storage Engine you can now combine data residing in Cassandra with data inside MariaDB and this is done through normal looking queries on the MariaDB side.
- Data interchange: JSON has become a very popular standard for data interchange. In Dynamic Columns one can now request a row in JSON format.
- Per thread memory usage (MDEV-4011)
- Based on a patch by Taobao, INFORMATION_SCHEMA and SHOW STATUS enables the analysis of thread specific memory usage
- Faster ALTER TABLE with UNIQUE key (MDEV-539)
- Significant speed up of ALTER TABLE with unique keys (for Aria and MyISAM storage engines)
MariaDB 10.0 Merged Features
Features listed in this category have been directly merged from MySQL 5.6.
Already available since MariaDB 10.0.0
- InnoDB and Performance Schema
- Most InnoDB enhancements, but some, for example InnoDB’s fulltext capabilities, will come in an upcoming version of 10.0.
MySQL Manual: InnoDB.
- The full new performance schema with all the new event filtering, instrumentation, and other goodies.
MySQL Manual: Performance Schema
- ORDER BY … LIMIT -optimization
- A useful optimization for showing only a few rows of a bigger resultset.
MySQL Manual:Limit Optimization
Now added in 10.0.1
- Plugin-load-add (MDEV-3860)
- Used to avoid specifying a large set of plugins in a single long argument
MariaDB 10.0 Reimplemented Features
These features are re-implementations of the corresponding functionality in MySQL 5.6. In future versions of MariaDB 10.0 there will be a few more features in this category. I’ll cover them in a future blog post.
- Add full support for auto-initialized/updated timestamp and datetime
MariaDB 5.x Features now in MySQL 5.6
Earlier MariaDB 5.x versions included features that have now been introduced in MySQL 5.6. It should be noted that the corresponding features in MySQL 5.6 haven’t been merged from MariaDB. Oracle has re-implemented them.
MariaDB 5.x Features Backported from MySQL 5.6
These features were merged from MySQL 5.6’s development trees to MariaDB, where they were then hardened for production use.
- Binlog checksums, were introduced in MariaDB 5.3. It is backport of the corresponding feature in MySQL 5.6.
As you can see above there are quite many features in MariaDB 10.0 already, but more is coming. Stay tuned for an update on features going into MariaDB 10.0.2.