The error "(pymysql.err.OperationalError) (2006, 'MySQL server has gone away (ConnectionResetError(104, 'Connection reset by peer'))')" frequently occurs during the execution of scheduled batch jobs in Azure Database for MariaDB
Occurrence Time: 1:30 AM JST
Occurred Query: (The query is one executed by the App Service at scheduled times)
TRUNCATE TABLE table_name
Reproduction:
By manually restarting the DB instance and executing the App Service function, the error is reproduced.
Inexplicable Issue:
The error does not occur every day, but rather every other day.
Azure Database for MariaDB
-
Mallaiah Sangi • 890 Reputation points • Microsoft External Staff • Moderator
2025-05-08T10:03:57.4666667+00:00 Hi Mingqi Cai,
Greeting!
There are several reasons for failing your jobs.
- networking issue that can cause this error occurs if the MySQL port (default 3306) is blocked by your firewall, thus preventing any connections at all to the MySQL server
- By default, the server closes the connection after eight hours if nothing has happened. You can change the time limit by setting.
If possible, could you please share the detailed error log threads?
I hope this information helps. Please do let us know if you have any further queries.
- networking issue that can cause this error occurs if the MySQL port (default 3306) is blocked by your firewall, thus preventing any connections at all to the MySQL server
-
Mingqi Cai • 0 Reputation points
2025-05-09T00:51:50.93+00:00 Hi Mallaiah Sangi,
Thank you for your detailed explanation and suggestions.
I will check the firewall settings and connection timeout configuration as advised.
Additionally, could you please clarify which time limit you were referring to and how it can be modified?
Current DB settings are as follows:
SHOW VARIABLES LIKE 'wait_timeout'; # 1800 SHOW VARIABLES LIKE 'interactive_timeout'; # 1800 SHOW VARIABLES LIKE 'max_allowed_packet'; # 536870912 SHOW VARIABLES LIKE 'net_read_timeout'; # 120 SHOW VARIABLES LIKE 'net_write_timeout'; # 240
Please let me know if any of these values might be contributing to the issue.
-
Mallaiah Sangi • 890 Reputation points • Microsoft External Staff • Moderator
2025-05-09T05:31:35.3233333+00:00 Hi Mingqi Cai,
Thank you for reaching out me.
please check the firewall settings and connection setting.
for wait time out period refer this link. https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_wait_timeout
Please let me if you need more assistant.
-
Mingqi Cai • 0 Reputation points
2025-05-09T08:04:23.2233333+00:00 Hi Mallaiah Sangi,
Thank you for your comment.
The firewall settings and connection configurations have been checked and appear to be in order.
As additional information, there are two system environments—stg and stg2—sharing the same database, but this issue only occurs in stg2. As I mentioned earlier, what’s particularly puzzling is that the issue doesn’t happen consistently—it seems to occur every other day, rather than every day (or every time) the job runs.
Given this irregular pattern, do you recommend increasing the timeout settings (such as
wait_timeout
ornet_read_timeout
) as a first step to further isolate the issue?Looking forward to your advice.
And Please let me know if you have any further thoughts or suggestions based on this behavior.
-
PratikLad • 1,125 Reputation points • Microsoft External Staff • Moderator
2025-05-12T15:59:56.27+00:00 Hi Mingqi Cai, what error you are getting can you share the error you are facing?
-
Mingqi Cai • 0 Reputation points
2025-05-13T01:50:56.65+00:00 Hi PratikLad,
Thanks for following up.
The error I'm encountering is as follows:
Please let me know if you need more details.
Looking forward to your advice.
-
PratikLad • 1,125 Reputation points • Microsoft External Staff • Moderator
2025-05-13T17:06:43.2366667+00:00 Hi Mingqi Cai,
You're encountering the error
(2006, 'MySQL server has gone away (Connection reset by peer)')
during scheduled batch jobs in Azure Database for MariaDB, particularly when executingTRUNCATE TABLE
queries. This issue occurs intermittently—roughly every other day—around 1:30 AM JST, and can be reproduced by restarting the database and executing the App Service function manually.The most likely causes include stale or idle database connections being reused by your application, Azure maintenance or auto-scaling events that temporarily disrupt connectivity, and the nature of
TRUNCATE TABLE
, which requires an exclusive lock and can be sensitive to contention or replication delays. Network fluctuations or restarts of the App Service could also contribute to the issue.To mitigate the problem, implement connection retry logic that attempts to reconnect if error 2006 occurs. If you're using SQLAlchemy, enable
pool_pre_ping=True
to ensure that pooled connections are alive before use. Consider replacingTRUNCATE TABLE
withDELETE FROM table_name
if performance permits, as it's less sensitive to locking issues. It's also important to monitor Azure for scheduled maintenance or resource scaling events that might affect database availability. Finally, if you're on a lower-tier SKU, consider upgrading to improve stability and reduce the chance of connection drops.You're encountering the error(2006, 'MySQL server has gone away (Connection reset by peer)')
during scheduled batch jobs in Azure Database for MariaDB, particularly when executingTRUNCATE TABLE
queries. This issue occurs intermittently—roughly every other day—around 1:30 AM JST, and can be reproduced by restarting the database and executing the App Service function manually.The most likely causes include stale or idle database connections being reused by your application, Azure maintenance or auto-scaling events that temporarily disrupt connectivity, and the nature of
TRUNCATE TABLE
, which requires an exclusive lock and can be sensitive to contention or replication delays. Network fluctuations or restarts of the App Service could also contribute to the issue.To mitigate the problem, implement connection retry logic that attempts to reconnect if error 2006 occurs. If you're using SQLAlchemy, enable
pool_pre_ping=True
to ensure that pooled connections are alive before use. Consider replacingTRUNCATE TABLE
withDELETE FROM table_name
if performance permits, as it's less sensitive to locking issues. It's also important to monitor Azure for scheduled maintenance or resource scaling events that might affect database availability. Finally, if you're on a lower-tier SKU, consider upgrading to improve stability and reduce the chance of connection drops. -
PratikLad • 1,125 Reputation points • Microsoft External Staff • Moderator
2025-05-14T16:02:38.23+00:00 Hi Mingqi Cai, We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution
please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
-
PratikLad • 1,125 Reputation points • Microsoft External Staff • Moderator
2025-05-15T08:13:00.0433333+00:00 Hi Mingqi Cai, We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution
please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
-
Mingqi Cai • 0 Reputation points
2025-05-16T07:31:41.7966667+00:00 Hi PratikLad,
Thank you for your comments, and apologies for the delayed response.
We replaced
TRUNCATE TABLE
withDELETE FROM table_name
in the implementation, but the issue still persists. It appears the root cause might lie elsewhere. We're continuing to investigate.Finally, if you're on a lower-tier SKU, consider upgrading to improve stability and reduce the chance of connection drops.
We're considering this as a final option if no other solution works.
Again thank you for following up. And please let me know if you have any other further thoughts or suggestions based on this behavior.
Looking forward to your advice.
-
PratikLad • 1,125 Reputation points • Microsoft External Staff • Moderator
2025-05-16T16:57:26.21+00:00 Hi Mingqi Cai, is upgrading resolve your issue
-
PratikLad • 1,125 Reputation points • Microsoft External Staff • Moderator
2025-05-19T07:48:35.7433333+00:00 Hi Mingqi Cai, We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution
please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
-
Mingqi Cai • 0 Reputation points
2025-05-20T00:23:57.97+00:00 Hi PratikLad,
Thank you for your comments, and apologies for the delayed response.
I'm sorry to tell you the issue still persists.
As for the server upgrade, it will require some additional time, as we need to finalize internal discussions and prepare a formal plan for the client.
We're continuing to investigate other solution works.
Again thank you for following up and please let me know if you have any other further thoughts or suggestions based on this behavior.
Looking forward to your advice.
Sign in to comment