Vérifiez l'état de nos services d'un seul coup d'œil
| Titre | mysql2 down |
| ID | Opération #111 |
| État | terminé |
| Date de début | 18 juin 2013 00:05 |
| Date de fin | 18 juin 2013 01:41 |
| Serveurs concernés |
|
| 18 juin 2013 00:15 |
Kernel panic. We’ve rebooted the server. |
| 18 juin 2013 00:32 |
Once again. We’re investigating. |
| 18 juin 2013 00:38 |
MySQL is suddently using more than the available RAM, which causes the issue. We’re still investigating why. |
| 18 juin 2013 01:02 |
MySQL has been upgraded, to no avail. We’re still investigating and trying solutions. |
| 18 juin 2013 01:13 |
We’ve blocked SQL requests from http10 to mysql2 as a specific account on this server is probably triggering a MySQL bug. |
| 18 juin 2013 01:25 |
We may have isolated the account sending the requests that trigger the bug. |
| 18 juin 2013 01:41 |
The account has been confirmed. The customer has been contacted and we will investigate more together tomorrow. |
| 18 juin 2013 13:00 |
After more investigation, we’ve isolated the query triggering the bug. It’s actually rather simple, but an index was recently created and caused the bug. This is a known issue with MySQL. Note that PostgreSQL cannot suffer from such issues (memory leak) thanks to its multi-process model. |