Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Duplicate
-
5.5(EOL), 10.0(EOL)
-
None
-
3 node Galera Cluster
Linux version 3.13.0-48-generic (buildd@orlo) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #80-Ubuntu SMP Thu Mar 12 11:16:15 U
TC 2015 (Ubuntu 3.13.0-48.80-generic 3.13.11-ckt16)
-
10.1.15, 10.1.20, 10.1.22, 10.1.29
Description
There is an intermittent bug whereby the binary log does not rotate . The binary log size is set at 100MB yet there are times it does not rotate and exceeds 100MB .
The binary log has sometimes grown to 60GB in size . Commands like FLUSH LOGS do not achieve rotation . When a binary log file becomes more than 10 days old, it is supposed to be deleted by the database server , this is not happening once hit by the bug .
The Mariadb node has to be restarted to rotate the binary log once it grows above 100MB . Parameters like max-bin-log and expire-logs-days are configured correctly .
max_binlog_size | 104857600
expire_logs_days | 8
Attachments
Issue Links
- includes
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
MDEV-11610 Logrotate to only FLUSH LOCAL ERROR LOGS, ENGINE LOGS, GENERAL LOGS
-
- Closed
-
Activity
The current issue seems to aggregate two separate ones. MDEV-9510 covers the cluster replication one (there's a patch at testing now).
What is behind the 2nd no-cluster 5.5-based remains open.
Lack of expected rotation is a symptom of the parent of the current issue and is explained in its patch (to be reviewed atm).
Folks, In light of the number of log-rotation based stalls, crashes I created the workaround in MDEV-11610. The code for it is here https://github.com/MariaDB/server/pull/323. In essence it removes rotation of binary and relays logs from the logrotate script and injects a SET LOCAL SQL_BIN_LOG=0.
If you have any issues with this patch please note it on the github PR or in MDEV-11610.
If you approve of this intermediary solution please vote for issue MDEV-11610.
I tried performing some log rotations while having an active long transaction, and rotation
worked as expected.
In 10.1, one possible reason that could delay log rotation will be the failure to lock LOCK_xid_list
(TC_LOG_BINLOG::mark_xids_active) during rotate() if it's held by some other thread.
In that case, the thread that triggers the log rotation will remain stuck as well.
The very reported cluster-related issue has been fixed by
MDEV-9510. I am not sure whether followup comments mentioning 5.5 still present an outstanding issue. If they are valid could you please make us known via either writing to this ticket, or better to report a new one.Thanks.