Журнал ошибок mysql

В 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';

Лог ошибок

Особенно полезен в случаях сбоев. Лог содержит информацию об остановках, запусках сервера, а также сообщения о критических ошибках. Может содержать сообщения с предупреждениями (warnings).

Основные настройки в 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

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

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

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

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

Максимальный размер:
max_relay_log_size = 500М

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

Начать новый файл лога можно только при остановленном дополнительном (slave) сервере:
shell> cat new_relay_log_name.index >> old_relay_log_name.index
shell> mv old_relay_log_name.index new_relay_log_name.index

Команда fluch logs инициирует ротацию лога.

Всем привет! Заметка будет краткой, так как не хочу открывать лишние вкладки, для того чтобы вспомнить, где и как включать логи. Ниже будет описание о том, какие логи есть (кратко) и как их включить (емко).
Логи в MySQL

Лог ошибок — Error Log

Если необходимо понять, по какой причине не запускается MySql сервер — error log вам в помощь. Там же еще можно прочесть сообщения о том,

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

/var/log/mysql/mysql_error.log

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

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

Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.

Ок, полез в файл /etc/mysql/conf.d/mysqld_safe_syslog.cnf — там следующее содержимое:

[mysqld_safe]
syslog

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

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

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

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

Двоичный («bin’арный») лог.

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

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

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

Подробнее:

  • log_bin — расположение;
  • expire_logs_days — срок жизни;
  • max_binlog_size — максимальный размер файла.

Лог медленных запросов — mysql-slow.log.

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

Если версия MySql у вас < 5.7, то в нужно исправить следующие настройки:

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 1

Если версия MySql у вас > или = 5.7, то нужно исправить следующие настройки:

slow_query_log = /var/log/mysql/mysql-slow.log
long_query_time = 1

Подробнее:

  • log_slow_queries (slow_query_log) — путь к файлу настроек;
  • long_query_time — минимальное время выполнения запроса в секундах, после которого он считается медленным.

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

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

Настройки нужно исправить на подобные:

general_log_file = /var/log/mysql/mysql.log
general_log = 1

Подробнее:

  • general_log_file — месторасположение
  • general_log — включение лога

Включить этот лог «на лету», без перезагрузки, мы можем и из консоли «mysql»:

SET GLOBAL general_log = 'ON';
SET GLOBAL general_log = 'OFF';

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

Дополнено 04/12/2017…

Как я и обещал в какой-то другой статье — «возможно статья будет дополняться».

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

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

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

Нагрузка на БД

Кроме того у меня возникал вопрос: «Скажите пожалуйста какими командами в SSH вычисляется нагрузка на БД ?«..

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

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

 [[email protected] ]# mysql -u root -p -h localhost
Enter password:
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 7926
Server version: 5.0.45 Source distribution

Type 'help;' or 'h' for help. Type 'c' to clear the buffer.

mysql&gt;

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

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

show status — команда  предоставляет информацию по состоянию сервера.

Пример ее вывода

