MaxScale should be able to react when some node of a cluster hits a disk-full situation.

For instance, if the master in a master-slave cluster hits a disk-full situation, MaxScale should promote some existing slave to master and remove the old master from the cluster. That way, a client connected to MaxScale would not necessarily detect anything special at all.

In order to do that, MaxScale must be able to detect that a disk-full situation has occurred. It's difficult and unreliable to do that using MariaDB itself, for instance, by trying to create a table and assuming it was a disk-full situation in case the creation fails or the attempt ends with a timeout. Further, that approach would not allow MaxScale to become aware of the situation before the disk actually becomes full.

A more reliable way would be to actually monitor the disk-space situation on the node and use that for the decision making, but arranging that is rather complex and fragile.

A robust solution would be if there were a pseudo table or pseudo tables in information_schema using which information about the node could be found out. For instance as follows:

MariaDB [information_schema]> select * from information_schema.system;

+------+--------+-----+

| CPUS | MEMORY | ... |

+---------------------+

| 4    | 4096   | ... |

+---------------------+

1 row in set (0.00 sec)

MariaDB [information_schema]> select * from information_schema.disks;

+------------+------------+----------+-----+

| Filesystem |  1K-blocks |     Used | ... |

+------------+------------+----------+-----+

| udev       |    8156512 |        0 |     |

| tmpfs      |    1635388 |     9820 | ... |

| /dev/sda3  |   47929956 | 28150612 |     |

| ...        |        ... |      ... |     |

+------------+------------+----------+-----+

10 rows in set (0.00 sec)

With this information available, MaxScale could automatically take corrective action in case the amount of used disk-space grows above, say, 90%.