Handling MySQL errors in Go is not easy. There are a lot of MySQL server error codes, and the Go MySQL driver as its own errors, and Go database/sql has its own errors, and errors can bubble up from other packages, like net.OpError. Consequently, Go programs tend not to handle errors. Instead, they simply report errors: err := db.Query(...).Scan(&v) if err != nil { return err } And then the error is logged or reported somewhere.

In this blog post, we’ll look at how using thread_statistics can cause high memory usage.

I was recently working on a high memory usage issue for one of our clients, and made some interesting discoveries: high memory usage with no bounds. It was really tricky to diagnose.

Below, I am going to show you how to identify that having thread_statistics enabled causes high memory usage on busy systems with many threads.

Part 1: Issue Background

I had a server with 55.0G of available memory. Percona Server for MySQL version:

Version | 5.6.35-80.0-log Percona Server (GPL), Release 80.0, Revision f113994f31
                 Built On | debian-linux-gnu x86_64

We have …

In this blog, we’ll look at the differences in how a PREPARE statement handles errors in binary and text protocols.

Introduction

Since Percona XtraDB Cluster is a multi-master solution, when an application executes conflicting workloads one of the workloads gets rolled back with a DEADLOCK error. While the same holds true even if you fire the workload through a PREPARE statement, there are differences between using the MySQL connector API (with binary protocol) and the MySQL client (with text protocol). Let’s look at these differences with the help of an example.

Base Workload

• Say we have a two-node cluster (n1 and n2) with the following base schema and tables:
  

  use test;
  create table t (i int, k int, primary key pk(i)) engine=innodb;
  insert into t values (1, 10), (2, 20), (3, 30); …

Next time you have an error whilst running an sql script into mysql using the pretty easy redirect into eg: mysql -uroot -pmsandbox -h127.0.0.1 -P3306 dbname < filename you might want to give the -v option a shot.

MySQL normally outputs an error with the line number like:

[mysql@dcassar-ubuntu /mysql/dumps/stored_procs 11:10:12]$ mysql -uroot -pmsandbox -h127.0.0.1 -P5151 test < file
ERROR 1267 (HY000) at line 375: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_general_cs,IMPLICIT) for operation '='


But 375 is not including comments and stuff so it’s a bit hard to go through the file to locate the exact section which is failing.

Run the same command with -v:

[mysql@dcassar-ubuntu /mysql/dumps/stored_procs 11:10:30]$ mysql -uroot -pmsandbox -h127.0.0.1 -P5151 -v test < file | tail -5
ERROR 1267 (HY000) at line 375: Illegal mix …

If you are having an issue with adding hosts/clients/users on revision 162 it’s because of the INSERT DELAYED sql command being used. Before I release a new version, please change the following lines in the file “system/application/models/mode_app.php” Incorrect code line 70: $sql0="INSERT DELAYED INTO server_list ( line 139: $sql0="INSERT DELAYED INTO `server_client` ( line 177: $sql0="INSERT DELAYED INTO `system_users` [...]

Had to fix a service process error on the original release of the appliance. It’s now fixed and the machine export is running. I’ll have the new file uploaded and ready for use at approximately 20:00PST (GMT +8).

Just spotted the following posting from Paul DuBois on the internals mailing list:

I'm engaged in a project (WL#3403) to compile information that will provide better information about our errors and error messages:

• What an error means
• Likely causes of the error
• How to rectify or work around the error

The general idea is to provide our users something more than a list of error codes and the messages from errmsg.txt, such as the manual currently includes here:

…

Came across an error on the sql for the overview.php page. It wasn’t correctly displaying aggregate data on the charts. So here’s the fix for rev50 to rev51. This isn’t a deal breaker on the release but if you’re inclined to open system/application/models/model_main.php and replace one line it’s easier than waiting for our next release.

2001c2001
< $sql = "select $xval,DATE_FORMAT(Creation_time,'%m-%d %H:%i') as Date from server_statistics WHERE Creation_time BETWEEN '$sday' AND '$eday' GROUP BY DAY(Creation_time),HOUR(Creation_time) ORDER BY Creation_time";
---
> $sql = "select max($xval) as $xval,DATE_FORMAT(Creation_time,'%m-%d %H:%i') as Date from server_statistics WHERE Creation_time BETWEEN '$sday' AND '$eday' GROUP BY DAY(Creation_time),HOUR(Creation_time) ORDER BY Creation_time";

Fixed a lingering JS issue with the ExtJS code in header.php file that was preventing IE7 from loading the main.php page. It was….. an extra comma! If you are inclined to edit one file here is the diff change, otherwise like other bug fixes it will be included with the next release. The file is system/application/views/header.php and the change is for line #327 for revision 42+.

< {id: 'innodb_total', header: "innodb_total", width: 75, sortable: true, renderer: 'fileSize', dataIndex: 'innodb_total'},
---
> {id: 'innodb_total', header: "innodb_total", width: 75, sortable: true, renderer: 'fileSize', dataIndex: 'innodb_total'}


If you run IE7 and have tried Kontrollbase you may have noticed an infinite progress bar for the authentication. While login works on all other browsers, it was broken on IE7. The change has been committed to the repo and will be available in the next release. If you are inclined to edit one file here is the diff change. The file is system/application/controllers/login.php and the change is for line #68.

68c68
< $user_system_user_id = $this->session->userdata('user_system_user_id');
---
> $user_system_user_id = $this->phpsession->get('user_system_user_id');