mysql&gt; show status;
+-----------------------------------------------+-------------+
| Variable_name                                 | Value       |
+-----------------------------------------------+-------------+
| Aborted_clients                               | 0           |
| Aborted_connects                              | 1           |
| Binlog_cache_disk_use                         | 0           |
| Binlog_cache_use                              | 0           |
| Binlog_stmt_cache_disk_use                    | 0           |
| Binlog_stmt_cache_use                         | 0           |
| Bytes_received                                | 272         |
| Bytes_sent                                    | 509         |
| Com_admin_commands                            | 0           |
| Com_assign_to_keycache                        | 0           |
| Com_alter_db                                  | 0           |
| Com_alter_db_upgrade                          | 0           |
| Com_alter_event                               | 0           |
| Com_alter_function                            | 0           |
| Com_alter_procedure                           | 0           |
| Com_alter_server                              | 0           |
| Com_alter_table                               | 0           |
| Com_alter_tablespace                          | 0           |
| Com_alter_user                                | 0           |
| Com_analyze                                   | 0           |
| Com_begin                                     | 0           |
| Com_binlog                                    | 0           |
| Com_call_procedure                            | 0           |
| Com_change_db                                 | 0           |
| Com_change_master                             | 0           |
| Com_check                                     | 0           |
| Com_checksum                                  | 0           |
| Com_commit                                    | 0           |
| Com_create_db                                 | 0           |
| Com_create_event                              | 0           |
| Com_create_function                           | 0           |
| Com_create_index                              | 0           |
| Com_create_procedure                          | 0           |
| Com_create_server                             | 0           |
| Com_create_table                              | 0           |
| Com_create_trigger                            | 0           |
| Com_create_udf                                | 0           |
| Com_create_user                               | 0           |
| Com_create_view                               | 0           |
| Com_dealloc_sql                               | 0           |
| Com_delete                                    | 0           |
| Com_delete_multi                              | 0           |
| Com_do                                        | 0           |
| Com_drop_db                                   | 0           |
| Com_drop_event                                | 0           |
| Com_drop_function                             | 0           |
| Com_drop_index                                | 0           |
| Com_drop_procedure                            | 0           |
| Com_drop_server                               | 0           |
| Com_drop_table                                | 0           |
| Com_drop_trigger                              | 0           |
| Com_drop_user                                 | 0           |
| Com_drop_view                                 | 0           |
| Com_empty_query                               | 0           |
| Com_execute_sql                               | 0           |
| Com_flush                                     | 0           |
| Com_get_diagnostics                           | 0           |
| Com_grant                                     | 0           |
| Com_ha_close                                  | 0           |
| Com_ha_open                                   | 0           |
| Com_ha_read                                   | 0           |
| Com_help                                      | 0           |
| Com_insert                                    | 0           |
| Com_insert_select                             | 0           |
| Com_install_plugin                            | 0           |
| Com_kill                                      | 0           |
| Com_load                                      | 0           |
| Com_lock_tables                               | 0           |
| Com_optimize                                  | 0           |
| Com_preload_keys                              | 0           |
| Com_prepare_sql                               | 0           |
| Com_purge                                     | 0           |
| Com_purge_before_date                         | 0           |
| Com_release_savepoint                         | 0           |
| Com_rename_table                              | 0           |
| Com_rename_user                               | 0           |
| Com_repair                                    | 0           |
| Com_replace                                   | 0           |
| Com_replace_select                            | 0           |
| Com_reset                                     | 0           |
| Com_resignal                                  | 0           |
| Com_revoke                                    | 0           |
| Com_revoke_all                                | 0           |
| Com_rollback                                  | 0           |
| Com_rollback_to_savepoint                     | 0           |
| Com_savepoint                                 | 0           |
| Com_select                                    | 1           |
| Com_set_option                                | 0           |
| Com_signal                                    | 0           |
| Com_show_binlog_events                        | 0           |
| Com_show_binlogs                              | 0           |
| Com_show_charsets                             | 0           |
| Com_show_collations                           | 0           |
| Com_show_create_db                            | 0           |
| Com_show_create_event                         | 0           |
| Com_show_create_func                          | 0           |
| Com_show_create_proc                          | 0           |
| Com_show_create_table                         | 0           |
| Com_show_create_trigger                       | 0           |
| Com_show_databases                            | 0           |
| Com_show_engine_logs                          | 0           |
| Com_show_engine_mutex                         | 0           |
| Com_show_engine_status                        | 0           |
| Com_show_events                               | 0           |
| Com_show_errors                               | 0           |
| Com_show_fields                               | 0           |
| Com_show_function_code                        | 0           |
| Com_show_function_status                      | 0           |
| Com_show_grants                               | 0           |
| Com_show_keys                                 | 0           |
| Com_show_master_status                        | 0           |
| Com_show_open_tables                          | 0           |
| Com_show_plugins                              | 0           |
| Com_show_privileges                           | 0           |
| Com_show_procedure_code                       | 0           |
| Com_show_procedure_status                     | 0           |
| Com_show_processlist                          | 1           |
| Com_show_profile                              | 0           |
| Com_show_profiles                             | 0           |
| Com_show_relaylog_events                      | 0           |
| Com_show_slave_hosts                          | 0           |
| Com_show_slave_status                         | 0           |
| Com_show_status                               | 1           |
| Com_show_storage_engines                      | 0           |
| Com_show_table_status                         | 0           |
| Com_show_tables                               | 0           |
| Com_show_triggers                             | 0           |
| Com_show_variables                            | 0           |
| Com_show_warnings                             | 0           |
| Com_slave_start                               | 0           |
| Com_slave_stop                                | 0           |
| Com_stmt_close                                | 0           |
| Com_stmt_execute                              | 0           |
| Com_stmt_fetch                                | 0           |
| Com_stmt_prepare                              | 0           |
| Com_stmt_reprepare                            | 0           |
| Com_stmt_reset                                | 0           |
| Com_stmt_send_long_data                       | 0           |
| Com_truncate                                  | 0           |
| Com_uninstall_plugin                          | 0           |
| Com_unlock_tables                             | 0           |
| Com_update                                    | 0           |
| Com_update_multi                              | 0           |
| Com_xa_commit                                 | 0           |
| Com_xa_end                                    | 0           |
| Com_xa_prepare                                | 0           |
| Com_xa_recover                                | 0           |
| Com_xa_rollback                               | 0           |
| Com_xa_start                                  | 0           |
| Compression                                   | OFF         |
| Connection_errors_accept                      | 0           |
| Connection_errors_internal                    | 0           |
| Connection_errors_max_connections             | 0           |
| Connection_errors_peer_address                | 0           |
| Connection_errors_select                      | 0           |
| Connection_errors_tcpwrap                     | 0           |
| Connections                                   | 5           |
| Created_tmp_disk_tables                       | 0           |
| Created_tmp_files                             | 6           |
| Created_tmp_tables                            | 0           |
| Delayed_errors                                | 0           |
| Delayed_insert_threads                        | 0           |
| Delayed_writes                                | 0           |
| Flush_commands                                | 1           |
| Handler_commit                                | 0           |
| Handler_delete                                | 0           |
| Handler_discover                              | 0           |
| Handler_external_lock                         | 0           |
| Handler_mrr_init                              | 0           |
| Handler_prepare                               | 0           |
| Handler_read_first                            | 0           |
| Handler_read_key                              | 0           |
| Handler_read_last                             | 0           |
| Handler_read_next                             | 0           |
| Handler_read_prev                             | 0           |
| Handler_read_rnd                              | 0           |
| Handler_read_rnd_next                         | 0           |
| Handler_rollback                              | 0           |
| Handler_savepoint                             | 0           |
| Handler_savepoint_rollback                    | 0           |
| Handler_update                                | 0           |
| Handler_write                                 | 0           |
| Innodb_buffer_pool_dump_status                | not started |
| Innodb_buffer_pool_load_status                | not started |
| Innodb_buffer_pool_pages_data                 | 323         |
| Innodb_buffer_pool_bytes_data                 | 5292032     |
| Innodb_buffer_pool_pages_dirty                | 0           |
| Innodb_buffer_pool_bytes_dirty                | 0           |
| Innodb_buffer_pool_pages_flushed              | 1           |
| Innodb_buffer_pool_pages_free                 | 7866        |
| Innodb_buffer_pool_pages_misc                 | 2           |
| Innodb_buffer_pool_pages_total                | 8191        |
| Innodb_buffer_pool_read_ahead_rnd             | 0           |
| Innodb_buffer_pool_read_ahead                 | 0           |
| Innodb_buffer_pool_read_ahead_evicted         | 0           |
| Innodb_buffer_pool_read_requests              | 2642        |
| Innodb_buffer_pool_reads                      | 324         |
| Innodb_buffer_pool_wait_free                  | 0           |
| Innodb_buffer_pool_write_requests             | 1           |
| Innodb_data_fsyncs                            | 5           |
| Innodb_data_pending_fsyncs                    | 0           |
| Innodb_data_pending_reads                     | 0           |
| Innodb_data_pending_writes                    | 0           |
| Innodb_data_read                              | 5378048     |
| Innodb_data_reads                             | 336         |
| Innodb_data_writes                            | 5           |
| Innodb_data_written                           | 34304       |
| Innodb_dblwr_pages_written                    | 1           |
| Innodb_dblwr_writes                           | 1           |
| Innodb_have_atomic_builtins                   | ON          |
| Innodb_log_waits                              | 0           |
| Innodb_log_write_requests                     | 0           |
| Innodb_log_writes                             | 1           |
| Innodb_os_log_fsyncs                          | 3           |
| Innodb_os_log_pending_fsyncs                  | 0           |
| Innodb_os_log_pending_writes                  | 0           |
| Innodb_os_log_written                         | 512         |
| Innodb_page_size                              | 16384       |
| Innodb_pages_created                          | 0           |
| Innodb_pages_read                             | 323         |
| Innodb_pages_written                          | 1           |
| Innodb_row_lock_current_waits                 | 0           |
| Innodb_row_lock_time                          | 0           |
| Innodb_row_lock_time_avg                      | 0           |
| Innodb_row_lock_time_max                      | 0           |
| Innodb_row_lock_waits                         | 0           |
| Innodb_rows_deleted                           | 0           |
| Innodb_rows_inserted                          | 0           |
| Innodb_rows_read                              | 0           |
| Innodb_rows_updated                           | 0           |
| Innodb_num_open_files                         | 5           |
| Innodb_truncated_status_writes                | 0           |
| Innodb_available_undo_logs                    | 128         |
| Key_blocks_not_flushed                        | 0           |
| Key_blocks_unused                             | 13396       |
| Key_blocks_used                               | 0           |
| Key_read_requests                             | 0           |
| Key_reads                                     | 0           |
| Key_write_requests                            | 0           |
| Key_writes                                    | 0           |
| Last_query_cost                               | 0.000000    |
| Last_query_partial_plans                      | 0           |
| Max_used_connections                          | 1           |
| Not_flushed_delayed_rows                      | 0           |
| Open_files                                    | 16          |
| Open_streams                                  | 0           |
| Open_table_definitions                        | 67          |
| Open_tables                                   | 60          |
| Opened_files                                  | 115         |
| Opened_table_definitions                      | 0           |
| Opened_tables                                 | 0           |
| Performance_schema_accounts_lost              | 0           |
| Performance_schema_cond_classes_lost          | 0           |
| Performance_schema_cond_instances_lost        | 0           |
| Performance_schema_digest_lost                | 0           |
| Performance_schema_file_classes_lost          | 0           |
| Performance_schema_file_handles_lost          | 0           |
| Performance_schema_file_instances_lost        | 0           |
| Performance_schema_hosts_lost                 | 0           |
| Performance_schema_locker_lost                | 0           |
| Performance_schema_mutex_classes_lost         | 0           |
| Performance_schema_mutex_instances_lost       | 0           |
| Performance_schema_rwlock_classes_lost        | 0           |
| Performance_schema_rwlock_instances_lost      | 0           |
| Performance_schema_session_connect_attrs_lost | 0           |
| Performance_schema_socket_classes_lost        | 0           |
| Performance_schema_socket_instances_lost      | 0           |
| Performance_schema_stage_classes_lost         | 0           |
| Performance_schema_statement_classes_lost     | 0           |
| Performance_schema_table_handles_lost         | 0           |
| Performance_schema_table_instances_lost       | 0           |
| Performance_schema_thread_classes_lost        | 0           |
| Performance_schema_thread_instances_lost      | 0           |
| Performance_schema_users_lost                 | 0           |
| Prepared_stmt_count                           | 0           |
| Qcache_free_blocks                            | 1           |
| Qcache_free_memory                            | 16759680    |
| Qcache_hits                                   | 0           |
| Qcache_inserts                                | 0           |
| Qcache_lowmem_prunes                          | 0           |
| Qcache_not_cached                             | 1           |
| Qcache_queries_in_cache                       | 0           |
| Qcache_total_blocks                           | 1           |
| Queries                                       | 8           |
| Questions                                     | 3           |
| Select_full_join                              | 0           |
| Select_full_range_join                        | 0           |
| Select_range                                  | 0           |
| Select_range_check                            | 0           |
| Select_scan                                   | 0           |
| Slave_heartbeat_period                        |             |
| Slave_last_heartbeat                          |             |
| Slave_open_temp_tables                        | 0           |
| Slave_received_heartbeats                     |             |
| Slave_retried_transactions                    |             |
| Slave_running                                 | OFF         |
| Slow_launch_threads                           | 0           |
| Slow_queries                                  | 0           |
| Sort_merge_passes                             | 0           |
| Sort_range                                    | 0           |
| Sort_rows                                     | 0           |
| Sort_scan                                     | 0           |
| Ssl_accept_renegotiates                       | 0           |
| Ssl_accepts                                   | 0           |
| Ssl_callback_cache_hits                       | 0           |
| Ssl_cipher                                    |             |
| Ssl_cipher_list                               |             |
| Ssl_client_connects                           | 0           |
| Ssl_connect_renegotiates                      | 0           |
| Ssl_ctx_verify_depth                          | 0           |
| Ssl_ctx_verify_mode                           | 0           |
| Ssl_default_timeout                           | 0           |
| Ssl_finished_accepts                          | 0           |
| Ssl_finished_connects                         | 0           |
| Ssl_server_not_after                          |             |
| Ssl_server_not_before                         |             |
| Ssl_session_cache_hits                        | 0           |
| Ssl_session_cache_misses                      | 0           |
| Ssl_session_cache_mode                        | NONE        |
| Ssl_session_cache_overflows                   | 0           |
| Ssl_session_cache_size                        | 0           |
| Ssl_session_cache_timeouts                    | 0           |
| Ssl_sessions_reused                           | 0           |
| Ssl_used_session_cache_entries                | 0           |
| Ssl_verify_depth                              | 0           |
| Ssl_verify_mode                               | 0           |
| Ssl_version                                   |             |
| Table_locks_immediate                         | 70          |
| Table_locks_waited                            | 0           |
| Table_open_cache_hits                         | 0           |
| Table_open_cache_misses                       | 0           |
| Table_open_cache_overflows                    | 0           |
| Tc_log_max_pages_used                         | 0           |
| Tc_log_page_size                              | 0           |
| Tc_log_page_waits                             | 0           |
| Threads_cached                                | 0           |
| Threads_connected                             | 1           |
| Threads_created                               | 1           |
| Threads_running                               | 1           |
| Uptime                                        | 147542      |
| Uptime_since_flush_status                     | 147542      |
+-----------------------------------------------+-------------+
341 rows in set (0,00 sec) 

