I was playing with Percona Server today and found fast_index_creation does not work quite exactly like described in the manual. The point I’m looking to make though it would be very hard to catch this problem without additional
information_schema tables we added in Percona Server.
I have a customer who is considering Percona XtraDB Cluster (PXC) in a two colo WAN environment. They wanted me to do a test comparing PXC against semi-synchronous replication to see how they stack up against each other.
The test environment included AWS EC2 nodes in US-East and US-West (Oregon). The ping RTT latency between these nodes was right around 100ms.
The Percona Toolkit team is happy to announce the release of Percona Toolkit versions 2.0.5 and 2.1.2. These are bug-fix releases in the 2.0 and 2.1 series, respectively. These releases fix many dozens of bugs, and we suggest that users upgrade to the latest versions of the tools.
I know about it, I knew about it all along, but... it's so easy to fall for it; there's just so much absurdity!
A CHAR type has a known number of characters. For example, the column:
CountryCode CHAR(3) CHARSET ascii NOT NULL
- is known to have exactly three characters. These could be 'USA', 'FRA', etc.
Many of you heard of this nasty security vulnerability in MySQL, and as we are getting a lot of inquiries how does it affect Percona Server, I decided to address it in this post.
As a tool author, I really look forward to working with MySQL 5.6. Many of the improvements will make life significantly easier for Percona Toolkit.
One illustration of this is in figuring out what the optimizer is doing when it plans a statement, and how it intends to use indexes. Compound indexes present challenges in some situations. Many of our tools have extensive checks to try to avoid executing queries that have bad execution plans. If the optimizer intends to use only a few of the columns in an index, how will we know?
“In short, if you try to authenticate to a MySQL server affected by this flaw, there is a chance it will accept your password even if the wrong one was supplied. The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password.”
$ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done mysql>
The following are confirmed distributions that are vulnerable:
Since the new MySQL Pacemaker resource agent supporting PRM is now included in version 3.9.3 of the official Pacemaker resource agents package and things have stabilized a bit, I have been able to write some documentation. I wrote a first draft of the PRM documentation that is likely far from perfect, but I hope it will be useful and improve rapidly. The PRM documentation is available here.