7.2 The MySQL Data Directory

Information managed by the MySQL server is stored under a directory known as the data directory. The following list briefly describes the items typically found in the data directory, with cross references for additional information:

• Data directory subdirectories. Each subdirectory of the data directory is a database directory and corresponds to a database managed by the server. All MySQL installations have certain standard databases:

  • The mysql directory corresponds to the mysql system schema, which contains information required by the MySQL server as it runs. This database contains data dictionary tables and system tables. See Section 7.3, “The mysql System Schema”.

  • The performance_schema directory corresponds to the Performance Schema, which provides information used to inspect the internal execution of the server at runtime. See Chapter 29, MySQL Performance Schema.

  • The sys directory corresponds to the sys schema, which provides a set of objects to help interpret Performance Schema information more easily. See Chapter 30, MySQL sys Schema.

  • The ndbinfo directory corresponds to the ndbinfo database that stores information specific to NDB Cluster (present only for installations built to include NDB Cluster). See Section 25.6.15, “ndbinfo: The NDB Cluster Information Database”.

  Other subdirectories correspond to databases created by users or applications.

  Note

  INFORMATION_SCHEMA is a standard database, but its implementation uses no corresponding database directory.

• Log files written by the server. See Section 7.4, “MySQL Server Logs”.

• InnoDB tablespace and log files. See Chapter 17, The InnoDB Storage Engine.

• Default/autogenerated SSL and RSA certificate and key files. See Section 8.3.3, “Creating SSL and RSA Certificates and Keys”.

• The server process ID file (while the server is running).

• The mysqld-auto.cnf file that stores persisted global system variable settings. See Section 15.7.6.1, “SET Syntax for Variable Assignment”.

• The mysql_upgrade_history file. A JSON audit record of the compatibility versions and exact update releases that have run using the data directory.

Some items in the preceding list can be relocated elsewhere by reconfiguring the server. In addition, the --datadir option enables the location of the data directory itself to be changed. For a given MySQL installation, check the server configuration to determine whether items have been moved.

mysql_upgrade_history File

The server maintains mysql_upgrade_history as an audit file. It is not used to permit or reject an upgrade or downgrade, and its contents do not affect data dictionary, replication, or other compatibility decisions.

The root upgrade_history array contains parent entries for compatibility versions. Each new parent entry retains the existing date, version, maturity, and, when applicable, initialize members. The version member contains the three-part compatibility version. Each parent created or updated by MySQL 26.10 also has an update_history array whose entries contain date and version_with_update members.

For example:

 {
      "file_format": "1",
      "upgrade_history": [
        {
          "date": "2026-08-01 10:00:00",
          "version": "26.10.0",
          "maturity": "INNOVATION",
          "initialize": true,
          "update_history": [
            {
              "date": "2026-08-01 10:00:00",
              "version_with_update": "26.10.0.0"
            },
            {
              "date": "2026-08-15 16:45:00",
              "version_with_update": "26.10.0.1"
            },
            {
              "date": "2026-08-25 09:30:00",
              "version_with_update": "26.10.0.0"
            }
          ]
        }
      ]
    }

Update 0 is recorded like any other exact release. If the latest parent has the running compatibility version, a change in the exact version appends an update_history entry. This applies to both upgrades and downgrades. Restarting the same exact version does not add a duplicate entry. A compatibility-version change or a runtime-suffix change creates a new parent entry.

For compatibility with an older valid file, if the latest matching parent has no update_history member, the server adds an initial child containing the current exact release. A present empty update_history array is also valid and receives the current exact release.

Before updating the file, the server validates the complete JSON document, including every parent and every present update_history entry. If parsing fails or any required structure has an invalid type, the server logs:

Invalid format of file 'file_name'. The file will be recreated.

The server then replaces the file with a document containing only the current compatibility-version parent and exact-release child. Failure to read or write this audit file produces a warning but does not prevent initialization or server startup.

The 1000-entry limit applies to compatibility-version parent entries. No separate limit applies to entries in an update_history array.