Подробное описание команды

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

  • Aborted_clients — Количество соединений, отмененных по причине отключения клиента без надлежащего закрытия соединения. See Раздел A.2.9, «Коммуникационные ошибки / Оборванные соединения».
  • Aborted_connects — Количество неудачных попыток подсоединения к серверу MySQL. See Раздел A.2.9, «Коммуникационные ошибки / Оборванные соединения».
  • Bytes_received — Количество байтов, полученных от всех клиентов.
  • Bytes_sent — Количество байтов, отправленных всем клиентам.
  • Com_xxx — Количество запусков каждой команды xxx.
  • Connections — Количество попыток подсоединения к серверу MySQL.
  • Created_tmp_tables — Количество неявных временных таблиц на диске, созданных во время выполнения операторов.
  • Created_tmp_tables — Количество неявных временных таблиц в памяти, созданных во время выполнения операторов.
  • Created_tmp_files — Количество созданных временных файлов mysqld.
  • Delayed_insert_threads — Количество используемых потоков вставки данных в режиме insert delayed.
  • Delayed_writes — Количество строк, вставленных при помощи команды INSERT DELAYED.
  • Delayed_errors — Количество записанных при помощи команды INSERT DELAYED строк, в которых произошли какие-либо ошибки (возможно, duplicate key).
  • Flush_commands — Количество запущенных команд FLUSH.
  • Handler_commit — Количество внутренних команд COMMIT.
  • Handler_delete — Количество удалений строки из таблицы.
  • Handler_read_first — Количество считываний из индекса первой записи. Если это значение высокое, то, по всей вероятности, сервер осуществляет много полных индексных сканирований, например, SELECT col1 FROM foo, предполагая, что col1 проиндексирован.
  • Handler_read_key — Количество запросов на чтение строки, основанных на ключе. Высокое значение переменной говорит о том, что ваши запросы и таблицы проиндексированы надлежащим образом.
  • Handler_read_next — Количество запросов на чтение следующей строки в порядке расположения ключей. Это значение будет увеличиваться, если производится запрос индексного столбца с ограничением по размеру. Значение также увеличивается во время проведения индексного сканирования.
  • Handler_read_prev — Количество запросов на чтение предыдущей строки в порядке расположения ключей. В большинстве случаев используется для оптимизации ORDER BY … DESC.
  • Handler_read_rnd — Количество запросов на чтение строки, основанных на фиксированной позиции. Значение будет высоким, если выполняется много запросов, требующих сортировки результатов.
  • Handler_read_rnd_next — Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, если производится много сканирований таблиц. Обычно это означает, что ваши таблицы не проиндексированы надлежащим образом или ваши запросы не используют преимущества индексов.
  • Handler_rollback — Количество внутренних команд ROLLBACK.
  • Handler_update — Количество запросов на обновление строки в таблице.
  • Handler_write — Количество запросов на вставку строки в таблицу.
  • Key_blocks_used — Количество используемых блоков в кэше ключей.
  • Key_read_requests — Количество запросов на чтение блока ключей из кэша.
  • Key_reads — Количество физических считываний блока ключей с диска.
  • Key_write_requests — Количество запросов на запись блока ключей в кэш.
  • Key_writes — Количество физических записей блоков ключей на диск.
  • Max_used_connections — Максимальное количество одновременно используемых соединений.
  • Not_flushed_key_blocks — Блоки ключей в кэше ключей, которые были изменены, но еще не записаны на диск.
  • Not_flushed_delayed_rows — Количество строк, стоящих в очереди на запись в запросах INSERT DELAY.
  • Open_tables — Количество открытых таблиц.
  • Open_files — Количество открытых файлов.
  • Open_streams — Количество открытых потоков (в основном используется для журналирования).
  • Opened_tables — Количество открывавшихся таблиц.
  • Rpl_status — Статус отказобезопасной репликации (еще не используется).
  • Select_full_join — Количество соединений без ключей (если это значение равно 0, необходимо внимательно проверить индексы своих таблиц).
  • Select_full_range_join — Количество соединений, где был использован поиск по диапазону в справочной таблице.
  • Select_range — Количество соединений, в которых использовались диапазоны в первой таблице. (Обычно это значение не критично, даже если оно велико)
    Select_scan — Количество соединений, в которых проводилось первое сканирование первой таблицы.
  • Select_range_check — Количество соединений без ключей, в которых проверка использования ключей производится после каждой строки (если это значение равно 0, необходимо внимательно проверить индексы своих таблиц).
  • Questions — Количество запросов, направленных на сервер.
  • Slave_open_temp_tables — Количество временных таблиц, открытых в настоящий момент потоком подчиненного компьютера.
  • Slave_running — Содержит значение ON, если это подчиненный компьютер, подключенный к головному компьютеру.
  • Slow_launch_threads — Количество потоков, создание которых заняло больше, чем указано в slow_launch_time.
  • Slow_queries — Количество запросов, обработка которых заняла больше времени, чем long_query_time. See Раздел 4.9.5, «Журнал медленных запросов».
  • Sort_merge_passes — Количество объединений, осуществленных алгоритмом сортировки. Если это значение велико, следует увеличить sort_buffer_size.
  • Sort_range — Количество сортировок, которые осуществлялись в диапазонах.
  • Sort_rows — Количество отсортированных строк.
  • Sort_scan — Количество сортировок, осуществленных путем сканирования таблицы.
  • ssl_xxx — Переменные, используемые SSL; еще не реализовано.
  • Table_locks_immediate — Количество запросов на немедленную блокировку таблицы. Доступно начиная с версии 3.23.33.
  • Table_locks_waited — Количество запросов, когда немедленная блокировка не могла быть осуществлена и требовалось время на ожидание. Если это значение велико, и у вас есть проблемы с производительностью, сначала необходимо оптимизировать свои запросы, а затем либо разделить таблицы, либо использовать репликацию. Доступно начиная с версии 3.23.33.
  • Threads_cached — Количество потоков в кэше потоков.
  • Threads_connected — Количество открытых в настоящий момент соединений.
  • Threads_created — Количество потоков, созданных для управления соединениями.
  • Threads_running — Количество не простаивающих потоков.
  • Uptime — Время в секундах, в течение которого сервер находится в работе.

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

  • Если значение 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, чтобы временные таблицы располагались в памяти, а не на жестком диске.

