Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.1(EOL)
Description
According to https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-101/, Galera (wsrep stroage engine in SHOW PLUGINS output, to be more specific) is a standard part of MariaDB 10.1 (and newer version).
It is not documented anywhere explicitly, but one can conclude from code review and fix for MDEV-9214 that wsrep is XA-capable storage engine. With it we'll have tc.log created in the datadir of 10.1+ and maintained by default, even if wsrep_on is set to OFF and InnoDB is the only XA-capable storage engine listed in SHOW ENGINES:
MariaDB [test]> \! ls -l data/*.log
|
-rw-rw---- 1 openxs openxs 24576 чер 8 17:25 data/tc.log
|
MariaDB [test]> select @@datadir, @@wsrep_on, @@log_bin;
|
+----------------------------------+------------+-----------+
|
| @@datadir | @@wsrep_on | @@log_bin |
|
+----------------------------------+------------+-----------+
|
| /home/openxs/dbs/maria10.1/data/ | 0 | 0 |
|
+----------------------------------+------------+-----------+
|
1 row in set (0.00 sec)
|
|
|
MariaDB [test]> show engines;
|
+--------------------+---------+--------------------------------------------------------------------------------------------------+--------------+------+------------+
|
| Engine | Support | Comment | Transactions | XA | Savepoints |
|
+--------------------+---------+--------------------------------------------------------------------------------------------------+--------------+------+------------+
|
| MRG_MyISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
|
| CSV | YES | CSV storage engine | NO | NO | NO |
|
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
|
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
|
| SEQUENCE | YES | Generated tables filled with sequential values | YES | NO | YES |
|
| Aria | YES | Crash-safe tables with MyISAM heritage | NO | NO | NO |
|
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
|
| InnoDB | DEFAULT | Percona-XtraDB, Supports transactions, row-level locking, foreign keys and encryption for tables | YES | YES | YES |
|
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
|
+--------------------+---------+--------------------------------------------------------------------------------------------------+--------------+------+------------+
|
9 rows in set (0.00 sec)
|
I found literally nothing in MariaDB KB about the tc.log file and numerous bug reports mentioning failures to create it etc mean that this information is clearly missing. MySQL's reference here, https://dev.mysql.com/doc/refman/5.6/en/server-options.html#option_mysqld_log-tc, refers to multiple storage engines:
"... memory-mapped transaction coordinator log file (for XA transactions that affect multiple storage engines when the binary log is disabled)."
and is not helpful unless we document Galera (wsrep) engine as the one that causes this file to be created in 10.1+.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
Hi valerii,
If he saw errors like this:
2018-11-30 23:08:49 140046048638848 [ERROR] Recovery failed! You must enable exactly 3 storage engines that support two-phase commit protocol
|
2018-11-30 23:08:49 140046048638848 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover={commit|rollback}
|
2018-11-30 23:08:49 140046048638848 [ERROR] Can't init tc log
|
2018-11-30 23:08:49 140046048638848 [ERROR] Aborting
|
Then that's already documented here:
Can you please share what errors you saw?
I got a different error, basically the one reported here:
https://github.com/docker-library/mariadb/issues/201
The "Bad Magic Number" being the key. We've made changes similar to the recommendations in that issue in our deployment, and deleting the tc.log worked as expected since we were only using innodb.
Deleting tc.log is a temporary fix. It sounds like this problem can happen every time a docker instance is rebooted.
Which of the specific changes mentioned there fixed the problem with the docker instance permanently for you? i.e.:
- Running mysql_upgrade?
- Explicitly specifying a major release (like "mariadb: 10.3") in the compose file?
- Setting a "stop timeout" for the container?
- Something else?
I went ahead and created this section:
If you are using the memory-mapped file-based transaction coordinator log, then it is possible to see errors like the following:
2018-09-19 4:29:31 0 [Note] Recovering after a crash using tc.log
2018-09-19 4:29:31 0 [ERROR] Bad magic header in tc log
2018-09-19 4:29:31 0 [ERROR] Crash recovery failed. Either correct the problem (if it's, for example, out of memory error) and restart, or delete tc log and start mysqld with --tc-heuristic-recover=Unknown macro: {commit|rollback}
2018-09-19 4:29:31 0 [ERROR] Can't init tc log
2018-09-19 4:29:31 0 [ERROR] AbortingThis means that the header of the memory-mapped file-based transaction coordinator log is corrupt. To recover from this error, delete the file defined by the --log-tc server option, and then restart the server with the --tc-heuristic-recover option set.
This issue is known to occur when using docker. In that case, the problem may be caused by using a MariaDB container version with a data directory from a different MariaDB or MySQL version. Therefore, some potential fixes are:
- Pinning the docker instance to a specific MariaDB version in the docker compose file, so that it consistently uses the same version.
- Running mysql_upgrade to ensure that the data directory is upgraded to match the server version.
See this docker issue for more information.
https://mariadb.com/kb/en/library/transaction-coordinator-log-overview/#bad-magic-header-in-tc-log
The above is good for my original request, but does not cover concern from the comment by Monty Taylor - when one may have to and can safely remove tc.log upon startup.