The error log contains information about a server's startup and shutdown as well as any critical errors that the server encounters. This includes problems that stop the server or prevent a plugin from starting as well as data corruptions. The log can be enabled or disabled.
Note
The error log is a file and is located in the data directory by default. Its default name is the server's hostname with the .err extension. Using the default name may not be a good idea in a replication environment as all servers have different hostnames, and the administrator may prefer to have identical names for all log files.
On Windows, the error log is enabled by default. If it is explicitly disabled, the errors can be shown on the console using the --console option. Note that this does not work if the --log-error option is present.
On all systems, --log-error explicitly enables the log. It is possible to specify a filename and a path (optionally) using the --log-error=filename syntax. If only a filename is specified, without a path, the error log is placed in the data directory.
If a file is used, the path and name of the file can also be read from the log_error server variable, which is a read-only variable.
Tip
The error log can be disabled on Windows using the console option, but it cannot be disabled on Linux. If a configuration file used by several servers enables the error log, the log files used by an individual server cannot disable it. A trick to do this is specifying the /dev/null special file as an error log, and all writes will simply be suppressed.
If the log_warnings dynamic variable is greater than 0, warnings are logged in to the error log. If the value is greater than 1, all connection errors are logged.
The error log file contains a row for each entry. When the server starts, an empty line is left after the last shutdown message.
Let's see a sample entry and analyze its format:
131231 17:17:38 [ERROR] Event Scheduler: [root@localhost][dataset1.populate_t01] Table 'dataset1.t01' doesn't exist
The first data we see in the preceding example is the date when the error occurred. It is written in the YYMMDD format. After a space, the time is written in a human-readable format.
Then, there is the entry type. The [Note], [Warning], and [ERROR] values have the same meaning just like they do in the Level column of SHOW WARNINGS. An additional value is mysqld_safe, which means the entry has been recorded by the mysqld_safe script. Such rows inform us about server startups and automatic restarts.
Some informative rows do not follow this format because it is not necessary. This happens on startup and after a crash. Such information is never written in the system table.
On some systems, the error log file also includes a stack trace after an abnormal shutdown. This can be used for server debugging.
Suppose that your MariaDB server, on a Linux system, does not start. The first thing to do is to check the error log. Of course, the error must be in the last part of the log. You also know that a fatal error should contain the [ERROR] label.
You can start searching for that label in the final 10 lines of the error log from the command line. You need two Linux utilities: tail, which returns the last lines of a file; and grep, which returns lines that match a given regular expression. On a typical configuration, you also need sudo to gain the permissions to access the file. These programs are all part of the GNU project. All Unix systems have similar tools. On Windows, open source ports of these tools can be installed separately. The most widely used tool is called Cygwin and is available at www.cygwin.com.
Let's execute the proper command, shown as follows:
federico@this:~$ sudo tail -20 /usr/local/mysql/data/this.err | grep ERROR 140101 18:11:21 [ERROR] /usr/local/mysql/bin/mysqld: unknown variable 'base_dir=/usr/local/mysql' 140101 18:11:21 [ERROR] Aborting
The first returned line tells you the exact problem—you set an invalid option in a configuration file (the exact typing is basedir, not base_dir). The second line just informs you about the server shutdown, but you already know that. All you have to do is open the file with an editor and fix the problem.
The problem was simple. However, this example shows the procedure to find the problem that you need to solve.