With MySQL 5.7 there will be many improvements and changes. The most valuable ones are:

1. “General Tablespace” feature -> From now you can place tables to separate tablespaces. Prior, on our hands there were only “System TableSpace” and “InnoDB file per table” options.

Check for further reading: General Tablespaces Create statement: Create TableSpace

2. Resizing InnoDB Buffer Pool online -> for changing innodb_buffer_pool_size variable restart is required prior to MySQL 5.7, from now we can change buffer pool size without restart dynamically. Read Documentation -> …

What is Optimizer Trace? After reading topic about Optimizer Tracer by [Morgan Tocker][1] decided to test it. From [Optimizer Trace and EXPLAIN FORMAT=JSON in 5.7][2]: Optimizer trace is a new diagnostic tool introduced in MySQL 5.6 to show how the optimizer is working internally. It is similar to EXPLAIN, with a few notable differences: It doesn’t just show the intended execution plan, it shows the alternative choices. You enable the optimizer trace, then you run the actual query. It is far more verbose in its output. For understanding goal of article please read previous one about related verified optimizer BUG: [Playing with count() optimizer work][3] ** We have 2 queries: **select count() from sales; select count(*) from sales where sales_id > 0; Firstly let’s get explain plan for query with JSON format and as regular:

       -- JSON 
          mysql> explain format=json select …

Did you ever try to use log rotate facility in Linux with MySQL? There is no need to script one for this purpose, it is already installed. From MySQL spec file, it looks for logrotate.d folder:

    # Ensure that needed directories exists 
    install -d $RBR%{_sysconfdir}/{logrotate.d,init.d}

As well as there is dedicated mysql-log-rotate.sh script for installing logrotate script. The script path is: /mysql-5.6.24/support-files/mysql-log-rotate.sh Again from spec file:

    # Install logrotate and autostart 
    install -m 644 $MBD/release/support-files/mysql-log-rotate $RBR%{\_sysconfdir}/logrotate.d/mysql

After installing there will be mysql script in /etc/logrottate.d/.

   # The log file name and location can be set in
   # /etc/my.cnf by setting the "log-error" option
   # in either [mysqld] or [mysqld_safe] section as
   # follows: …

Wonder how MySQL Slave server will act, when disk full condition occurs? Before in our articles we use only single MySQL server. Now think about replication topology, where slave server has problem with full partition. Firstly we will enable Binary Log/GTID on Slave side and will ensure that the changes also applied to binary log on Slave side:

      # BINARY LOGGING # 
      server_id = 2 
      log_bin = /opt/mysql/datadir/mysql-bin 
      log_bin_index = /opt/mysql/datadir/mysql-bin 
      expire_logs_days = 14 
      sync_binlog = 1 
      binlog_format = row 
      relay_log = /opt/mysql/datadir/mysql-relay-bin 
      log_slave_updates = 1 
      read_only = 1 
      gtid-mode = on 
      enforce-gtid-consistency = true 
      master-info-repository = TABLE 
      relay-log-info-repository = TABLE 
      slave-parallel-workers = 15 
      binlog-checksum = CRC32 
      master-verify-checksum = 1 
      slave-sql-verify-checksum = 1 …

From previous articles about “disk full” conditions, you have some taste of testing MySQL with such approach:

1. Testing Disk Full Conditions

2. Using GDB, investigating segmentation fault in MySQL

But there is still untouched topic, about read-only mounted file system and how MySQL will act in such condition. In real life, i have encountered such situation that something happened with Linux server and file system suddenly goes to read-only mode.

Buffer I/O error on device sdb1, logical block 1769961 lost page write due to I/O error on sdb1 sd 0:0:1:0: timing out command, waited 360s sd 0:0:1:0: Unhandled error code sd 0:0:1:0: SCSI error: return code = 0x06000008 Result: hostbyte=DID_OK …

In previous article, we have covered some errors and issues with using MySQL in “disk full” environment. Where there was no space left on device.(See here: Testing Disk Full Conditions)

Today’s scenario is -> Starting MySQL with GTID/binary log enabled, in 0 space left Linux(CentOS 6.5) environment.

If you hit a bug or problem, general rule for helping community to fix it is to provide as much information as possible. Especially useful is to give gdb output from coredump. To get coredump you can read this wonderful article Hunting-The-Core

Now let’s explore our situation. Because our segfault is detected while starting MySQL, it is not possible to attach PID to GDB and also using strace. Our my.cnf file:

[mysqld] 
log_bin = …

How MySQL will act if there is no space left on hard disk?
To answer this question, let’s test it:

Our first test is with MySQL 5.6.24-debug with disabled binary log:
Trying to import huge dump, after while it says table is full:

Query OK, 12725 rows affected (2.46 sec)
Records: 12725  Duplicates: 0  Warnings: 0

Query OK, 12724 rows affected (2.40 sec)
Records: 12724  Duplicates: 0  Warnings: 0

Query OK, 12726 rows affected (2.53 sec)
Records: 12726  Duplicates: 0  Warnings: 0

ERROR 1114 (HY000): The table 'sales' is full
ERROR 1114 (HY000): The table 'sales' is full
ERROR 1114 (HY000): The table 'sales' is full

In error log you will see something like:

[root@localhost mysql]# tail -f /opt/mysql/datadir/error.err
Version: '5.6.24-debug'  socket: '/opt/mysql/datadir/mysqld-new.sock'  port: 3307  Shahriyar Rzayev's MySQL
2015-04-24 03:56:09 7fabeffff700 InnoDB: Error: Write to file ./sales2/sales.ibd failed at …

Article about bug report #68814 related to testing count(*) explain plan.

Or sales table huge enough to play with.

mysql> select count(*) from sales;
+----------+
| count(*) |
+----------+
|  2500003 |
+----------+
1 row in set (0.56 sec)

First with regular count(*) without where clause:

mysql> explain select count(*) from sales\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: sales
         type: index
possible_keys: NULL
          key: sales_cust_idx
      key_len: 4
          ref: NULL
         rows: 2489938
        Extra: Using index
1 row in set (0.00 sec)

Estimated rows -> rows: 2489938

Then with {where sales_id > 0}:

mysql> explain select count(*) from sales where sales_id > 0\G
*************************** 1. row …

As you know there is a great toolset named “MySQL Utilities”, which you can use for solving various administrative tasks.
mysqldiskusage utility is for calculating MySQL Server’s disk usage and generating informative reports.
Of course this project is open source and everybody could review the source code.
A few words about how mysqldiskusage calculates database disk usage will be crucial for understanding algorithm.
The source tree is: mysql-utilities-1.5.4/scripts/mysqldiskusage.py
If you open this Python file you will see (line 169-175) :

 # We do database disk usage by default.
    try:
        diskusage.show_database_usage(servers[0], datadir, args, options)
    except UtilError:
        _, e, _ = sys.exc_info()
        print("ERROR: %s" % e.errmsg)
        sys.exit(1)

By …

Due to reported BUG report(BUG 73365) i am testing full disk error conditions with MySQL 5.6.19-debug-log.

There were some interesting error messages in error log:

2014-07-23 08:09:59 7f44500f0700 InnoDB: Error: Write to file ./xxx/news.ibd failed at offset 218103808.
InnoDB: 1048576 bytes should have been written, only -1 were written.
InnoDB: Operating system error number 28.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 28 means 'No space left on device'.

InnoDB: 1048576 bytes should have been written, only -1 were written.
So what is “-1″ here?

The answer from:

[24 Jul 16:02] David Bennett

The -1 value is an error return from the os_file_pwrite() function in …