show processlist — показывает, какие потоки запущены в настоящий момент. Пример ее вывода:

mysql&gt; show processlist;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+------+---------+------+-------+------------------+
| 4 | root | localhost | NULL | Query | 0 | init | show processlist |
+----+------+-----------+------+---------+------+-------+------------------+
1 row in set (0,00 sec) 

Подробное описание команды

Команда SHOW [FULL] PROCESSLIST показывает, какие потоки запущены в настоящий момент. Эту информацию также можно получить при помощи команды mysqladmin processlist. Если у вас привилегия SUPER, можно просматривать все потоки, в противном случае — только свои потоки. See Раздел 4.5.5, «Синтаксис команды KILL». Если не используется параметр FULL, будут показаны только первые 100 символов каждого запроса.

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

Эта команда очень полезна, если выдается сообщение об ошибке ‘too many connections’ (слишком много соединений) и необходимо выяснить, что происходит. MySQL резервирует одно дополнительное соединение для клиента с привилегией SUPER, чтобы у вас всегда была возможность войти в систему и произвести проверку (предполагается, что вы не станете раздавать эту привилегию всем своим пользователям).

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

  • Checking table — Поток осуществляет [автоматическую] проверку таблицы.
  • Closing tables — Означает, что поток записывает измененные данные таблиц на диск и закрывает использующиеся таблицы. Выполнение этой операции должно произойти быстро. Если на нее уходит значительное время, убедитесь, что диск не переполнен или что диск не используется слишком интенсивно.
  • Connect Out — Подчиненный компьютер, подсоединенный к головному компьютеру.
  • Copying to tmp table on disk — Набор временных результатов превысил tmp_table_size, и теперь поток изменяет таблицу временных данных, расположенную в памяти, на дисковую таблицу, чтобы сохранить память.
  • Creating tmp table — Поток создает временную таблицу, чтобы хранить часть результатов для запроса.
  • deleting from main table — При запуске первой части удаления нескольких таблиц удаление производится только начиная с первой таблицы.
  • deleting from reference tables — При запуске второй части удаления нескольких таблиц удаляются совпадающие строки из других таблиц.
  • Flushing tables — Поток запускает команду FLUSH TABLES и ожидает, пока все потоки закроют свои таблицы.
  • Killed — Кто-то направил команду на закрытие потока, и поток будет закрыт при следующей проверке флага закрытия. Флаг проверяется при каждом основном цикле в MySQL, но в некоторых случаях закрытие потока может занять некоторое время. Если поток заблокирован другим потоком, закрытие будет произведено сразу после того, как другой поток снимет блокировку.
  • Sending data — Поток обрабатывает строки для оператора SELECT, а также направляет данные клиенту.
  • Sorting for group — Поток осуществляет сортировку в соответствии с GROUP BY.
  • Sorting for order — Поток осуществляет сортировку в соответствии с ORDER BY.
  • Opening tables — Это просто означает, что поток пытается открыть таблицу. Такая процедура осуществляется довольно быстро, если что-либо не мешает открытию. Например, команды ALTER TABLE или LOCK TABLE могут помешать открытию таблицы, пока выполнение команды не будет завершено.
  • Removing duplicates — Запрос использовал команду SELECT DISTINCT таким образом, что MySQL не смог произвести оптимизацию на начальном этапе. Поэтому MySQL перед отправкой результатов клиенту должен выполнить дополнительное удаление всех дублирующихся строк.
  • Reopen table — Поток заблокировал таблицу, но обнаружил, что после блокировки структура таблицы изменилась. Он снял блокировку, закрыл таблицу и теперь пытается повторно ее открыть.
  • Repair by sorting — Код восстановления использует сортировку для создания индексов.
  • Repair with keycache — Код восстановления использует создание ключей один за другим, через кэш ключей. Это намного медленнее, чем Repair by sorting.
  • Searching rows for update — Поток осуществляет первую фазу — производит поиск всех совпадающих строк, чтобы затем обновить их. Это действие
    необходимо выполнить, если команда UPDATE изменяет индекс, который используется для поиска указанных строк.
  • Sleeping — Поток ожидает, когда клиент направит ему новую команду.
  • System lock — Поток ожидает получения внешней системной блокировки таблицы. Если не используется несколько серверов mysqld, которые получают доступ к одним и тем же таблицам, системную блокировку можно отключить при помощи параметра —skip-external-locking.
  • Upgrading lock — Обработчик INSERT DELAYED пытается заблокировать таблицу, чтобы вставить строки.
  • Updating — Поток производит поиск строк, которые необходимо обновить, и обновляет их.
  • User Lock — Поток ожидает GET_LOCK().
  • Waiting for tables — Поток получил уведомление, что структура таблицы изменилась, и ему необходимо повторно открыть таблицу, чтобы получить новую структуру. Чтобы повторно открыть таблицу, он должен подождать, пока ее не закроют все остальные потоки. Это уведомление выдается, если другой поток воспользовался командой FLUSH TABLES или к таблице была применена одна из следующих команд: FLUSH TABLES table_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE или OPTIMIZE TABLE. Обработчик INSERT DELAYED завершил работу со всеми вставками и ожидает новые.

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

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

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

