A while back, I wrote a blog post explaining how PERFORMANCE_SCHEMA
improvements in MySQL Server 5.7 provides new visibility into the SSL/TLS status of each running client configuration. An excellent recent post from Frederic Descamps at Percona covers similar territory. Both of us use PERFORMANCE_SCHEMA
tables directly – a powerful interface, but one that requires a query joining multiple tables. Thanks to the excellent work of Mark Leith, and a contribution from Daniël van Eeden, access to this same information is made far easier via the SYS
schema. Continue reading SYS Schema: Simplified Access To SSL/TLS Details
Tag Archives: performance_schema
Practical P_S: Find Client JRE Version Using SQL
MySQL Connector/Java supports connection attributes since version 5.1.25. This projects useful metadata about the client environment into the database, where MySQL administrators can query PERFORMANCE_SCHEMA tables to remotely survey application deployment environments. One useful piece of information exposed is the version and vendor of the JVM in use by the client. This very short blog demonstrates how to get this information from PERFORMANCE_SCHEMA.
Continue reading Practical P_S: Find Client JRE Version Using SQL
Practical P_S: Which TLS ciphers are connections using?
As noted in an earlier post, MySQL Server 5.7 prefers and enables SSL/TLS connections by default. That’s great and useful progress towards secure connections, but we know that not all SSL/TLS ciphers are created equal – some are older and more vulnerable. Furthermore, some recent vulnerabilities rely on the ability to negotiate less-secure ciphers during the handshake. Monitoring which ciphers are used can help identify connections using low-grade ciphers, but also to build an appropriate restricted cipher list. Using improvements to PERFORMANCE_SCHEMA
introduced in 5.7, you can now easily do this – and this post will show you how.
Continue reading Practical P_S: Which TLS ciphers are connections using?
SF MySQL Meetup Presentation: Changes in MySQL 5.7
Last Wednesday, I spoke at the San Francisco MySQL Meetup on the topic of changes coming in MySQL 5.7 (and later). We actually went through two different slide decks; the first on features being considered for deprecation in MySQL 5.7 (or later), and the second set providing a brief overview of the new features and benefits already introduced in MySQL 5.7 via the development milestone releases (DMRs) published to date. A big thanks to the entire SF Meetup group, and in particular the organizers (Erin, Mike and Darren), for having me. The event was streamed and recorded, and you can view the full presentation on YouTube. The slide deck can be found here.
The discussion around proposed deprecation was good, and this blog serves to document my own notes about what was said – giving others an opportunity to provide additional feedback. Feel free to comment either to reinforce or offer alternative perspectives on the feedback noted. There’s also some post-presentation clarification mixed in:
Continue reading SF MySQL Meetup Presentation: Changes in MySQL 5.7
Understanding max_connect_errors
To only slightly misquote one of the greatest movies of all times:
You keep using that option. I do not think it means what you think it means.
Perhaps like many users, I had certain assumptions about what max_connect_errors really does – but in looking closely as part of investigating the new PERFORMANCE_SCHEMA.HOST_CACHE table in MySQL 5.6, I learned that some very fundamental elements had escaped my notice. I’m writing this blog post to help others who hold similar misconceptions of what this option does.
MySQL 5.6 users – prevent host blocked errors
The much-improved PERFORMANCE_SCHEMA in MySQL 5.6 provides visibility into MySQL’s host cache, including the ability to monitor for impending blocked hosts. You can do this with the following query:
mysql> SELECT -> ip, -> host, -> host_validated, -> sum_connect_errors -> FROM performance_schema.host_cache\G *************************** 1. row *************************** ip: 192.168.2.4 host: TFARMER-MYSQL.wh.oracle.com host_validated: YES sum_connect_errors: 3 1 row in set (0.02 sec)
That’s helpful information, and allows DBAs to identify problematic hosts before they are blocked. Due to Bug#69807, it’s also something MySQL 5.6 users will want to do. This bug causes the counter maintained in the host cache for failed connections – against which max_connect_errors is compared – to never be reset by a valid connection. The end result is that over time, hosts may reach the max_connect_errors threshold and be blocked.
Continue reading MySQL 5.6 users – prevent host blocked errors
Spring Cleaning: Useless protocol commands
In an earlier post, I commented on clients and utility programs which seem to no longer be useful, and opened (or referenced existing) public bug reports to deprecate and remove, where appropriate. That effort came actually was the product of a different initiative: I was looking for clients which might leverage the full spectrum of MySQL protocol commands in an effort to understand whether certain protocol commands are in use. I thought I would share my observations, in the hope that we might also get feedback from others regarding usage of these commands. And even though it’s no longer spring (I started this post in April), I finally found time to finish this post.
Continue reading Spring Cleaning: Useless protocol commands
Practical P_S: Fixing gaps in GLOBAL STATUS
Over three years ago, I noticed that there was no STATUS counter for COM_PING commands – something that is useful for ensuring proper configuration of JDBC connection pools. Mark Leith even provided a patch, but it’s never been incorporated. With the advances PERFORMANCE_SCHEMA makes in MySQL 5.6, that’s OK – a STATUS counter becomes somewhat redundant:
mysql> SELECT SUM(count_star) as pings -> FROM events_statements_summary_global_by_event_name -> WHERE event_name = 'statement/com/Ping'; +-------+ | pings | +-------+ | 12 | +-------+ 1 row in set (0.02 sec)
Continue reading Practical P_S: Fixing gaps in GLOBAL STATUS
Practical P_S: How idle are your connections?
Idle connections can cause problems both at the application side, increasing the risk of connection timeouts for applications where persistent connections are used, and the server side, where resources remain allocated to idle connections. Any application with persistent connections, such as a JDBC application using a connection pool, will have periods where connections are idle – but it’s good to know how much time is spent idle. Too much idle time might mean connections pools configured to allow too many connections to sit idle in a connection pool, or not properly doing connection pool maintenance.
PERFORMANCE_SCHEMA in MySQL 5.6 makes it trivial to measure absolute time spent waiting. This will show total, average and maximum idle times by account:
Continue reading Practical P_S: How idle are your connections?
Practical P_S: How old are your connections?
I’ve often wished that PROCESSLIST exposed when a connection was first established, and I find myself wishing for this information more now with MySQL 5.6. Improvements to PERFORMANCE_SCHEMA make it trivial to see how much time is being spent in various operations for a given connection – but it would make some analysis (“what percentage of connection time is spent doing X?”) easier.
That said, it is possible to approximate connection age with PERFORMANCE_SCHEMA in MySQL 5.6. I say “approximate” because results will vary based on what instrumentation exists, is enabled, and is collecting timing data. That’s because we’re just doing a SUM() on the SUM_TIMER_WAIT column for all instrumented waits. Here’s an example (FYI, I’m using the format_time() function from Mark Leith’s awesome ps_helper scripts to convert from picoseconds to something meaningful to me):
Continue reading Practical P_S: How old are your connections?