Part 2 continues this 7-part series on practical MySQL server administration.

Once the server starts, I inspect the physical layout behind the instance. The MySQL data directory does more than hold user tables. It stores server metadata, generated certificates, system schemas, redo information, binary logs, and persisted configuration state.

Locate the Data Directory

Check the data directory path in the MySQL configuration file.

cat /etc/my.cnf

Example terminal output:

[root@mysql-a ~]# cat /etc/my.cnf
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/8.0/en/server-configuration-defaults.html

[mysqld]
datadir=/mysqlbkup
socket=/mysqlbkup/mysql.sock
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[root@mysql-a ~]#

This confirms the active data directory, socket path, error log, and pid file location for the instance.

What You Commonly Find Under Datadir

The data directory typically contains:

  • the mysql system schema
  • the performance_schema
  • the sys schema
  • InnoDB tablespace and redo files
  • binary log files and binlog.index
  • autogenerated SSL and RSA key files
  • runtime files such as the socket and lock file
  • mysqld-auto.cnf for persisted dynamic settings

Inspect the directory directly:

cd /mysqlbkup
ls -ltr

Example terminal output:

[root@mysql-a mysqlbkup]# ls -ltr
total 695788
-rw-r----- 1 mysql mysql        56 Aug  3 21:57 auto.cnf
-rw-r----- 1 mysql mysql   8585216 Aug  3 21:57 #ib_16384_1.dblwr
-rw------- 1 mysql mysql      1680 Aug  3 21:57 ca-key.pem
-rw-r--r-- 1 mysql mysql      1112 Aug  3 21:57 ca.pem
-rw------- 1 mysql mysql      1680 Aug  3 21:57 server-key.pem
-rw-r--r-- 1 mysql mysql      1112 Aug  3 21:57 server-cert.pem
drwxr-x--- 2 mysql mysql       243 Aug  9 21:00 mysql_innodb_cluster_metadata
drwxr-x--- 2 mysql mysql      4096 Oct 26 22:29 #innodb_redo
drwxr-x--- 2 mysql mysql       187 Oct 26 22:29 #innodb_temp
-rw-r----- 1 mysql mysql       389 Oct 26 22:29 binlog.000021
-rw-r----- 1 mysql mysql        64 Oct 26 22:29 binlog.index
-rw------- 1 mysql mysql         5 Oct 26 22:29 mysql.sock.lock
srwxrwxrwx 1 mysql mysql         0 Oct 26 22:29 mysql.sock
-rw-r----- 1 mysql mysql      3874 Oct 26 22:34 mysqld-auto.cnf
-rw-r----- 1 mysql mysql  16777216 Oct 27 22:02 undo_001
-rw-r----- 1 mysql mysql  16777216 Oct 27 22:02 undo_002
-rw-r----- 1 mysql mysql  12582912 Oct 27 22:02 ibdata1
[root@mysql-a mysqlbkup]#

A single listing reveals whether the instance uses binary logging, whether persisted settings exist, and which files InnoDB created during normal operation.

Recognize the Core System Schemas

At minimum, every administrator should be comfortable with these directories or schemas:

  • mysql for system tables and administrative metadata
  • performance_schema for instrumentation data collected during runtime
  • sys for easier DBA-facing views built on top of the Performance Schema
  • ndbinfo in environments that include NDB Cluster

These schemas tell you a lot about the server’s role and how deeply it has been instrumented.

Observe Binary Log Rollover Across a Restart

One useful operational detail: binary log files move forward after a clean restart.

Before restart:

[root@mysql-a mysqlbkup]# ls -ltr *binlog*
-rw-r----- 1 mysql mysql   386408 Oct 28 08:29 binlog.000025
-rw-r----- 1 mysql mysql      128 Oct 28 08:29 binlog.index
-rw-r----- 1 mysql mysql      389 Oct 28 08:29 binlog.000026

Restart the server:

systemctl stop mysqld
systemctl start mysqld

After restart:

[root@mysql-a mysqlbkup]# ls -ltr *binlog*
-rw-r----- 1 mysql mysql   386408 Oct 28 08:29 binlog.000025
-rw-r----- 1 mysql mysql      412 Oct 28 10:49 binlog.000026
-rw-r----- 1 mysql mysql      144 Oct 28 10:49 binlog.index
-rw-r----- 1 mysql mysql      389 Oct 28 10:49 binlog.000027

The new binlog.000027 file confirms that MySQL advanced the binary log sequence after the restart.

Why This Matters Operationally

Understanding the contents of the data directory helps with:

  • troubleshooting startup issues
  • validating persisted configuration changes
  • confirming binary logging status
  • recognizing which schemas and files belong to the server itself
  • identifying unexpected artifacts during audits or incident response

Final Thoughts

The data directory tells the story of the instance. If you know what should live there, you can spot configuration drift, logging behavior, and storage-engine artifacts much faster.

In Part 3, I move from the physical layout into the logical administration layer: the data dictionary, system tables, and server logs.

<
Previous Post
Practical MySQL Server Administration - Part 1: Server Configuration and System Variables
>
Next Post
Practical MySQL Server Administration - Part 3: Data Dictionary and Server Logs