Источники:

  • https://ruhighload.com/post/бла-бла-бла-1
  • https://ruhighload.com/post/бла-бла-бла-2
  • https://dev.mysql.com/doc/refman/5.7/en/perror.html
  • https://unixforum.org/index.php?showtopic=92923
  • http://www.arininav.ru/mysql/show-status.html
  • http://www.arininav.ru/mysql/show-processlist.html

Список

  • Общий журнал — все запросы — см. VARIABLE general_log
  • Медленный журнал — запросы медленнее, чем long_query_time — slow_query_log_file
  • Binlog — для репликации и резервного копирования — log_bin_basename
  • Журнал ретрансляции — также для репликации
  • общие ошибки — mysqld.err
  • start / stop — mysql.log (не очень интересно) — log_error
  • Журнал изменений InnoDB — iblog *

См. Переменные basedir и datadir для местоположения по умолчанию для многих журналов

Некоторые журналы включаются и выключаются другими ПЕРЕМЕННЫМИ. Некоторые из них либо записываются в файл, либо в таблицу.

(Примечание для рецензентов: для этого требуется более подробная информация и пояснения.)

Документаторы : укажите расположение и имя по умолчанию для каждого типа журнала, как для Windows, так и для * nix. (Или, по крайней мере, столько, сколько сможете).

Медленный журнал запросов

Журнал медленных запросов состоит из журнальных событий для запросов, long_query_time до long_query_time . Например, до 10 секунд для завершения. Чтобы увидеть установленный порог времени, выполните следующие действия:

SELECT @@long_query_time;
+-------------------+
| @@long_query_time |
+-------------------+
|         10.000000 |
+-------------------+

Его можно установить как переменную GLOBAL в файле my.cnf или my.ini . Или это может быть установлено связью, хотя это необычно. Значение может быть установлено в диапазоне от 0 до 10 (в секундах). Какую ценность использовать?

  • 10 настолько высока, что почти бесполезна;
  • 2 — компромисс;
  • 0,5 и другие фракции;
  • 0 захватывает все; это может залить диск опасно быстро, но может быть очень полезно.

Захват медленных запросов включается или выключается. И указанный файл также указан. Ниже приведены следующие понятия:

