1 |
. |
2 |
|
3 |
Hello everyone, |
4 |
|
5 |
I upgraded to mariadb-10.2.22-r1 from mariadb-10.1.38-r1 about 3 weeks |
6 |
ago. Just today I've discovered that the log files |
7 |
(/var/lib/mysql/mariadb-bin.XXXXXX) have been accumulating since that |
8 |
time. I have no use for all of these log files, so years ago I set |
9 |
expire_logs_files = 1 in my.cnf to keep just the most recent one. |
10 |
This has worked well until the upgrade. This upgrade also introduced |
11 |
a new way of expressing the /etc/mysql/my.cnf file. It now follows |
12 |
Gentoo practice of pointing to a directory (/etc/mysql/mariadb.d) |
13 |
which contains multiple files that are concatenated to produce the |
14 |
my.cnf file that is handed to mariadb. One of these files |
15 |
(/etc/mysql/mariadb.d/logs) contains |
16 |
[mysql] |
17 |
expire_logs_days = 1 |
18 |
|
19 |
Clearly, this is being ignored, since I now have 3 weeks of |
20 |
accumulated log files instead of just the latest one. When I |
21 |
attempted to log into the mariadb server to examine the values of the |
22 |
global variables, the login failed with the message |
23 |
|
24 |
mysql: unknown variable 'expire_logs_days=1' |
25 |
|
26 |
I then commented out the line "expire_logs_days = 1" in the |
27 |
file /etc/mysql/mariadb.d/logs. This allowed me to log into the |
28 |
mariadb server without the error message to issue the SHOW VARIABLES; |
29 |
command, which revealed that expire_logs_days was set to the 0 |
30 |
default. |
31 |
|
32 |
So clearly mariadb seems to think that expire_logs_days is still a |
33 |
legitimate variable. It looks like something is interpreting the line |
34 |
"expire_logs_days = 1" as just a variable name instead of name = |
35 |
value. |
36 |
|
37 |
Anybody else experience this? Any suggested solutions? I haven't |
38 |
found anything on Google or bugs.gentoo.org. |
39 |
|
40 |
John Blinka |