maria DB 10.6.5, 10.5.13, 10.4.22, 10.3.32, 10.2.41.

it release version, so DA Team need time to testing and ensure to not make data corruption.
 
10.5.13 on master appears to break replication "Got fatal error 1236 from master when reading data from binary log: 'Binary log is not open'"
 
It looks like the /etc/my.cnf is overwritten when updating so we lost all our changes to my.cnf. We haven't seen this before during other updates. Is there a reason why this is necessary? And what's the best way to add our own mysqld variables to my.cnf?
 
hnzufx said:
It looks like the /etc/my.cnf is overwritten when updating so we lost all our changes to my.cnf. We haven't seen this before during other updates. Is there a reason why this is necessary? And what's the best way to add our own mysqld variables to my.cnf?
Click to expand...
Yes; this is why my replication broke as well.
 
look like no option to direct customize my.cnf from reading direct on build script
around line 10552

it check only
if [ ! -e /root/.skip_mysql_install ]; then
Click to expand...
just create file to tell build script to skip setting my.cnf
Code: 
touch /root/.skip_mysql_install

but your old file not complete removing, it just move to ".old"

#edit
2777 - Move creation of basic my.cnf from setup procedures to CustomBuild.
Click to expand...
I see this before, but I have no clue what's it meant, where's file to move, until today. ;(
 
Last edited:
jamgames2 said:
but your old file not complete removing, it just move to ".old"
Click to expand...
That shouldn't happen anyway. Why is the new my.cnf not changed to my.cnf.new instead of overwriting existing ones?

It seems the /etc/my.cnf.d/server.cnf might be used to do the settings, but still... it's a sudden change we should have been warned about and given a way to prevent it.

So I'm also curious as to why this sudden change.
 
I would prefer that the backup file be named my.cnf.old-YYYYMMDDHHMM (eg: my.cnf.old-202111161146) so that they are all preserved, don't overwrite the previous backup file, I can clean them up later. Something like this would help prevent loss of a config from say doing an update twice. Which did happen to me on my test machine, but easy to fix (I can go back in my archive backup and grab the changes). Others may not be so lucky. May be as an alternative/option leave the old config in place and create a my.cnf.new-202111161146 with the new config to be manually merged/updated.
 
Richard G said:
That shouldn't happen anyway. Why is the new my.cnf not changed to my.cnf.new instead of overwriting existing ones?

It seems the /etc/my.cnf.d/server.cnf might be used to do the settings, but still... it's a sudden change we should have been warned about and given a way to prevent it.

So I'm also curious as to why this sudden change.
Click to expand...
It was a bug, and it has been fixed in latest version of CB.
 
You must log in or register to reply here.
Back
Top