SELECT @@slow_query_log; -- Is capture currently active? (1=On, 0=Off)
SELECT @@slow_query_log_file; -- filename for capture. Resides in datadir
SELECT @@datadir; -- to see current value of the location for capture file

SET GLOBAL slow_query_log=0; -- Turn Off
-- make a backup of the Slow Query Log capture file. Then delete it.
SET GLOBAL slow_query_log=1; -- Turn it back On (new empty file is created)

Для получения дополнительной информации см. Страницу руководства MySQL. Журнал медленных запросов

Примечание: приведенная выше информация о включении / выключении замедления была изменена в 5.6 (?); у старой версии был другой механизм.

«Лучший» способ увидеть, что замедляет вашу систему:

long_query_time=...
turn on the slowlog
run for a few hours
turn off the slowlog (or raise the cutoff)
run pt-query-digest to find the 'worst' couple of queries.  Or mysqldumpslow -s t

Общий журнал запросов

Общий журнал запросов содержит листинг общей информации от клиентских подключений, разъединений и запросов. Это бесценно для отладки, но это создает препятствия для работы (цитата?).

Пример просмотра общего журнала запросов приведен ниже:

введите описание изображения здесь

Чтобы определить, записывается ли в настоящий момент общий журнал:

SELECT @@general_log; -- 1 = Capture is active; 0 = It is not.

Чтобы определить имя файла захвата:

SELECT @@general_log_file; -- Full path to capture file

Если полный путь к файлу не отображается, файл существует в datadir .

Пример Windows:

+----------------------------------------------------------+
| @@general_log_file                                       |
+----------------------------------------------------------+
| C:ProgramDataMySQLMySQL Server 5.7DataGuySmiley.log |
+----------------------------------------------------------+

Linux:

+-----------------------------------+
| @@general_log_file                |
+-----------------------------------+
| /var/lib/mysql/ip-ww-xx-yy-zz.log |
+-----------------------------------+

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

В случае отсутствия записи для файла general_log_file в файле конфигурации по умолчанию будет @@hostname .log в datadir .

Лучшая практика — отключить захват. Сохраните файл журнала в резервном каталоге с именем файла, отражающим дату и время начала и окончания захвата. Удаление предыдущего файла, если перемещение файловой системы не произошло из этого файла. Установите новое имя файла для файла журнала и включите захват (все показано ниже). Лучшие практики также включают тщательное определение, даже если вы хотите захватить на данный момент. Как правило, захват включен только для целей отладки.

Типичным именем файла файловой системы для резервного архива может быть:

/LogBackup/GeneralLog_20160802_1520_to_20160802_1815.log

где дата и время являются частью имени файла как диапазона.

Для Windows обратите внимание на следующую последовательность изменений настроек.

SELECT @@general_log; -- 0. Not being captured
SELECT @@general_log_file; -- C:ProgramDataMySQLMySQL Server 5.6DataGuySmiley.log
SELECT @@datadir; -- C:ProgramDataMySQLMySQL Server 5.7Data
SET GLOBAL general_log_file='GeneralLogBegin_20160803_1420.log'; -- datetime clue
SET GLOBAL general_log=1; -- Turns on actual log capture. File is created under `datadir`
SET GLOBAL general_log=0; -- Turn logging off

Linux похож. Они будут представлять собой динамические изменения. Любой перезапуск сервера подбирает настройки файла конфигурации.

Что касается файла конфигурации, рассмотрите следующие соответствующие параметры переменной:

[mysqld]
general_log_file = /path/to/currentquery.log
general_log      = 1

Кроме того, переменную log_output можно настроить для вывода TABLE , а не только FILE . Для этого, пожалуйста, см. « Направления» .

См. Страницу руководства MySQL . Общий журнал запросов .

Журнал ошибок

Журнал ошибок заполняется информацией о запуске и остановке и критическими событиями, встречающимися на сервере.

Ниже приведен пример его содержимого:

введите описание изображения здесь

Переменная log_error содержит путь к файлу журнала для регистрации ошибок.

В отсутствие записи файла конфигурации для log_error система будет по умолчанию использовать значения @@hostname .err в datadir . Обратите внимание, что log_error не является динамической переменной. Таким образом, изменения выполняются с помощью изменений файла cnf или ini и перезапуска сервера (или путем просмотра «Промывка и переименование файла журнала ошибок» на странице «Ручная страница» внизу).

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

GLOBAL-переменная log_warnings устанавливает уровень для многословия, который зависит от версии сервера. Следующий фрагмент иллюстрирует:

SELECT @@log_warnings; -- make a note of your prior setting
SET GLOBAL log_warnings=2; -- setting above 1 increases output (see server version)

log_warnings как показано выше, является динамической переменной.

Изменения файла конфигурации в файлах cnf и ini могут выглядеть следующим образом.

[mysqld]
log_error        = /path/to/CurrentError.log
log_warnings     = 2

MySQL 5.7.2 расширил многословие уровня предупреждения до 3 и добавил GLOBAL log_error_verbosity . Опять же, оно было введено в 5.7.2. Он может быть установлен динамически и проверен как переменная или задан с помощью настроек файла конфигурации cnf или ini .

Начиная с MySQL 5.7.2:

[mysqld]
log_error           = /path/to/CurrentError.log
log_warnings        = 2
log_error_verbosity = 3 

Пожалуйста, обратитесь к странице руководства по MySQL, озаглавленной « Журнал ошибок», особенно для флеширования и переименования файла журнала ошибок, а также в разделе « Подробный журнал ошибок » с версиями, связанными с log_warnings и error_log_verbosity .

Thank you for reading this post, don’t forget to subscribe!

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

shell&gt; 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

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

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

# — 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&gt;/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.

https://github.com/midnight47/

Although only available as a release candidate, MySQL 8 is already proving to be a huge leap forward in many regards. Error logging is no exception. The MySQL development team just announced that they have redesigned the error logging subsystem to use a new component architecture.

The redesign will allow the filtering of log events, as well as the routing of error log output to multiple destinations via the enabling of multiple sink components. This will make it possible to send error log events to third-party systems for additional formatting and analysis.

In today’s article, we’ll explore how to employ MySQL 8’s component-based error logging to achieve a variety of logging configurations. Note that all this is specific for MySQL 8 and is not available in earlier versions and also not in MariaDB. However, MariaDB has an option to write the error log to the system “syslog” on systemd-based Linux variants — which includes all common Linux distributions released in the last few years. This option is not available in MySQL.

Component Architecture

