pt-mysql-summary : bad size of transaction logs

[Frederic Descamps]

The output of pt-mysql-summary displays wrong value in calculation for InnoDB log files:

       Log File Size | 2 * 1G = 2.9G

in my.cnf:

innodb_log_file_size = 1500M

mysql> show global variables like 'innodb_log_file%';
+---------------------------+------------+
| Variable_name | Value |
+---------------------------+------------+
| innodb_log_file_size | 1572864000 |
| innodb_log_files_in_group | 2 |
+---------------------------+------------+

[Daniel Nichter (daniel-nichter)]

The real value is/should be 3_145_728_000, or 3.1G.

[Brian Fraser (fraserbn)]

Code fixed in 2.0.4, but we weren't able to test it properly because pt-mysql-summary conflates gathering data and reporting it, and the only way to get it right would be to create a 1.5GB log file for the test. In 2.1.x, pt-mysql-summary will get a reorganization, so tests for this fix will go there.

[Daniel Nichter (daniel-nichter)]

Not fixed yet, so I have untargeted from 2.0.4 so the release may proceed.

[Daniel Nichter (daniel-nichter)]

Turns out, "Log File Size | 2 * 1G = 2.9G" is correct. Here's the comment that's now in shorten():

   # By default Mebibytes (MiB), Gigibytes (GiB), etc. are used because
   # that's what MySQL uses. This may create odd output for values like
   # 1500M * 2 (bug 937793) because the base unit is MiB but the code
   # see 1,572,864,000 * 2 = 3,145,728,000 which is > 1 GiB so it uses
   # GiB as the unit, resulting in 2.9G instead of 3.0G that the user
   # might expect to see. There's no easy way to determine that
   # 3,145,728,000 was actually a multiple of MiB and not some weird GiB
   # value to begin with like 3.145G. The Perl lib Transformers::shorten()
   # uses MiB, GiB, etc. too.

[Daniel Nichter (daniel-nichter)]

See bug 993436 for a fixed version of shorten().

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PT-937