Bug #83717 Manual does not explain when ddl_log.log file is deleted and how large it can be
Submitted: 7 Nov 2016 10:18 Modified: 29 Nov 2016 13:20
Reporter: Valeriy Kravchuk Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:5.7 OS:Any
Assigned to: Jon Stephens CPU Architecture:Any
Tags: DDL, ddl_log.log, missing manual

[7 Nov 2016 10:18] Valeriy Kravchuk
Description:
MySQL manual (https://dev.mysql.com/doc/refman/5.7/en/ddl-log.html) eplains what is the DDL log, where and when it is created.

But it does not explain how large it can be and for how long time it exists.

In reality is may grow (indefinitely?) until server restarts. After successful startup it seems to disappear.

How to repeat:
Do some SQL that forces creation of ddl_log.log, like this:

mysql> alter table trange drop partition p1;
Query OK, 0 rows affected (1 min 21.54 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> alter table trange drop partition pmax;
Query OK, 0 rows affected (0.39 sec)
Records: 0  Duplicates: 0  Warnings: 0

for some non-empty partiitoned table:

mysql> show create table trange\G
*************************** 1. row ***************************
       Table: trange
Create Table: CREATE TABLE `trange` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `c1` int(11) DEFAULT NULL,
  `c2` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `c1` (`c1`),
  KEY `c2` (`c2`)
) ENGINE=InnoDB AUTO_INCREMENT=402 DEFAULT CHARSET=latin1 STATS_PERSISTENT=0
/*!50100 PARTITION BY RANGE (id)
(PARTITION p1 VALUES LESS THAN (100) ENGINE = InnoDB,
 PARTITION p2 VALUES LESS THAN (200) ENGINE = InnoDB,
 PARTITION p3 VALUES LESS THAN (300) ENGINE = InnoDB,
 PARTITION pmax VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */
1 row in set (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into trange(c1, c2) select c1, c2 from trange;
Query OK, 4 rows affected (0.02 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> insert into trange(c1, c2) select c1, c2 from trange;
Query OK, 8 rows affected (0.00 sec)
Records: 8  Duplicates: 0  Warnings: 0

mysql> insert into trange(c1, c2) select c1, c2 from trange;
Query OK, 16 rows affected (0.00 sec)
Records: 16  Duplicates: 0  Warnings: 0

mysql> insert into trange(c1, c2) select c1, c2 from trange;
Query OK, 32 rows affected (0.00 sec)
Records: 32  Duplicates: 0  Warnings: 0

mysql> insert into trange(c1, c2) select c1, c2 from trange;
Query OK, 64 rows affected (0.00 sec)
Records: 64  Duplicates: 0  Warnings: 0

...

You will see the file is created in the datadir:

[openxs@fc23 5.7]$ ls -l data | grep ddl_log
-rw-r-----. 1 openxs openxs     20480 Nov  7 12:06 ddl_log.log
[openxs@fc23 5.7]$ lsof -p `pidof mysqld` | grep ddl
mysqld  2571 openxs   50u   REG                8,3     20480 3163338 /home/openxs/dbs/5.7/data/ddl_log.log

Even though ALTER completes and there are no other transactions, even after clean shutdown this file remains:

[openxs@fc23 5.7]$ bin/mysqladmin -uroot shutdown
[openxs@fc23 5.7]$ ls -l data | grep ddl_log
-rw-r-----. 1 openxs openxs    20480 Nov  7 12:06 ddl_log.log
[openxs@fc23 5.7]$ ps aux | grep mysqld
openxs    3183  0.0  0.0 118488  2384 pts/2    S+   12:10   0:00 grep --color=auto mysqld

But it disappears upon startup:

[openxs@fc23 5.7]$ bin/mysqld_safe --no-defaults &
[1] 3184
[openxs@fc23 5.7]$ 2016-11-07T10:11:37.257789Z mysqld_safe Logging to '/home/openxs/dbs/5.7/data/fc23.err'.
2016-11-07T10:11:37.287489Z mysqld_safe Starting mysqld daemon with databases from /home/openxs/dbs/5.7/data

[openxs@fc23 5.7]$ ls -l data | grep ddl_log

Suggested fix:
Please, explain more details about the ddl_log.log file in the manual, including those on when it disappears and how large it can be. 

See the test case explained above and Bug #83708 for some hints.
[7 Nov 2016 12:28] Umesh Shastry
Hello Valerii,

Thank you for the report.

Thanks,
Umesh
[10 Nov 2016 15:10] Jon Stephens
After discussion with Paul, I'll take this one.
[29 Nov 2016 13:20] Jon Stephens
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly.

See also BUG#83708.

Closed.