- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Hi, I hope my answer would help you. Confirm the autocommit status directly in the Aurora database by checking the global variable value. This will validate if the server setting is actually being overridden. (SHOW VARIABLES LIKE 'autocommit';) By default, autocommit is enabled in Aurora MySQL, so the server_status value returned would be 2. This indicates that all SQL statements are committed implicitly, without the need for an explicit COMMIT statement.
Clients like the PyMySQL Python module rely on the server_status value to determine whether to issue COMMIT statements or not. But in Aurora MySQL, the value may be 2 even if autocommit is actually disabled at the server level.
As a workaround, you could explicitly start transactions and commit/rollback instead of relying on autocommit detection.
I'd summary like below: Aurora autocommit enabled (default): server_status value is 2 Aurora autocommit disabled: server_status value should be 0 but Aurora may still return 2 This mismatch can cause issues for clients expecting the standard MySQL behavior. Explicit transactions are recommended as a workaround when autocommit detection fails.
Contenuto pertinente
- AWS UFFICIALEAggiornata un anno fa
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 3 anni fa
- AWS UFFICIALEAggiornata un anno fa
Hi Regina, thanks for the answer. I know how to make it work explicitly, but problem is that this is existing bug with Aurora, because PyMySQL is even on official AWS RDS tutorial pages in python examples and people using this module will expect it to work properly with AWS databases and it's not currently. Never in any AWS page it's being noted that you need to explicitly commit every transaction, because autocommit option is not working for this module using Aurora. Autocommit is very important, as I don't imagine people commit after each select whenever you are doing readonly application., it just doesn't make sense. Either PyMySQL should be notified and they need to update the module to stop relying on this or Aurora team need to make sure proper server_status is being returned. Just to make clear that "server_status" is a variable in PyMySQL, they call it that way.