Here's some contextual information: I have a multi-tenant, WordPress MU installation running on Elastic Beanstalk, scaled up to 2 instances minimum. These are connected to the RDS database and are otherwise functioning correctly. Each WordPress install (tenant) has a database on a shared RDS cluster.

This doesn't happen in Aurora MySQL 5.6, which may be a clue, I just haven't been able to find an answer yet. A couple days ago I began upgrading to Aurora MySQL 5.7. I created a new cluster from scratch, and am importing individual databases for a gradual rollout in case there was any problems.

The RDS cluster has 1 primary instance and 1 read replica, and the error is occurring on both the primary and replica.

Here is a sample of the log:

2018-10-17T11:12:55.418509Z 34783 [Note] Aborted connection 34783 to db: 'unconnected' user: 'unauthenticated' host: '' (Got an error reading communication packets)
2018-10-17T11:12:59.939953Z 34785 [Note] Aborted connection 34785 to db: 'unconnected' user: 'unauthenticated' host: '' (Got an error reading communication packets)
2018-10-17T11:13:10.715438Z 34791 [Note] Aborted connection 34791 to db: 'unconnected' user: 'unauthenticated' host: '' (Got an error reading communication packets)

The IPs are the EC2 instances so the connections aren't malicious as far as I can tell. I have the security group setup to only allow connections from the Elastic Beanstalk application.

I find db: 'unconnected' user: 'unauthenticated' to be pretty odd though.

The databases seem to be working fine but I'd like to resolve this before moving the rest of our clients over.

Please let me know if there's any other information I can provide, and thank you in advance for spending the time.

  • Who is Is it in-house? – Rick James Oct 20 '18 at 4:00

The aborted connections log messages are controlled by the log_warnings setting. In MySQL 5.6 it is set to 1 by default whereas in 5.7 the default is 2 (which is more verbose and shows connection messages)

You can compare the description of the settings for 5.6 vs 5.7



Print out warnings such as Aborted connection... to the error log. This option is enabled (1) by default. To disable it, use --log-warnings=0. Specifying the option without a level value increments the current value by 1. Enabling this option by setting it greater than 0 is recommended, for example, if you use replication (you get more information about what is happening, such as messages about network failures and reconnections). If the value is greater than 1, aborted connections are written to the error log, and access-denied errors for new connection attempts are written. See Section B.5.2.11, “Communication Errors and Aborted Connections”.

As long as the defaults weren't changed I wouldn't expect to see the connection errors on the 5.6 server. You could try setting it to 2 and checking the log again: set global log_warnings=2;

  • Thank you! I am rather confident now it is an AWS issue concerning the replication. The log_warning being different didn't occur to me -- I set log_warnings to 2 on the old database and confirmed it happens there as well. – Curtis Oct 18 '18 at 2:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.