Timeline for Why is this DELETE causing my Aurora MySQL 5.7 instance to crash?
Current License: CC BY-SA 4.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 6, 2022 at 21:21 | comment | added | Wilson Hauck | View profile for contact information and get in touch, please. | |
| Jun 6, 2022 at 2:08 | comment | added | Swechsler | I appreciate the responses, but I believe that posting any data publicly would run afoul of our audit department, even if it's not PII data. | |
| Jun 5, 2022 at 19:18 | comment | added | Wilson Hauck | Could you post just the first five items from your (large list of values)? So we can see the information sent to the optimizer. Posting the additional information requested May 30, 2022 would allow us to consider Global Variable options to make DELETE many rows more survivable. | |
| May 30, 2022 at 14:48 | comment | added | Wilson Hauck | Could you post text results of SHOW TABLE STATUS WHERE name LIKE 'bigtable'; for additional information, including AVG ROW SIZE and other details. Welcome to SE. | |
| May 30, 2022 at 13:07 | comment | added | Wilson Hauck | Could you post a SHORT sample of the DELETE query - maybe 10 ids? | |
| May 30, 2022 at 13:01 | comment | added | Wilson Hauck | Additional information request, please. What is your RDS type? RAM size, # cores, any SSD or NVME devices on MySQL Host server? Post on pastebin.com and share the links. From your SSH login root, Text results of: A) SELECT COUNT(*) FROM information_schema.tables; B) SHOW GLOBAL STATUS; after minimum 24 hours UPTIME C) SHOW GLOBAL VARIABLES; D) SHOW FULL PROCESSLIST; E) STATUS; not SHOW STATUS, just STATUS; G) SHOW ENGINE INNODB STATUS; for server workload tuning analysis to provide suggestions - that will increase DELETE tolerance. | |
| May 25, 2022 at 22:43 | comment | added | Swechsler | To clarify, it's not really a true "crash". There's nothing in the error log (yes, it is available) to indicate any problems; however, the mysqld process continues to eat up all memory until the host becomes unresponsive, at which point AWS forces a failover. It's 32k rows, as I noted in the OP, and we are having the application devs change their query, but that's not the point of the post. | |
| May 25, 2022 at 20:55 | comment | added | Rick James | About how many rows? 10K should not be a problem. In any case, I would break it up into 100 or 1000 rows at a time; this will eliminate some of the potential issues. | |
| May 25, 2022 at 15:06 | comment | added | akuzminsky | to clarify. I stay away from RDS not because there is a potential bug - any software has bugs. But because it's nearly impossible to debug. No coredumps, no logs, no way to bpftrace it. | |
| May 25, 2022 at 15:00 | comment | added | akuzminsky | Sorry to hear :/. That's exactly why I stay away from RDS. Is error log available in RDS - there might be stack trace in there. As a workaround you might want to try pt-archiver. It would delete records by the primary key. Hopefully, RDS will survive that. | |
| S May 25, 2022 at 13:39 | review | First questions | |||
| May 25, 2022 at 15:27 | |||||
| S May 25, 2022 at 13:39 | history | asked | Swechsler | CC BY-SA 4.0 |