Archive
Posts in Databases
Understanding MySQL performance data with mysqlreport
MySQL maintains numerous operational metrics (e.g., connections, questions, etc), which can be accessed by running 'show status' or one of it's variants from the mysql client. The mysqlreport Perl script can be used to summarize this data into a nicely formatted report with several useful performance metrics: The output from mysqlreport includes metrics on key cache and query cache utilization, the number of operations (SELECT, UPDATE, etc.) performed, thread utilization, connection volumes, table locks, and the types of temporary tables used by sorts. The folks over at hackmysql provide a nice writeup on what each report means, and the typical value ranges you should see in each report. Running mysqlreport is a great way to get a high-level understanding of how a database is performing, and can greatly assist with identifying the areas that are worth reviewing in greater detail.
$ read more →Securing MySQL installations with mysql_secure_installation
MyQSL comes with several utilities to configure and manage a database platform. One useful utility is the mysql_secure_installation script, which limits access to the 'root' account, removes the test database, and removes anonymous accounts. To use the mysql_secure_installation script, you can run it with the path to your my.cnf: The '-n' that is printed looks to be a bug, but reviewing the 'user' table indicates that the script worked as expected.
$ read more →Finding BIND failures in OpenLDAP logfiles
When OpenLDAP is configured to log connection information, a RESULT entry is written with the status (e.g., success or failure) of the last BIND: The "err=" string contains zero if the BIND was successful, and an error code if the BIND didn't complete successfully. The error codes are defined in "LDAPResult.h," which is included with the OpenLDAP source code. When a BIND fails because the credentials were invalid, the error string will contain the value 49: To get the DN that tried to BIND, you can grep the connection number (the value after conn=) out of the OpenLDAP logfile: You can get the IP address of the host that initiated the BIND by grepping the connection id, along with the ACCEPT keyword, from the OpenLDAP logfile: This is useful for tracking down folks who are poking around your directory server.
$ read more →Checking for OpenLDAP unindexed searches
I was checking my openldap logfiles today, and noticed that the "cn" attribute wasn't indexed. I found this by checking for the "index_param" string in my OpenLDAP logfiles: To fix this problem, I added an "index" statement to my slapd.conf: Once the index was added, I rebuilt the indexes with the "slapdindex" utility: The OpenLDAP documentation has more info if you want to learn more.
$ read more →