Percona Server 5.6.33-79.0 is now available

percona server 5.6.33-79.0

percona server 5.6.33-79.0Percona 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 Server 5.6.17-66.0 is now available


Percona ServerPercona 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.


What’s up with HandlerSocket?

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.


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.


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.


Where does HandlerSocket really save you time?

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:

libmysql (Akira’s Numbers)
samples % symbol name
748022 7.7355 MYSQLParse(void*)
219702 2.2720 my_pthread_fastmutex_lock
205606 2.1262 make_join_statistics(…)
198234 2.0500 btr_search_guess_on_hash
180731 1.8690 JOIN::optimize()
177120 1.8317 row_search_for_mysql
171185 1.7703 lex_one_token(void*,void*)
162683 1.6824 alloc_root
131823 1.3632 read_view_open_now
122795 1.2699 mysql_select(…)

– Parsing SQL is slow

HandlerSocket (Akira’s Numbers)
samples % symbol name
119684 14.7394 btr_search_guess_on_hash
58202 7.1678 row_search_for_mysql
46946 5.7815 mutex_delay
38617 4.7558 my_pthread_fastmutex_lock
37707 4.6437 buf_page_get_known_nowait
36528 4.4985 rec_get_offsets_func
34625 4.2642 build_template(…)
20024 2.4660 row_sel_store_mysql_rec
19347 2.3826 btr_cur_search_to_nth_level
16701 2.0568 row_sel_convert_mysql_key_to_innobase

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

libmysql (5.1.56)
samples % symbol name
57390 2.4548 MYSQLparse(void*)
42091 1.8004 String::copy(…)
32543 1.3920 __read_nocancel
30536 1.3062 btr_search_guess_on_hash
24630 1.0535 my_wc_mb_latin1
24407 1.0440 memcpy
23911 1.0228 MYSQLlex(void*, void*)
22392 0.9578 pthread_mutex_lock
21973 0.9399 fcntl
20529 0.8781 my_utf8_uni

– Parsing SQL is slow

libmysql w/ prepared statements (5.1.56)
samples % symbol name
18054 4.1415 String::copy(…)
14223 3.2627 make_join_statistics(…)
11934 2.7376 JOIN::optimize()
10140 2.3261 my_wc_mb_latin1
7152 1.6407 my_utf8_uni
7092 1.6269 Protocol::send_fields(List*, unsigned int)
6530 1.4980 JOIN::prepare(…)
6175 1.4165 Protocol::store_string_aux(…)
5748 1.3186 create_ref_for_key(…)
5325 1.2215 mysql_execute_command(THD*)

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

HandlerSocket (5.1.56)
samples % symbol name
18946 2.9918 btr_search_guess_on_hash
15853 2.5034 vfprintf
8745 1.3810 row_search_for_mysql
7021 1.1087 buf_page_get_known_nowait
5212 0.8230 __find_specmb
5116 0.8079 dena::dbcontext::cmd_find_internal(…)
5100 0.8054 build_template(…)
4866 0.7684 _IO_default_xsputn
4794 0.7570 dena::hstcpsvr_worker::run_one_ep()
4538 0.7166 send

– 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!


Upcoming Webinar on HandlerSocket

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?



To register:


Powered by WordPress | Theme: Aeros 2.0 by TheBuckmaker.com