Как посмотреть логи mysql windows

Обновлено: 02.07.2024

По умолчанию все ошибки выводятся в консоль (stderr), в Debian ошибки пишутся в syslog, но по хорошему было бы неплохо вести этот лог в отдельном файле, а именно:

Как его перенести?

открыв файл /etc/mysql/my.conf я нашел следующую строчку:

Поняв, что все льется в syslog, я закомментировал syslog и добавил следующую строку:

Все, логи пишутся куда нужно, и я спокоен.

ps.: Для того, чтобы понять что означают те или иные ошибки, можно воспользоваться такой штукой, как perror.

В этот лог записываются все команды изменения БД, и нужен он для репликации и восстановления. Включать его не рекомендуется, если никакой репликации не планируется, так как он требователен к ресурсам.

Включается он в файле /etc/mysql/my.conf, там нужно разкомментрировать следующие строки:

Он будет содержать в себе запросы, которые очень нуждаются в оптимизации. По умолчанию он отключен, включается в том же /etc/mysql/my.cnf.

Лог всех запросов.

Пригодиться он опять же для оптимизации и выявления ошибочных запросов, так как записывает все запросы. по умолчанию отключен. Включаем там же: /etc/mysql/my.cnf.

Не забываем про logrotate.

Во первых про LogRotate, приведу скрипт который используется у меня:

Как вы уже поняли, он стандартный, и он прекрасно справляется со своей работой.

Собственно все это можно посмотреть хоть в phpmyadmin, но так же никто не запрещает воспользоваться консольным клиентом MySQL, который так и называется: mysql :)

Для того, чтобы в него попасть, необходимо ввести следующую команду, а после пароль

все, вы в него попали :)

Там мне были полезны две команды:

Команда SHOW STATUS предоставляет информацию по состоянию сервера (как mysqladmin extended-status). Приведенные выше переменные состояния имеют следующие значения:

Некоторые примечания к приведенной выше информации:

Если значение Opened_tables велико, возможно, что значение переменной table_cache слишком мало.
Если значение Key_reads велико, возможно, что значение переменной key_buffer_size слишком мало. Частоту неуспешных обращений к кэшу можно вычислить так: Key_reads/Key_read_requests.
Если значение Handler_read_rnd велико, возможно, поступает слишком много запросов, требующих от MySQL полного сканирования таблиц или у вас есть соединения, которые не используют ключи надлежащим образом.
Если значение Threads_created велико, возможно, необходимо увеличить значение переменной thread_cache_size. Частоту успешных обращений к кэшу можно вычислить при помощи Threads_created/Connections.
Если значение Created_tmp_disk_tables велико, возможно, необходимо увеличить значение переменной tmp_table_size, чтобы временные таблицы располагались в памяти, а не на жестком диске.

Начиная с 4.0.12, MySQL сообщает имя хоста для TCP/IP соединений как имя_хоста:клиентский_порт с тем, чтобы было проще понять, какой клиент чем занят.

Некоторые состояния обычно можно увидеть в mysqladmin processlist.

Существует еще несколько состояний, не упомянутых выше, но большинство из них полезны только для поиска ошибок в mysqld.

В MySQL на данный момент существуют 4 вида журнала (лога) и при достаточно серьёзной работе с базами на MySQL необходимо за ними следить. Например, бинарный лог у нас за сутки набирает около гигабайта, а размер жёсткого диска на сервере ограничен и за ними надо следить. Однако следить следует не только за бинарным логом, так как логи (журналы) в MySQL могут принести немалую пользу.

Итак, какие логи ведёт MySQL? Это:
1. бинарный лог (binary log)
2. лог ошибок (error log)
3. лог медленный запросов (slow query log)
4. лог запросов (general query log)
5. лог репликаций (relay log)

Каждый из них по-своему полезен.

Бинарный лог

В первую очередь полезен с точки зрения репликаций. Можно его бэкапить, можно использовать для восстановления данных на более точное время при использовании бэкапов. Лог содержит все команды изменений базы данных, выборки (select, show) не сохраняет, для таблиц, поддерживающих транзакции (BDB, InnoDB) запись в лог выполняется только после выполнения команды COMMIT . Для лога можно указывать список баз данных, которые надо логировать и список баз данных, которые не надо логировать. В более ранних версиях вместо бинарного лога использовался лог обновлений. Использование бинарного лога снижает производительность базы данных, однако его польза настолько велика, что крайне не рекомендуется его отключать. Рекомендуется защищать бинарный лог паролем, так как он может данные также о паролях пользователей. При достижении максимально разрешённого размера (1 гиг по умолчанию) создаётся следующий файл. Каждый новый файл имеет порядковый номер после имени.

Содержание бинарного лога можно посмотреть с помощью утилиты mysqlbinlog.

Основные настройки в my.cnf

Местоположение лога:
log_bin = /var/log/mysql/mysql-bin.log

Максимальный размер, минимум 4096 байт, по умолчанию 1073741824 байт (1 гигабайт):
max_binlog_size= 500M

Сколько дней хранится:
expire_logs_days = 3

Наиболее часто использующиеся команды

Повторение действий после операции восстановления:
shell> mysqlbinlog log_file | mysql -h server_name

Удаление логов до определённого файла:
PURGE BINARY LOGS TO 'mysql-bin.000';

Удаление логов до определённой даты:
PURGE BINARY LOGS BEFORE 'YYYY-MM-DD hh:mm:ss';

Лог ошибок

Основные настройки в my.cnf

Местоположение лога:
log_error = /var/log/mysql/mysql.err

Флаг, указывающий стоит ли записывать в лог в том числе предупреждения (записываются, если значение больше нуля):
log_warnings = 1

Наиболее часто использующиеся команды

Переход к новому файл лога:
shell> mysqladmin flush-logs

Копирование старой части лога (необходимо, так как в случае повторного выполнения fluch он будет удалён):
shell> mv host_name.err-old backup-directory

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

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

Основные настройки в my.cnf

Местоположение лога:
log_slow_queries = /var/log/mysql/mysql_slow.log

Со скольки секунд выполнения запрос считается медленным, минимальное значений — 1 секунда, по умолчанию 10 секунд:
long_query_time = 10

Если надо логировать запросы, которые не используют индексы, надо добавить строку:
log-queries-not-using-indexes

Если надо вести лог медленных команд, таких как OPTIMIZE TABLE , ANALYZE TABLE и ALTER TABLE :
log-slow-admin-statements

Лог запросов

Лог содержит информацию о подключениях и отключениях клиентов, а также все SQL запросы, которые были получены. Фактически, это временный лог. Обычно лог удаляется автоматически сразу после выполнения всех команд (т.е. как только он стал ненужным). Лог ведётся в соответствии с очередность поступления запросов. Этот лог содержит все запросы к базе данных (независимо от приложений и пользователей). Так что если есть желание (или необходимость) проанализировать, какие необходимы индексы, какие запросы могли бы оптимизированы, то этот лог как раз может помочь в таких целях. Лог полезен не только для случаев, когда необходимо знать, какие запросы выполняются с базой данных, но и в случаях, когда ясно, что возникла ошибка с базой данных, но неизвестно, какой запрос был отправлен к базе данных (например, в случае генерации динамического SQL-а). Рекомендуется защищать лог запросов паролем, так как он может данные также о паролях пользователей.

Основные настройки в my.cnf

Местоположение лога:
log = /var/log/mysql/mysql.log

Наиболее часто использующиеся команды

В отличии от других логов, перезагрузка сервера и команда fluch не инициирует создание нового лога. Но это можно сделать вручную:
shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> mv host_name-old.log backup-directory

Лог репликаций

Здесь логируются изменения, выполненные по инициации сервера репликаций. Как и бинарный лог, состоит из файлов, каждый из которых пронумерован.

Средство просмотра журнала используется в среде SQL Server Management Studio для доступа к сведениям об ошибках и событиях, записываемых в следующие журналы.

Агент SQL Server

События Windows (К ним можно получить доступ с помощью программы просмотра событий Windows.)

Открыть средство просмотра журнала можно несколькими способами (в зависимости от того, какие сведения нужно просмотреть).

Permissions

Чтобы получить доступ к файлам журнала для экземпляров SQL Server , которые находятся в сети, требуется членство в предопределенной роли сервера securityadmin.

Чтобы получить доступ к файлам журнала для экземпляров SQL Server , которые находятся вне сети, необходим доступ на чтение к пространству WMI Root\Microsoft\SqlServer\ComputerManagement10 , а также к папке, в которой хранятся файлы журнала. Дополнительные сведения см. в подразделе "Безопасность" раздела Просмотр автономных файлов журнала.

Безопасность

Требуется членство в предопределенной роли сервера securityadmin.

Просмотр файлов журнала

Просмотр журналов, связанных с общими операциями SQL Server

В обозревателе объектов разверните узел Управление.

Выполните одно из приведенных ниже действий.

Щелкните правой кнопкой мыши Журналы SQL Server, выберите Просмотр, а затем Журнал SQL Server или Журнал SQL Server и Windows.

Разверните узел Журналы SQL Server, щелкните правой кнопкой мыши любой файл журнала и выберите Просмотреть журнал SQL Server. Можно также дважды щелкнуть любой файл журнала.

Доступны журналы Компонент Database Mail, SQL Server, Агент SQL Server и Windows NT.

Просмотр журналов, связанных с заданиями

В обозревателе объектов откройте Агент SQL Server, щелкните правой кнопкой мыши Задания и выберите Просмотр журнала.

Доступны журналы Компонент Database Mail, Журнал заданий и Агент SQL Server.

Просмотр журналов, связанных с планами обслуживания

В обозревателе объектов раскройте узел Управление, щелкните правой кнопкой мыши Планы обслуживания и выберите Просмотр журнала.

Доступны журналы Компонент Database Mail, Журнал заданий, Планы обслуживания, План удаленного обслуживания и Агент SQL Server.

Просмотр журналов, связанных с коллекциями данных

В обозревателе объектов раскройте узел Управление, щелкните правой кнопкой мыши Сбор данных и выберите команду Просмотреть журналы.

Доступны журналы Сбор данных, Журнал заданий и Агент SQL Server.

Просмотр журналов, связанных с компонентом Database Mail

В обозревателе объектов раскройте узел Управление, щелкните правой кнопкой мыши Компонент Database Mail и выберите команду Просмотреть журнал компонента Database Mail.

Доступны журналы Компонент Database Mail, Журнал заданий, Планы обслуживания, Планы удаленного обслуживания, SQL Server, Агент SQL Server и Windows NT.

Просмотр журналов, связанных с коллекциями аудитов

В обозревателе объектов разверните узел Безопасность, затем узел Аудиты, щелкните правой кнопкой мыши аудит и выберите команду Просмотреть журналы.

Доступны журналы Коллекция аудитов и Windows NT.

Журналы событий — первый и самый простой инструмент для определения статуса системы и выявления ошибок. Основных логов в 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

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

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

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

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

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

Лог запросов

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

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

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

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

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

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

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

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

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

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

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

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

DDL Log

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

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

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

Highload нужны авторы технических текстов. Вы наш человек, если разбираетесь в разработке, знаете языки программирования и умеете просто писать о сложном!
Откликнуться на вакансию можно здесь .

Что такое индексы в Mysql и как их использовать для оптимизации запросов

Основные понятия о шардинге и репликации

Примеры ad-hoc запросов и технологии для их исполнения

Настройка Master-Master репликации на MySQL за 6 шагов

Как создать и использовать составной индекс в Mysql

Анализ медленных запросов (профилирование) в MySQL с помощью Percona Toolkit

Открытие файла журнала mysql и подробное объяснение: General_log и Binlog

General_log подробно

1. Введение

Открыть общий журнал будет все Оператор SQL, поступающий на сервер MySQL, записывается.

Как правило, функция открытия не включается, поскольку количество журнала очень велико. Однако в некоторых случаях общий журнал может быть временно открыт для устранения неполадок. к
Есть 3 связанных параметра: general_log, log_output, general_log_file

log_output=’FILE’ Указывает на сохранение журнала в файле, значение по умолчанию - ФАЙЛ.
log_output=’TABLE’ Указывает, что журнал хранится в базе данных, поэтому информация журнала будет записана в mysql.slow_log Стол.

База данных mysql поддерживает два метода хранения журналов одновременно, которые могут быть разделены запятыми при настройке, например: log_output = 'FILE, TABLE'. Журналы записываются в специальной таблице журналов системы, которая потребляет больше системных ресурсов, чем записи в файлы. , Следовательно, если вам нужно включить журналы медленного поиска и требуется более высокая производительность системы, чем достаточно, рекомендуется сначала войти в файлы.

2. Откройте шаг базы данных general_log.

Сначала выполните команду sql: show variables like ‘%log%’;

Вы можете видеть, что по умолчанию general_log отключено, мы можем открыть его напрямую: set global general_log = ON; (Постоянная модификация должна быть добавлена в [mysqld] my.cnf: general_log = 1 ）

Хорошо, теперь mysql будет в general_log_file Общий журнал записывается в отображаемый файл пути! (Запись с этого момента) Мой путь по умолчанию: /usr/local/mysql/data/VM_0_17_redhat.log

Бинлог подробно

1. Введение

Можно сказать, что двоичный журнал MySQL является наиболее важным журналом MySQL. Он записывает все операторы DDL и DML (кроме операторов запроса данных) (записывает внутреннюю Добавления и удаления Дождитесь записи обновленного содержимого базы данных mysql (изменений в базе данных), Запросы к базе данных, такие как select или show, не будут записываться binlog ), который записывается в виде событий, а также содержит время, затраченное на выполнение оператора.Бинарный журнал MySQL безопасен для транзакций.

Вообще говоря, будет Потеря производительности 1% 。

Два наиболее важных сценария использования:
Первый: репликация MySQL открывает двоичный журнал на стороне мастера, и Mster передает свой двоичный журнал ведомым устройствам для достижения согласованности данных ведущего и ведомого. к
Во-вторых: естественно, данные восстанавливаются, и данные могут быть восстановлены с помощью инструмента mysqlbinlog.

Бинарный журнал включает два типа файлов:
Индексный файл двоичного журнала (суффикс имени файла .index) используется для записи всех двоичных файлов;
В двоичный файл журнала (суффикс имени файла .00000 *) записываются все события операторов DDL и DML (кроме операторов запроса данных) в базе данных.

2. Откройте журнал binlog.

Проверьте статус открытия binlog:

Отредактируйте vim, чтобы открыть файл конфигурации mysql my.cnf:

Многие онлайн-руководства просто добавляют строку журнала. Почему мы добавляем здесь идентификатор сервера?
Поскольку мы используем версию 5.7 и выше, перезапуск службы mysql без server-id сообщит об ошибке, а версию ниже 5.7 добавлять не нужно. к

Значит, нужно добавить параметр server-id! Случайным образом укажите строку, имя которой не может совпадать с именем других машин в кластере. Если есть только одна машина, вы можете указать ее по своему желанию. к
нота! После изменения файла конфигурации лучше всего найти errlog mysql и проверить конкретную ошибку. У меня есть ошибка Используйте root для настройки каталога, в котором находится bin-log, без предоставления прав пользователя mysql 。

Также существует способ настройки (укажите три параметра):

Первый параметр - открыть журнал binlog
Второй параметр - это базовое имя файла журнала binlog, к которому будет добавлен идентификатор, указывающий на каждый файл.
Третий параметр указывает индексный файл файла binlog, этот файл управляет каталогом всех файлов binlog

После перезапуска проверьте:

3. Часто используемые команды работы с журналом binlog

1. Просмотреть весь список журналов binlog

2. Просмотрите главный статус, то есть имя номера последнего (последнего) журнала binlog и значение последней конечной точки pos события операции (Position)

3. Обновите журнал, и с этого момента будет создаваться новый пронумерованный файл журнала binlog.

Примечание: при перезапуске службы mysqld она автоматически выполнит эту команду для обновления журнала binlog; добавление опции -F при резервном копировании данных mysqldump также обновит журнал binlog;

4. Сбросить (очистить) все журналы binlog

5. Просмотрите содержимое журнала binlog (в виде таблицы).

4. Использование команды mysqlbinlog

Некоторые параметры команды mysqlbinlog:

Примечание. Подбаза Myslqlbinlog экспортирует binlog. Если вы используете параметр -d, вы должны использовать базу данных при обновлении данных. к
Пример: проанализируйте журнал binlog базы данных yj-test и запишите его в файл my.sql

Вы можете напрямую просмотреть всю информацию бинарного журнала:

5. Три режима работы binlog

Просмотрите формат журнала binlog:

Примечание. Я по умолчанию ROW Режим отличается от режима по умолчанию в Интернете (Заявление)

（1）Row level
ROW основан на уровне строки. Он будет записывать изменения каждой строки записей, то есть записывать модификацию каждой строки в binlog. Запись очень подробная, но Оператор sql отсутствует в binlog 。
Модификация каждой строки данных будет записана в журнал, а затем те же данные будут изменены на ведомой стороне. При репликации нет проблемы несогласованности данных Master-Slave из-за триггеров хранимых процедур и т. Д., Но есть фатальный недостаток, заключающийся в том, что объем журнала относительно велик. Поскольку изменения данных каждой строки записываются, условие where не добавляется после выполнения оператора обновления. Количество журналов, созданных во время alter table или alter table, довольно велико. к

(2) Уровень инструкции (по умолчанию)
Каждый sql измененных данных будет записан в bin-log главного устройства, и когда подчиненное устройство реплицирует, процесс sql будет проанализирован в тот же sql, выполненный исходным мастером, и выполнен снова
Преимущества: устранены недостатки на уровне строк, не требуется записывать изменения данных в каждой строке, сокращается количество журналов бункерных журналов, сохраняется дисковый ввод-вывод и улучшаются новые возможности.

(3) Смешанный (смешанный режим)
Сочетает в себе преимущества уровня строки и уровня утверждения. к
Is по умолчанию, но в некоторых случаях он переключается в состояние строки, например, когда DML обновляет таблицу механизма ndb или функции, связанные с пользователями времени. В случае ведущего-ведомого, если он находится в режиме STATEMENT на ведущем, тогда binlog пишет now () напрямую. Однако, если это так, то время, когда ведомое устройство работает, также выполняется now (), но, очевидно, эти два времени не Будет таким же, поэтому в этом случае вы должны изменить режим STATEMENT на режим ROW, потому что режим ROW будет записывать значения напрямую, а не писать операторы (этот случай неверен, даже режим STATEMENT также может использовать функцию now (), Конкретные причины будут проанализированы позже). Точно так же режим ROW может также уменьшить связанные вычисления ведомого устройства.Например, когда есть операция статистической записи в ведущем устройстве, ведомое устройство может избежать вычисления и записать значение непосредственно на ведомое устройство.

Выбор общего режима корпоративного бинарного журнала:
Интернет-компании используют MySQL с меньшим количеством функций (без хранимых процедур, триггеров, функций) и выбирают уровень операторов по умолчанию;
Используйте специальные функции MySQL (хранимые процедуры, триггеры, функции) для выбора смешанного режима;
Используйте специальные функции MySQL (хранимые процедуры, триггеры, функции), и вы хотите максимизировать объем данных, всегда выбирайте строковый режим;

Читайте также: