Skip to content

Serious Bug in Aurora MySQL: tables with foreign key relationships are not placed on the LRU list for memory eviction

2

Hello

We wanted to reach AWS to verify if the Aurora Team is aware of a nasty MySQL bug potentially affecting all MySQL versions 5.7.x and 8.0.x.

This bug is related to how MySQL evicts tables cached in the InnoDB buffer pool. When a table with Foreign Key relationships is loaded into the InnoDB cache, it's never subject to eviction. When many tables with FK are used, the memory used by the InnoDB table cache grows without limits. Memory is only released when shutting down or rebooting the DB instance. This seems to affect only tables with FKs, other tables are evicted normally from the InnoDB cache.

In other words, memory usage will slowly increase over time, creating potential Out of memory errors and DB crashes. The only way for now to release this memory is again by shutting down/rebooting the DB instance affected, which is not optimal.

The bug was first reported 6 years ago and was marked as S2 (Serious) but unfortunately MySQL has not fixed it yet:

https://bugs.mysql.com/bug.php?id=95898

It is also acknowledged by Google Cloud here: https://cloud.google.com/mysql/memory-usage#global-caches

We are aware that the Percona team apparently did release a fix though after finding the bug working on a different issue: https://perconadev.atlassian.net/browse/PS-5639

Can AWS or the Aurora team acknowledge that this bug exists currently in Aurora MySQL or that it has been fixed/patched already? If it has not been patched, are there any plans to fix it in the near future? Many of our DB clusters are experiencing symptoms very similar to this bug so we are thinking that they could be related.

Thanks

1 Answer
0

Just so anyone is aware, AWS support replied to this issue via internal support ticket, i'm leaving their answer below in case anyone is facing the same problem, but unfortunately there wont be any fix on their side. #############################################################################

Dear AWS Customer,

Thanks for reaching back!

I understand your issue that you want to know if AWS has acknowledged this issue as a bug.

From my observation, as we can see that it is already acknowledged by mysql. [+] InnoDB releases memory of table only on shutdown if table has FK constraint: https://bugs.mysql.com/bug.php?id=95898

We can be only fixing the issue in aurora when it is fixed by the mysql community.

As mentioned in the AWS Public Documentation:

When Aurora MySQL accesses tables that are connected through foreign keys, it loads and keeps the related table metadata in memory. This creates a snowball effect where accessing one table triggers the loading of multiple related table definitions into the dictionary cache.

The increase indicates:

  1. Schema Evolution:Your application is adding new tables with foreign key relationships, expanding dictionary cache requirements
  2. Query Pattern Changes: Different access patterns are loading more table definitions into memory
  3. Interconnected Dependencies: As your schema grows, the foreign key relationships create more interconnected metadata that must be cached together

To resolve this issue you can check how many open table definitions are in memory (Open_table_definitions) to confirm how many are being held. If this turns out to be the cause, there are a few things you can explore:

  1. Limit the number of open tables (or check for unnecessary foreign key relations).
  2. Consider refactoring schema if feasible — especially to reduce circular or deep foreign key dependencies.
  3. Set table_definition_cache appropriately — but this is only part of it.

Refer to the below document to troubleshoot the same [+]https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/ams-workload-memory.html#ams-workload-memory.example3

A few Immediate Recommendations:

  1. Proactive Monitoring Setup: I recommend setting up CloudWatch alarms on the FreeableMemory metric with thresholds at 15GB and 8GB to provide early warning [1]
  2. Memory Instrumentation: Implement continuous monitoring using the memory instrumentation queries to track trends over time [2][3][4]
  3. Aurora OOM Response Configuration:Configure the aurora_oom_response parameter to preserve diagnostic information during memory pressure events [5]
  4. Schema Review: Consider reviewing your foreign key relationships for optimization opportunities, particularly checking for:
    • Circular dependencies
    • Unnecessary constraints
    • Tables that could be accessed independently
  5. Connection Management: Monitor and manage idle/sleep connections to optimize memory usage [6]
  6. Scaling Consideration: Given your current memory pressure (only 10GB free), consider temporarily scaling to a larger instance class while we address the root cause
  7. Workload Analysis: Make sure you do not commit large number of changes together , commit in batches. Run EXPLAIN on queries to understand the query execution plan.

I hope the above Information helped you answer your question. If you have any further queries with respect to the above issue, kindly feel free to update/email it on the case, we will be happy to assist you further.

Thank you.

Have a great day and stay safe.

—REFERENCES—— [1] Cloudwatch Alarms: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/creating_alarms.html

[2] Aurora MySQL Memory Workload Management: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/ams-workload-memory.html

[3] MySQL Stored Procedures for Ending Sessions: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-stored-proc-ending.html

[4] Troubleshooting Low Freeable Memory in RDS MySQL/MariaDB: https://repost.aws/knowledge-center/low-freeable-memory-rds-mysql-mariadb

[5] Aurora MySQL Out-of-Memory Response Configuration: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQLOOM.html

[6] Data Dictionary object cache: https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-object-cache.html

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.