Description
When you click on "User manager" it automatically performs FLUSH PRIVILEGES.
This statement FLUSH PRIVILEGES is actually always binlogged and also generates a gtid (if the mysql server is in gtid mode) and can be dangerous depending on the situation.
I will give example, actually my use case, where it is dangerous.
I have a read only slave server that is used as a standby and in case of emergency it is promoted as a master. All my servers in the topology are in gtid mode.
I am connecting with HeidiSQL to that read only server to check some things without intention to write. But because I clicked on user management there is actually a write performed and gtid is generated. Then few days later the binary log that contained this particular gtid event are rotated/purged. Then I need to promote this server as master to the others servers in the topology and none of them can replicate because this gtid can not be found any more on the original server binary log and my life becomes complicated :)
I know as dba there is a way to deal with the situation (either by generating empty transactions for the missing gtids, or even go further and find them in some other backup and so on). I know that I should connect with limited user to the server. And so many other workarounds.
Not sure if this is actually a bug or by design, but I ask you to reconsider. There might be more such interractions that would do some implicit writes ...
HeidiSQL version and OS
12.17 Windows 11
Database server version
mysql any version I guess
Reproduction recipe
Error/Backtrace
Description
When you click on "User manager" it automatically performs FLUSH PRIVILEGES.
This statement FLUSH PRIVILEGES is actually always binlogged and also generates a gtid (if the mysql server is in gtid mode) and can be dangerous depending on the situation.
I will give example, actually my use case, where it is dangerous.
I have a read only slave server that is used as a standby and in case of emergency it is promoted as a master. All my servers in the topology are in gtid mode.
I am connecting with HeidiSQL to that read only server to check some things without intention to write. But because I clicked on user management there is actually a write performed and gtid is generated. Then few days later the binary log that contained this particular gtid event are rotated/purged. Then I need to promote this server as master to the others servers in the topology and none of them can replicate because this gtid can not be found any more on the original server binary log and my life becomes complicated :)
I know as dba there is a way to deal with the situation (either by generating empty transactions for the missing gtids, or even go further and find them in some other backup and so on). I know that I should connect with limited user to the server. And so many other workarounds.
Not sure if this is actually a bug or by design, but I ask you to reconsider. There might be more such interractions that would do some implicit writes ...
HeidiSQL version and OS
12.17 Windows 11
Database server version
mysql any version I guess
Reproduction recipe
Error/Backtrace