What happened?
Setting binlog: false to any of MySQL resources does not prevent MySQL server from writing to binlogs. Looks like this option is not applied at all.
How can we reproduce it?
- Run a MySQL server with binlogs enabled
- Create a kube resource
User for which spec.forProvider.binlog = false
- On MySQL server, run
mysqlbinlog -vv /var/lib/mysql/mysql-bin.XXXX
→ You can see CREATE USER statement in binlogs
What environment did it happen in?
Crossplane version: v1.14.5
Provider-sql version: v0.9.0
Analysis
By looking into the code, the SET sql_log_bin = 0 statement is executed in a different MySQL connection from the one used for create/update/delete resource. In fact, as mySQLDB.Exec() creates a new sql.Database object, it also opens/closes a new every time it 's called, which explain why this option is not taken into account.
See MySQL doc about this option.
I've been working on a patch to fix this, a PR will follow.
What happened?
Setting
binlog: falseto any of MySQL resources does not prevent MySQL server from writing to binlogs. Looks like this option is not applied at all.How can we reproduce it?
Userfor whichspec.forProvider.binlog = falsemysqlbinlog -vv /var/lib/mysql/mysql-bin.XXXX→ You can see
CREATE USERstatement in binlogsWhat environment did it happen in?
Crossplane version: v1.14.5
Provider-sql version: v0.9.0
Analysis
By looking into the code, the
SET sql_log_bin = 0statement is executed in a different MySQL connection from the one used for create/update/delete resource. In fact, asmySQLDB.Exec()creates a newsql.Databaseobject, it also opens/closes a new every time it 's called, which explain why this option is not taken into account.See MySQL doc about this option.
I've been working on a patch to fix this, a PR will follow.