Percona announces the release of Percona Server 5.5.51-38.1 on August 19, 2016. Based on MySQL 5.5.51, including all the bug fixes in it, Percona Server 5.5.51-38.1 is now the current stable release in the 5.5 series.
Percona Server is open-source and free. You can find release details of the release in the 5.5.51-38.1 milestone on Launchpad. Downloads are available here and from the Percona Software Repositories.
DROP DATABASE would fail to delete some of the tables in the database, the partially-executed command is logged in the binlog as DROP TABLE t1, t2, ... for the tables for which drop succeeded. A slave might fail to replicate such DROP TABLE statement if there exist foreign key relationships to any of the dropped tables and the slave has a different schema from the master. Fixed by checking, on the master, whether any of the database to be dropped tables participate in a Foreign Key relationship, and fail the DROP DATABASE statement immediately. Bug fixed #1525407 (upstream #79610).
-DMYSQL_MAINTAINER_MODE=ON option. Bug fixed #1590454.
EINTR received during network I/O was not handled correctly. Bug fixed #1591202 (upstream #82019).
.gitignore in the percona-server source distribution had a line *.spec, which means someone trying to check in a copy of the percona-server source would be missing the spec file required to build the RPM packages. Bug fixed #1600051.
innodb_fast_shutdown set to 0) could result in an incomplete purge, if a separate purge thread is running (which is a default in Percona Server). Bug fixed #1609364.
ld_preload libraries can now only be loaded from the system directories (/usr/lib64, /usr/lib) and the MySQL installation base directory.#1515591 (upstream #79249), #1612551, #1609523, #756387, #1097870, #1603073, #1606478, #1606572, #1606782, #1607224, #1607359, #1607606, #1607607, #1607671, #1608385, #1608424, #1608437, #1608515, #1608845, #1609422, #1610858, #1612084, #1612118, and #1613641.
Find the release notes for Percona Server 5.5.51-38.1 in our online documentation. Report bugs on the launchpad bug tracker.
This new release instantly refused to start with malloc-lib set to jemalloc, while the previous versions worked as expected. What changed? No errors were being logged, and the log file itself wasn’t even being opened. This caused us an extended service outage which could have been avoided.
Hi,
For security reasons ld_preload libraries can now only be loaded from system directories. It looks like this change was omitted from the change log and this announcement.
Hello,
Thanks for the update! When you say system directories, are there any in particular? For example jemalloc was being loaded using:
malloc-lib=’/usr/local/lib/libjemalloc.so’
However, this technically is a “system directory”.
To answer my own question. The only dirs which work to ld_preload are:
/usr/lib
/usr/lib64
I also want to mention that symlinks pointing outside of these lib dirs can be used as it doesn’t seem they’re being dereferenced. For example, I now have malloc-lib=’/usr/lib64/libjemalloc.so’, where /usr/lib64/libjemalloc.so is a symlink to /usr/local/lib/libjemalloc.so, which is also a symlink to /usr/local/lib/libjemalloc.so.2. The MySQL service however, clearly shows it loaded:
mysqld 12853 mysql mem REG 9,0 292817 3530336 /usr/local/lib/libjemalloc.so.2
However, I would expect the following to all work if used, and not just the two /usr/lib’s from above:
/usr/local/lib
/usr/local/lib64
/lib
/lib64
Thanks for reporting this, I’ll need to check the suggestion about adding the /usr/local/ as the original recommendation came from our security team.