Php логирование ошибок mysql

Если выбирать из этих двух, то второй, разумеется. Он на порядок лучше первого:
— в отличие от первого, он будет выдавать ошибки туда же, куда и весь остальной РНР. На машине разработчика это может быть экран, на боевом сайте — лог. Первый плюёт ошибки в браузер ВСЕГДА, чего на боевом сайте не должно быть никогда
— в отличие от первого, он сообщит номер строки и имя файла, где произошла ошибка, что является критически важным для того самого отлова ошибки. Рекомендую попробовать поискать ошибочный запрос в коде на пару тысяч строк по сообщению от первого варианта. Подробнее про то, как правильно обрабатывать ошибки, можно почитать здесь: Обработка ошибок, часть 1

Примечание: на самом деле ни тот, ни другой коды работать не будут, поскольку mysqli_error() тоже требует $link в обязательном порядке.

Дальше уже идут более продвинутые варианты.
Для начала, mysqli умеет кидать исключения из коробки:

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);

и после этого любая ошибка mysqli будет порождать исключение.
Но у этого подхода есть два минуса:
1. Такой вариант может понадобиться только в случае, если обращения к mysqli_query разбросаны по всему коду, чего делать нельзя ни в коем случае.
2. В брошенном исключении будет отсутствовать сам запрос, который может быть очень полезен при отладке.

Поэтому идеальным вариантом будет такой:
Во-первых, все обращения к mysqli API в обязательном порядке надо завернуть в какую-либо библиотеку, которая возьмёт на себя выполнение всей грязной и повторяющейся работы. Пример такой библиотеки — SafeMysql
Во-вторых, в этой библиотеке оформить код обращения к mysqli_query такм образом:

$res = $link->query($query);
if (!$res) throw new Exception($link->error() ." [$query]");

В результате мы получим идеальную обработку ошибок:
— этот код уже из коробки будет так же следовать настройкам РНР, и не будет выдавать ошибки на экран на боевом сервере, но при этом программист всегда будет о ней проинформирован.
— этот код будет выдавать трассировку вызовов — бесценную информацию, без которой найти место, где произошла ошибка, будет очень сложно.
— брошенное исключение можно будет поймать в хендлере или блоке try..catch (однако если нет опыта работы с этими двумя вещами, то на первое время лучше оставить исключение как есть. В обработке ошибок есть много нюансов, неизвестных среднему кодеру, и поэтому лучше оставить эту задачу для РНР).

Журналы событий — первый и самый простой инструмент для определения статуса системы и выявления ошибок. Основных логов в MySQL четыре:

• Error Log — стандартный лог ошибок, которые собираются во время работы сервера (в том числе start и stop);
• Binary Log — лог всех команд изменения БД, нужен для репликации и бэкапов;
• General Query Log — основной лог запросов;
• Slow Query Log — лог медленных запросов.

Лог ошибок

Этот журнал содержит все ошибки, которые произошли во время работы сервера, включая критические ошибки, а также остановки, включения сервера и предупреждения (warnings). С него нужно начать в случае сбоя системы. По умолчанию все ошибки выводятся в консоль (stderr), также можно записывать ошибки в syslog (по умолчанию в Debian) или отдельный лог-файл:

log_error=/var/log/mysql/mysql_error.log

# Ошибки будут писаться в mysql_error.log

Рекомендуем держать этот журнал включенным для быстрого определения ошибок. А для понимания, что значит та или иная ошибка, в MySQL присутствует утилита perror:

shell> perror 13 64
OS error code  13:  Permission denied
OS error code  64:  Machine is not on the network

# Объясняет значения кодов ошибок

Бинарный (он же двоичный) лог

В бинарный лог записываются все команды изменения базы данных, пригодится для репликации и восстановления.

Включается так:

log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 5
max_binlog_size         = 500M

# Указывает расположение, срок жизни и максимальный размер файла

Учтите, что если вы не собираетесь масштабировать систему и реализовывать отказоустойчивость, то бинарный лог лучше не включать. Он требователен к ресурсам и снижает производительность системы.

Лог запросов

В этом журнале содержатся все полученные SQL-запросы, информация о подключениях клиентов. Может пригодиться для анализа индексов и оптимизации, а также выявления ошибочных запросов:

general_log_file        = /var/log/mysql/mysql.log
<b>general_log          = 1</b>

# Включает лог и указывает расположение файла

Также его можно включить/отключить во время работы сервера MySQL:

SET GLOBAL general_log = 'ON';

SET GLOBAL general_log = 'OFF';

# Для применения не нужно перезагружать сервер

Лог медленных запросов

Журнал пригодится для определения медленных, то есть неэффективных запросов. Подробнее читайте в этой статье.

Просмотр логов

Для просмотра логов на Debian (Ubuntu) нужно выполнить:

# Лог ошибок
tail -f /var/log/syslog

<span class="comment"> #Лог запросов
</span>tail -f /var/log/mysql/mysql.log

<span class="comment"> # Лог медленных запросов
</span>tail -f /var/log/mysql/mysql-slow.log

# Если логи не указаны отдельно, то находятся в /var/lib/mysql

Ротация логов

Не забывайте сжимать (архивировать, ротировать) файлы логов, чтобы они занимали меньше места на сервере. Для этого используйте утилиту logrotate, отредактировав файл конфигурации /etc/logrotate.d/mysql-server:

# - I put everything in one block and added sharedscripts, so that mysql gets
<span class="comment">
#   flush-logs'd only once.
</span>#   Else the binary logs would automatically increase by n times every day.
<span class="comment">
# - The error log is obsolete, messages go to syslog now.
</span><b>/var/log/mysql.log /var/log/mysql/mysql.log /var/log/mysql/mysql-slow.log</b> {
        daily
        rotate 7
        missingok
        create 640 mysql adm
        compress
        sharedscripts
        postrotate
                test -x /usr/bin/mysqladmin || exit 0
               <span class="comment"> # If this fails, check debian.conf!
</span>                MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf"
                if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then
                 <span class="comment"> # Really no mysqld or rather a missing debian-sys-maint user?
</span>                 <span class="comment"> # If this occurs and is not an error please report a bug.
</span>                 <span class="comment"> #if ps cax | grep -q mysqld; then
</span>                  if killall -q -s0 -umysql mysqld; then
                    exit 1
                  fi
                else
                  $MYADMIN flush-logs
                fi
        endscript
}

# Сжимает и архивирует нужные логи, очищает файлы

DDL Log

MySQL также ведет лог языка описания данных. В него собираются данные операций типа DROP_TABLE and ALTER_TABLE. Лог используется для восстановления после сбоев, которые произошли во время выполнения таких операций. DDL Log — бинарный файл, не предназначенный для чтения пользователем, поэтому не модифицируйте и не удаляйте его.

Самое главное

Всегда включайте лог ошибок, используйте лог запросов для проверки соединения приложения с базой данных, проверки запросов и работы memcached. Лог медленных запросов пригодится для оптимизации работы MySQL.