MySQL Server now includes a component-based architecture. This will facilitate the management of server capabilities through the installing and un-installing of specific components.

The component-based architecture is more modular in that components only interact with each other through the services they provide. The services provided by components are available to the server as well as to other components.

With respect to the error log, a log component can be a filter or a sink:

  • A filter processes log events to add, remove, or modify individual event fields or to delete events entirely.
  • A sink is a destination (writer) for log events. Typically, a sink processes log events into log messages that have a particular format and writes these messages to its associated output, such as a file or the system log.

You can view the error log configuration by querying the global_variables table. Error log variables are prefixed with log_error_:

select * from global_variables where VARIABLE_NAME like 'log_error_%';

+---------------------+----------------------------------------+
| VARIABLE_NAME       | VARIABLE_VALUE                         |
+---------------------+----------------------------------------+
| log_error_services  | log_filter_internal; log_sink_internal |
| log_error_verbosity | 2                                      |
+---------------------+----------------------------------------+

The server executes filters and sinks in the log_error_services value in the order they are listed. By default, log events will first pass through log_filter_internal (the built-in filter component), followed by log_sink_internal (the built-in log writer component).

Component Types

Available log components reside in the lib/plugins directory and have an .so extension on Linux (and a .dll extension on Windows):

  • component_log_filter_dragnet.so
  • component_log_sink_json.so
  • component_log_sink_syseventlog.so
  • component_log_sink_test.so

To load a component, you refer to its URN. This is file:// plus the component filename without the .so extension. Each component’s respective URN is listed in the next section.

Error Log Filter Components

Error log filter components implement filtering of error log events. If no filter component is enabled, no filtering occurs. Otherwise, any enabled filter component affects log events only for components listed later in the log_error_services variable.

There are two log filter components:

  1. The log_filter_internal component: It implements filtering based on the log_error_verbosity system variable setting. This component is built-in so it does not need to be loaded via INSTALL COMPONENT before use. Note that although log_error_verbosity affects the log_filter_internal component,log_error_verbosity has no effect on logging if log_filter_internal is not enabled.
  2. The log_filter_dragnet component:It implements filtering based on the rules defined by the dragnet.log_error_filter_rules system variable setting. Its URN is file://component_log_filter_dragnet.

Error Log Sink Components

Error log sink components are writers that implement error log output. If no sink component is enabled, no log output occurs.

Some sink component descriptions refer to the default error log destination. This is the console or a file and is indicated by the fault of the log_error system variable.

There are four log sink components:

  1. The log_sink_internal component:It implements traditional error log message output format. This component is built-in so it does not need to be loaded via INSTALL COMPONENT before use. The output is routed to the default error log destination.
  2. The log_sink_json component:It implements JSON-format error logging. Its URN is file://component_log_sink_json. The JSON log writer determines its output destination based on the default error log destination, which is given by the log_error system variable.
  3. The log_sink_syseventlog component:It implements error logging to the system log. This is the event log on Windows, and syslog on UNIX and UNIX-like systems, such as Linux. Its URN is file://component_log_sink_syseventlog. The output is written to the system log rather than the default error log destination.
  4. The log_sink_test component:It’s intended for internal use in writing test cases and is not recommended for production use. Its URN is file://component_log_sink_test. The output destination is the default error log.

Enabling a Log Component

To enable a log component, you would first load it using INSTALL COMPONENT, then list the component in the log_error_services value.

For example, to use the system log writer (log_sink_syseventlog) instead of the default writer (log_sink_internal), we would first load the writer component, then modify the log_error_services value:

INSTALL COMPONENT 'file://component_log_sink_syseventlog';
SET GLOBAL log_error_services = 'log_filter_internal; log_sink_syseventlog';

One of the great things about the new error log architecture is that it’s possible to configure multiple log writers to send output to multiple destinations. For instance, to enable the system log writer in addition to the default writer, set the log_error_services value like so:

SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal; log_sink_syseventlog';

Here’s another example to load the JSON component writer:

INSTALL COMPONENT 'file://component_log_sink_json';

SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal; log_sink_json';

mysql> select * from global_variables where VARIABLE_NAME like 'log_error_%';

+---------------------+-------------------------------------------------------+
| VARIABLE_NAME       | VARIABLE_VALUE                                        |
+---------------------+-------------------------------------------------------+
| log_error_services  | log_filter_internal; log_sink_internal; log_sink_json |
| log_error_verbosity | 2                                                     |
+---------------------+-------------------------------------------------------+

A few more things to keep in mind regarding the JSON writer:

  • If log_error names a file, the JSON writer bases the output file naming on that file name, plus a numbered .NN.json suffix, with NN starting at 00. For example, if log_error is my_log_file, successive instances of log_sink_json named in the log_error_servicesvalue write to my_log_file.00.json, my_log_file.01.json, and so on.
  • If log_error is set to stderr, the JSON writer writes to the console by default. Even if log_json_writer is named multiple times in the log_error_services value, they all write to the console, which is not terribly useful.

Configuring a Log Component to Be Enabled at Server Startup

In most cases, you’ll want your error logging configuration to persist across server restarts. This can be achieved in a couple of ways:

  1. Load the component using INSTALL COMPONENT. This registers it in the mysql.component system table so that the server loads the component automatically for subsequent startups.
  2. Set the log_error_services value at startup to include the component name. You can set the value in the server my.cnf file.

As an example, suppose that you wanted to configure your MySQL server to use the JSON log writer (log_sink_json) in addition to the built-in log filter and writer (log_filter_internal, log_sink_internal). First, load the JSON writer:

INSTALL COMPONENT 'file://component_log_sink_json';

Then, in the my.cnf file, set log_error_services to take effect at server startup:

[mysqld]
log_error_services='log_filter_internal; log_sink_internal; log_sink_json'

SET PERSIST log_error_services = 'log_filter_internal; log_sink_internal; log_sink_json';

Either will work, but note that values set in my.cnf only take effect at the next restart, while those set using SET PERSIST take effect immediately, as well as for subsequent restarts.

Uninstalling a Log Component

To uninstall a log component, use the UNINSTALL COMPONENT command.

For example, to revert to using only the default writer and unload the system log writer, execute these statements:

SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal;
UNINSTALL COMPONENT 'file://component_log_sink_syseventlog';

Error Log Message Formats

Each error log component writes messages to its destination using its own individual output format, although other factors, such as system variables, may also influence the content of the messages.

For all log writers, the ID included in error log messages is that of the thread within the mysqld process responsible for writing the message (the connection thread ID). This indicates which part of the server produced the message and is consistent with general query log and slow query log messages, which also include the connection thread ID.

