Personal blog of Yzmir Ramirez

Percona announces the release of Percona Server 5.6.33-79.0 on October 18th, 2016. Download the latest version from the Percona web site or the Percona Software Repositories.

Based on MySQL 5.6.33, including all the bug fixes in it, Percona Server 5.6.33-79.0 is the current GA release in the Percona Server 5.6 series. Percona Server is open-source and free – this is the latest release of our enhanced, drop-in replacement for MySQL. Complete details of this release are available in the 5.6.33-79.0 milestone on Launchpad.

New Features:

• Percona Server has implemented support for per-column VARCHAR/BLOB compression for the XtraDB storage engine. This also features compression dictionary support, to improve compression ratio for relatively short individual rows, such as JSON data.
• A new TokuDB tokudb_dir_per_db option has been introduced to address two TokuDB shortcomings, the renaming of data files on table/index rename, and the ability to group data files together within a directory that represents a single database. This feature is disabled by default.

Bugs Fixed:

• After fixing bug #1540338, system table engine validation check is no longer skipped for tables that don’t have an explicit ENGINE clause in a CREATE TABLE statement. If MySQL upgrade statements are replicated, and slave does not have the MyISAM set as a default storage engine, then the CREATE TABLE mysql.server statement would attempt to create an InnoDB table and fail because mysql_system_tables.sql script omitted explicit engine setting for this table. Bug fixed #1600056.
• Audit Log Plugin malformed record could be written after audit_log_flush was set to ON in ASYNC and PERFORMANCE modes. Bug fixed #1613650.
• A race condition between HandlerSocket and server shutdown could lead to a server stall if shutdown was issued immediately after HandlerSocket startup. Bug fixed #1617198.
• HandlerSocket could access freed memory on startup. Bug fixed #1617998.
• Workloads with statements that take non-transactional locks (LOCK TABLES, global read lock, and similar) could have caused deadlocks when running under Thread Pool with high priority queue enabled and thread_pool_high_prio_mode set to transactions. Fixed by placing such statements into the high priority queue even with the above thread_pool_high_prio_mode setting. Bugs fixed #1619559 and #1374930.
• Fixed memory leaks in Audit Log Plugin. Bug fixed #1620152 (upstream #71759).
• Server could crash due to a glibc bug in handling short-lived detached threads. Bug fixed #1621012 (upstream #82886).
• QUERY_RESPONSE_TIME_READ and QUERY_RESPONSE_TIME_WRITE were returning QUERY_RESPONSE_TIME table data if accessed through a name that is not full uppercase. Bug fixed #1552428.
• Fixed memory leaks in HandlerSocket. Bug fixed #1617949.
• KILL QUERY was not behaving consistently and it would hang in some cases. Bug fixed #1621046 (upstream #45679).
• Cipher ECDHE-RSA-AES128-GCM-SHA256 was listed in the list of supported ciphers but it wasn’t supported. Bug fixed #1622034 (upstream #82935).
• Successful doublewrite recovery was showed as a warning in the error log. Bug fixed #1622985.
• Variable query_cache_type couldn’t be set to 0 if it was already set to that value. Bug fixed #1625501 (upstream #69396).
• LRU manager thread could run too long on a server shutdown, causing a server crash. Bug fixed #1626069.
• tokudb_default was not recognized by Percona Server as a valid row format. Bug fixed #1626206.
• InnoDB ANALYZE TABLE didn’t remove its table from the background statistics processing queue. Bug fixed #1626441 (upstream #71761).
• Upstream merge for #81657 to 5.6 was incorrect. Bug fixed #1626936 (upstream #83124).
• Fixed multi-threaded slave thread leaks that happened in case of thread create failure. Bug fixed #1619622 (upstream #82980).
• Shutdown waiting for a purge to complete was undiagnosed for the first minute. Bug fixed #1616785.
• Unnecessary InnoDB change buffer merge attempts are now skipped upon reading disk pages of non-applying types. Bug fixed #1618393 (upstream #75235).

Other bugs fixed: #1614439, #1614949, #1616392 (upstream #82798), #1624993 (#736), #1613647, #1626002 (upstream #83073), #904714, #1610102, #1610110, #1613663, #1613728, #1613986, #1614885, #1615959, #1615970, #1616333, #1616404, #1616768, #1617150, #1617216, #1617267, #1618478, #1618811, #1618819, #1619547, #1619572, #1620583, #1622449, #1622456, #1622977, #1623011, #1624992 (#1014), #1625176, #1625187, #1626500, #1628417, #964, and #735.

NOTE: If you haven’t already, make sure to add the new Debian/Ubuntu repository signing key.

Release notes for Percona Server 5.6.33-79.0 are available in the online documentation. Please report any bugs on the launchpad bug tracker.

Percona is glad to announce the release of Percona Server 5.6.17-66.0 on June 11, 2014. Downloads are available here and from the Percona Software Repositories.

Based on MySQL 5.6.17, including all the bug fixes in it, Percona Server 5.6.17-66.0 is the current GA release in the Percona Server 5.6 series. All of Percona’s software is open-source and free, all the details of the release can be found in the 5.6.17-66.0 milestone at Launchpad.

New Features:

• MySQL benchmarks (sql-bench directory in the MySQL distribution) has been made compatible with the TokuDB storage engine.
• Percona Server has ported MariaDB code enhancement for start transaction with consistent snapshot. This enhancement makes binary log positions consistent with InnoDB transaction snapshots.
• TokuDB Storage engine is now available as a separate package that can be installed along with the Percona Server 5.6.17-66.0. This feature is currently considered Release Candidate quality.
• Percona Server has implemented ability to clone a snapshot created by START TRANSACTION WITH CONSISTENT SNAPSHOT in another session.
• Percona Server 5.6 now includes HandlerSocket in addition to Percona Server 5.5.

Bugs Fixed:

• Fix for #1225189 introduced a regression in Percona Server 5.6.13-61.0 which could lead to an error when running mysql_install_db. Bug fixed #1314596.
• InnoDB could crash if workload contained writes to compressed tables. Bug fixed #1305364.
• GUI clients such as MySQL Workbench could not authenticate with a user defined with auth_pam_compat plugin. Bug fixed #1166938.
• Help in Percona Server 5.6 command line client was linking to Percona Server 5.1 manual. Bug fixed #1198775.
• InnoDB redo log resizing could crash when XtraDB changed page tracking was enabled. Bug fixed #1204072.
• Audit Log wasn’t parsing escape characters correctly in the OLD format. Bug fixed #1313696.
• Percona Server version was reported incorrectly in Debian/Ubuntu packages. Bug fixed #1319670.

Other bugs fixed: #1318537 (upstream #72615), #1318874, #1285618, #1272732, #1314568, #1271178, and #1323014.

Release notes for Percona Server 5.6.17-66.0 are available in our online documentation. Bugs can be reported on the launchpad bug tracker.

The post Percona Server 5.6.17-66.0 is now available appeared first on MySQL Performance Blog.

I’ve presented at two different venues about HandlerSocket recently and the number one question that always arises is:

Why hasn’t HandlerSocket become more popular than it is?

Considering how fast and awesome HandlerSocket is, it’s not seeing as rapid adoption as some might expect. I theorize that there are five reasons for this:

Bugs, Bugs, Bugs

Up until the beginning of the year, HandlerSocket had a couple of bugs that a lot of people considered deal-breakers, and it’s not widely known that these issues have been fixed.

• Write operations do not invalidate the query cache – Exactly what it sounds like, if you performed a write operation via HandlerSocket, you could potentially read stale data from the MySQL interface.
• No support for auto increment – Exactly as it sounds, you couldn’t have auto-incrementing columns get an auto increment value on insert.

Distribution

Lots of organizations simply use what is provided to them. This was the case with MyISAM in standard distributions of MySQL for the longest time; many people were on MyISAM simply because it was the default. Even today, many organizations using recent versions of MySQL 5.1 are not using the InnoDB plugin because it is not enabled by default! If people cannot be bothered to add a couple of lines to my.cnf to enable the InnoDB plugin, they certainly cannot be expected to build the HandlerSocket plugin from source.

This is being changed with Percona-Server. The HandlerSocket plugin is now included by default and it simply takes a couple of steps to set it up. Hopefully we’ll see HandlerSocket be included in other places in the MySQL community.

No releases

There are no real releases or release schedules that are easy to digest. There is active development, bugs are being fixed, and the documentation is improving, but that does not translate into people knowing that their bugs are fixed and there is new code available.

No popular use cases

This is sort of a chicken-and-egg problem where people need to see use cases or endorsements of well-known companies in order to adopt a technology. Generally speaking, engineers are more inclined to remember a use case for a particular technology when it is well documented.

Not enough benchmarks

Finally, the benchmarks are not thorough enough. Nobody has yet taken the time to show diverse workloads on a variety of data sets. The existing work has focused almost entirely on primary-key-select workloads because that is where HandlerSocket truly shines; but people still want to know how the rest of the functionality performs. Also, there is an inherent distrust of benchmarks when done only by parties who have an interest in the product; there needs to be a wide variety of benchmarks from an even wider variety of industries and companies.

Summary

Most of these “issues” will work themselves out naturally as HandlerSocket matures. More people will publish benchmarks and use cases. As companies upgrade their Percona-Server installations, HandlerSocket will become available and easily accessible to them. Finally, as the code matures and the community grows, we’ll see lots more third-party involvement with bug reports, feature requests, and patches. I see lots of interest in HandlerSocket and am tremendously optimistic about it’s future.

HandlerSocket has really generated a lot of interest because of the dual promises of ease-of-use and blazing-fast performance. The performance comes from eliminating CPU consumption. Akira Higuchi’s HandlerSocket presentation from a couple of months back had some really good profile results for libmysql versus libhsclient (starting at slide 15). Somebody in the audience at Percona Live asked about the profile results when using prepared statements and I’m just getting around to publishing the numbers now; I’ll reproduce the original numbers here, for reference:

– Parsing SQL is slow

– Most CPU time is spent inside InnoDB (this is great because there have been lots of InnoDB improvements & will continue to be)

– Parsing SQL is slow

– Still lots of time with SQL overhead (not parsing)

– Most of the time is in InnoDB & HandlerSocket

I won’t comment too much on this because they’re fairly self-explanatory. I’ve intentionally omitted any timing information because the point of these numbers are to indicate what HandlerSocket avoids doing when compared with standard SQL access. Next steps are to test with 5.5!

On March 29th, I’ll be giving a webinar whose title is “Understanding HandlerSocket – A NoSQL PlugIn For MySQL”. This is a continuation and extension of the talk I gave during the Percona Live Event in San Francisco back in February. We’ll ask, and answer, the following questions:

• What is HandlerSocket?
• Where does HandlerSocket fit in my application stack?
• Why would I want to use HandlerSocket?
• How do I use Handlersocket?

Description:

http://www.percona.com/webinars/2011-03-29-understanding-handlersocket-a-nosql-plugIn-for-mysql/

To register:

https://percona-events.webex.com/percona-events/onstage/g.php?t=a&d=666931904