Besides the common ID field, log_sink_internal, log_sink_json, and log_sink_syseventlog each employ their own output format.

Output Format for log_sink_internal

This log writer produces the traditional error log output using this format:

timestamp thread_id [severity] [err_code] [subsystem] message1

Note: The square bracket characters [ … ] are literal characters that appear in the message format and do not indicate that fields are optional, as they would in function parameter notation.

[err_code] and [subsystem] are new fields that were added in MySQL 8.0.4 and 8.0.5, respectively. Hence, they will be absent from logs generated by older servers. The err_code is a string value as it is made up of alphanumeric characters.

Here’s some example output:

2018-03-29T14:22:01.538083Z 0 [Note] [MY-012487] [InnoDB] InnoDB: DDL log recovery : begin

2018-03-29T14:22:01.538083Z 0 [Warning] [MY-010068] [Server] CA certificate /var/mysql/sslinfo/mycert.pem is self signed.

2018-03-29T14:22:01.538083Z 4 [Note] [MY-010051] [Server] Event Scheduler: scheduler thread started with id 4

2018-03-29T14:22:01.538083Z 0 [Note] [MY-010253] [Server] IPv6 is available.

Output Format for log_sink_json

The JSON format log writer produces messages as JSON objects that contain key/value pairs. For example:

{ "prio": 3, "err_code": 10051, "subsystem": "Server",

  "source_file": "event_scheduler.cc", "function": "run",

  "msg": "Event Scheduler: scheduler thread started with id 4",

  "time": "2018-03-22T12:35:47.669397Z", "thread": 4,

  "err_symbol": "ER_SCHEDULER_STARTED", "SQL_state": "HY000",

  "label": "Note" }

Notice that the content is produced as a one-line string, without line breaks.

Output Format for log_sink_syseventlog

The system log writer produces output that conforms to the specific system log format used on the local platform, i.e. the Windows Event Log.

Factors Affecting Error Log Format

As mentioned above, there are a couple of factors that may influence the content of Error Log messages:

  • Information available to the log writer: If a log filter component executed prior to the writer component removes a log event attribute for whatever reason, that attribute will no longer be available for writing.
  • log_timestamps system variable: The log_timestamps system variable controls the time zone of timestamps in messages written to all logs, including the error log, general query log, and slow query log files. Permitted values include “UTC” (the default) and “SYSTEM” (local system time zone).

Using Rule-Based Error Log Filtering

MySQL 8’s new error log service allows you to use components to filter the events according to your own rules, using the log_filter_dragnet component.

Usually, the error log configuration includes one log filter component and one or more log writer components. As mentioned in Error Log Filter Components section, MySQL includes two log filter components: log_filter_internal and log_filter_dragnet.

Priority vs. Rules Based Filtering

The log_filter_internal component employs priority filtering based on the log_error_verbosityvalue.

Permitted log_error_verbosity values are:

  • 1: Log errors only
  • 2: Log errors and warnings
  • 3: Log errors, warnings, and notes

The log_filter_internal system variable is built in and enabled by default but can be disabled. In the disabled state, changes to log_error_verbosity have no effect.

Important system messages about non-error situations are sent to the error log regardless of the log_error_verbosity value. These messages include startup and shutdown messages, and certain significant changes to settings.

If log_error_verbosity is set to two or greater, the server logs messages about statements that are unsafe for statement-based logging. In general, a statement is considered “safe” if it deterministic, i.e. always produces the same result for the same input, and “unsafe” if it is not. For example, statements containing system functions that may return a different value on slave such as FOUND_ROWS(), GET_LOCK(), IS_FREE_LOCK(), etc., would be considered nondeterministic, and thus, unsafe. Conversely, some nondeterministic functions, including CONNECTION_ID(), CURDATE(), CURRENT_DATE(), etc., are treated as safe for purposes of logging and replication. In addition, statements using results from floating-point math functions — which are hardware-dependent — are always considered unsafe.

If the value is 3, the server logs everything — from serious errors to aborted connections and access-denied errors for new connection attempts.

Filtering rules for the log_filter_dragnet component are defined by setting the dragnet.log_error_filter_rules system variable.

To enable the log_filter_dragnet filter, first load the filter component, then modify the log_error_services value. The following example adds your custom ruleset first in the chain, and the JSON log writer last:

INSTALL COMPONENT 'file://component_log_filter_dragnet'

SET GLOBAL log_error_services = 'log_filter_dragnet; 

log_sink_internal; log_sink_json';

A rule set consists of zero or more rules, where each rule is an IF statement terminated by a period (.) character. If the variable value is empty (zero rules), no filtering occurs.

Here’s a rule set that drops information events, and, for other events, removes the source_linefield:

SET GLOBAL dragnet.log_error_filter_rules =

  'IF prio>=INFORMATION THEN drop. IF EXISTS source_line THEN unset source_line.';

This rule limits information events to no more than one per 60 seconds:

SET GLOBAL dragnet.log_error_filter_rules = 

  'IF prio>=INFORMATION THEN throttle 1/60.';

Like other error-logging system variables, the log_filter_dragnet filter and dragnet.log_error_filter_rules can be enabled at server startup. To make your ruleset persist across server restarts, you should assign dragnet.log_error_filter_rules using SET PERSIST, as opposed to SET GLOBAL, as we did here. Alternatively, you can also add the setting to the server option file. See the «Configuring a Log Component to be Enabled at Server Startup» section above for instructions.

To turn off your custom filtering, you would remove the log_filter_dragnet filter from the set of error logging components, usually by setting a different and/or default filter component (rather than no filter component). For example:

SET GLOBAL log_error_services = 'log_filter_internal; log_sink_internal';

Don’t forget to use SET PERSIST if you want the setting to persist across server restarts!

Finally, uninstall the filter log_filter_dragnet component:

UNINSTALL COMPONENT 'file://component_log_filter_dragnet';

Conclusion

MySQL 8’s new component-based error logging architecture opens up a world of possibilities for customized error logging and routing. In a future blog, we’ll learn how to analyze error log messages using the Monyog MySQL Monitoring Tool.

Понравилась статья? Поделить с друзьями:

Не пропустите эти материалы по теме:

  • Яндекс еда ошибка привязки карты
  • Журнал ошибок bsod
  • Жить стало лучше жить стало веселее ошибка
  • Жители калинова живут замкнуто тип ошибки
  • Жители калинова живут замкнуто лексическая ошибка

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии