Journalctl xe for details где посмотреть

Форум русскоязычного сообщества Ubuntu

Страница сгенерирована за 0.036 секунд. Запросов: 25.

• Сайт
• Об Ubuntu
• Скачать Ubuntu
• Семейство Ubuntu
• Новости

• Форум
• Помощь
• Правила

• Документация
• Пользовательская документация
• Официальная документация
• Семейство Ubuntu
• Материалы для загрузки
• Совместимость с оборудованием
• RSS лента

• Сообщество
• Наши проекты
• Местные сообщества
• Перевод Ubuntu
• Тестирование
• RSS лента

© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

journalctl — утилита просмотра системного журнала

journalctl — это консольная утилита для просмотра системного журнала ОС Linux, поэтому перед вводом команд подключитесь к контроллеру по SSH или отладочный порт.

Здесь приведены примеры, которые решают большинство задач. Полный список параметров смотрите командой journalctl —help и в документации на утилиту.

Перемещаться по выводу утилиты можно с помощью клавиш:

• q — выйти из просмотра.
• ↑ — вверх на одну строку.
• ↓ — вниз на одну строку.
• b — вверх на одну страницу
• Пробел — вниз на одну страницу
• g — перейти на первую строку
• / — поиск по журналу
• n — найти следующее вхождение
• N — найти предыдущее вхождение

Архив

journald при каждой загрузке создаёт новый журнал, а старый закрывает. Список доступных журналов можно посмотреть командой:

# journalctl --list-boots -2 301af672ad2b400fa9c6562a3403d179 Sat 2021-10-30 10:25:03 +04—Thu 2021-11-04 10:39:39 +04 -1 1238af7b5cfb4dd9a10bc54a1dd63067 Thu 2021-11-04 10:39:53 +04—Thu 2021-11-04 13:42:19 +04 0 cc99bb41d7524321a70bddda34c1cceb Thu 2021-11-04 13:43:31 +04—Thu 2021-11-04 14:15:20 +04 

По умолчанию journalctl выводит сообщения из всех доступных журналов, но вы можете сократить выборку, для этого укажите номер журнала в параметре -b :

journalctl -b -1

Просмотр журнала

Вывести все сообщения:

journalctl

Выводить новые сообщения:

journalctl -f

Открыть журнал и перемотать его к последней записи:

journalctl -e

Вывести последние 5 строк журнала:

journalctl -n 5 

Фильтрация результатов

Лог последней загрузки операционной системы:

journalctl -b

Посмотреть сообщения ядра (dmesg):

journalctl -k

Посмотреть журнал определённого сервиса, например, wb-mqtt-serial:

journalctl -u wb-mqtt-serial

Просмотр сообщений от определённого сервиса в реальном времени:

journalctl -u wb-mqtt-serial -f

Фильтр по времени:

записи за последние сутки

journalctl --since -1d

journalctl --since "2020-02-13 07:00:00" 

journalctl --since "2020-02-13 07:00:00" --until "2020-02-14 07:00:00" 

journalctl --since "1 hour ago" 

Вывод команды можно фильтровать по уровню важности сообщений:

• 0: emergency — чрезвычайная ситуация
• 1: alerts — предупреждения, требуется вмешательство
• 2: critical — критическое состояние
• 3: errors — ошибки
• 4: warning — предупреждения
• 5: notice — уведомления
• 6: info — информационные сообщения
• 7: debug — отладочные сообщения

Например, чтобы вывести все ошибки:

journalctl -p 3 

Параметры можно комбинировать, например:

показать предупреждения, записанные драйвером wb-mqtt-serial с момента последней загрузки:

journalctl -b 0 -p 4 -u wb-mqtt-serial

journalctl --since "1 hour ago" -p 3 -u wb-mqtt-serial

Сохранение в текстовый файл

Вывод утилиты journalctl можно сохранить в файл, для этого добавьте в конец команды >> filename.txt , например, сохраним в файл сообщения драйвера wb-mqtt-serial:

journalctl --no-pager -u wb-mqtt-serial >> /tmp/log-file.txt

Так как вывод команды будет сохранён в файл /tmp/log-file.txt , то на консоли вы ничего не увидите.

О том, как скопировать файл с контроллера на компьютер, читайте в статье Просмотр файлов контроллера с компьютера.

Занимаемое логами место

Посмотреть занимаемое системным журналом место:

journalctl --disk-usage

Удалить все сообщения, старше 1 недели:

journalctl --vacuum-time=1weeks

Удалить все сообщения таким образом, чтобы журнал занял 100 Мбайт:

journalctl --vacuum-size=100M

Настроить параметры ведения системного журнала можно в файле /etc/systemd/journald.conf .

Восстановление базы данных InnoDB

Восстановление работоспособности после падения mysql, разберем специфику восстановления низкоуровневых подсистем InnoDB.

Почему падает бд

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

• Ошибка жёстких дисков, в следствие это невозможность считать файл.
• Ошибка записи была вызвана невозможность сохранить данные, по русски кончилось место в следствие этого произошла логическая ошибка БД.

Убедимся что проблема действительно есть

df -h

[root@centos-75-64-minimal ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/md2 437G 98G 317G 100% / devtmpfs 32G 0 32G 0% /dev tmpfs 32G 0 32G 0% /dev/shm tmpfs 32G 1.2M 32G 1% /run tmpfs 32G 0 32G 0% /sys/fs/cgroup /dev/md1 488M 143M 320M 31% /boot tmpfs 6.3G 0 6.3G 0% /run/user/600 tmpfs 6.3G 0 6.3G 0% /run/user/0

Место на диске кончилось, и БД не в состояние больше писать, отчистим место и попробуем перезапустить mysql, если же mysql не запускается то первым делом останавливаем mysql, в зависимости от ОС команда моет отличаться.

service mysqld restart

service mysql restart

/etc/init.d/mysqld restart

В нашем случае база не запустилась, по этому полностью останавливаем mysql

service mysqld stop

service mysql stop

/etc/init.d/mysqld stop

И убеждаемся что демон полностью остановлен и все процессы тоже, должен остаться только один процесс

[root@centos-75-64-minimal ~]# ps aux | grep mysql root 1903 0.0 0.0 112708 972 pts/3 S+ 19:46 0:00 grep --color=auto mysq

Если mysql все еще есть, то убиваем процесс

kill -9 "номер процесса"

Запускаем заново mysql

service mysqld start

service mysql start

/etc/init.d/mysqld start

Демон не запускается

service mysql start Redirecting to /bin/systemctl start mysql.service Job for mysqld.service failed because the control process exited with error code. See "systemctl status mysqld.service" and "journalctl -xe" for details.

В какие логи смотреть

journalctl -xe

PageUp и PageDown

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

Сам демон mysql может сообщить полезную информацию

service mysqld status

service mysql status

/etc/init.d/mysqld status

Redirecting to /bin/systemctl status mysql.service ● mysqld.service - MySQL Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: failed (Result: start-limit) since Mon 2019-02-18 18:20:59 MSK; 18min ago Docs: man:mysqld(8) http://dev.mysql.com/doc/refman/en/using-systemd.html Process: 25723 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQL D_OPTS (code=exited, status=1/FAILURE) Process: 25699 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS) Main PID: 14443 (code=killed, signal=KILL) Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service holdoff time over, scheduling . rt. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: start request repeated too quickly for mysqld. ice Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed. Hint: Some lines were ellipsized, use -l to show in full. [root@centos-75-64-minimal mysql]# service mysql status Redirecting to /bin/systemctl status mysql.service ● mysqld.service - MySQL Server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: failed (Result: start-limit) since Mon 2019-02-18 18:20:59 MSK; 18min ago Docs: man:mysqld(8) http://dev.mysql.com/doc/refman/en/using-systemd.html Process: 25723 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid $MYSQLD_OPTS (code=exited, status=1/FAILURE) Process: 25699 ExecStartPre=/usr/bin/mysqld_pre_systemd (code=exited, status=0/SUCCESS) Main PID: 14443 (code=killed, signal=KILL) Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service holdoff time over, scheduling restart. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: start request repeated too quickly for mysqld.service Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Failed to start MySQL Server. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: Unit mysqld.service entered failed state. Feb 18 18:20:59 centos-75-64-minimal systemd[1]: mysqld.service failed.

Как мы видим в данном случае информативности оно не добавило, просто mysql не желает стартовать.

Можно более подробно посмотреть в error логе mysql

tail -f /var/log/mysql/error.log

Нужно убедиться что логирование включено, для этого в my.cnf должна быть директива

log-error = путь до файла лога

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

find /etc/mysql/ -type f -exec grep -l "log-error" <> \;

2019-02-12T17:10:41.002325Z 0 [Warning] Could not increase number of max_open_files to more than 5000 (request: 80192) 2019-02-12T17:10:41.002565Z 0 [Warning] Changed limits: table_open_cache: 2392 (requested 18432) 2019-02-12T17:10:41.147060Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set. 2019-02-12T17:10:41.148006Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.23-25) starting as process 3314 .. 2019-02-12T17:10:41.153630Z 0 [Warning] InnoDB: Using innodb_file_format is deprecated and the parameter may be removed in future releases. See http://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html 2019-02-12T17:10:41.153694Z 0 [Note] InnoDB: PUNCH HOLE support available 2019-02-12T17:10:41.153702Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2019-02-12T17:10:41.153705Z 0 [Note] InnoDB: Uses event mutexes 2019-02-12T17:10:41.153708Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier 2019-02-12T17:10:41.153711Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7 2019-02-12T17:10:41.153715Z 0 [Note] InnoDB: Using Linux native AIO 2019-02-12T17:10:41.153902Z 0 [Note] InnoDB: Number of pools: 1 2019-02-12T17:10:41.153973Z 0 [Note] InnoDB: Using CPU crc32 instructions 2019-02-12T17:10:41.174468Z 0 [Note] InnoDB: Initializing buffer pool, total size = 18G, instances = 8, chunk size = 128M 2019-02-12T17:10:41.371813Z 0 [Note] InnoDB: Completed initialization of buffer pool 2019-02-12T17:10:41.401599Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2019-02-12T17:10:41.414873Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite 2019-02-12T17:10:41.425080Z 0 [Note] InnoDB: Highest supported file format is Barracuda. 2019-02-12T17:10:41.444212Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 21193390186 2019-02-12T17:10:41.444235Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 21193394424 2019-02-12T17:10:41.444432Z 0 [Note] InnoDB: Database was not shutdown normally! 2019-02-12T17:10:41.444436Z 0 [Note] InnoDB: Starting crash recovery. 2019-02-12T17:10:41.546953Z 0 [Note] InnoDB: Created parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite, size 31457280 bytes 2019-02-12T17:10:41.576387Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=3] log sequence number 108677477433 is in the future! Current system log sequence number 21193394506. 2019-02-12T17:10:41.576432Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/ forcing-innodb-recovery.html for information about forcing recovery. 2019-02-12T17:10:41.576647Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=2] log sequence number 132140291279 is in the future! Current system log sequence number 21193394506. 2019-02-12T17:10:41.576670Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/ forcing-innodb-recovery.html for information about forcing recovery. 2019-02-12T17:10:41.576922Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=4] log sequence number 21194400206 is in the future! Current system log sequence number 21193394506. 2019-02-12T17:10:41.576948Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/ forcing-innodb-recovery.html for information about forcing recovery. 2019-02-12T17:10:41.577209Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=11] log sequence number 132140749179 is in the future! Current system log sequence number 21193394506. 2019-02-12T17:10:41.577226Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/ forcing-innodb-recovery.html for information about forcing recovery. 2019-02-12T17:10:41.577858Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=6] log sequence number 132140702919 is in the future! Current system log sequence number 21193394506. 2019-02-12T17:10:41.577877Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/ forcing-innodb-recovery.html for information about forcing recovery. 2019-02-12T17:10:41.578094Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=330] log sequence number 132140702919 is in the future! Current system log sequence number 21193394506. 2019-02-12T17:10:41.578112Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/ forcing-innodb-recovery.html for information about forcing recovery. 2019-02-12T17:10:41.578328Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=790] log sequence number 21193512754 is in the future! Current system log sequence number 21193394506. 2019-02-12T17:10:41.578344Z 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to http://dev.mysql.com/doc/refman/5.7/en/ forcing-innodb-recovery.html for information about forcing recovery. 2019-02-12T17:10:41.578555Z 0 [ERROR] InnoDB: Page [page id: space=0, page number=45] log sequence number 21194412806 is in the future! Current system log sequence number 21193394506.

Что происходит

Была повреждена одна или более таблиц бд, особенно это относится к InnoDB

Как правило если исправить эту ошибку то работоспособность БД восстановится.

В противном случае нам прийдётся делать дамп всех БД и переустанавливать mysql

Востанавливаем базы данных

Когда innodb вообще не запускается, нам прийдутся зайти в защитный режим, для этого добавим в /etc/my.cnf

innodb_force_recovery = 1

Место положение файла зависит от ОС

И попробуем заново запустить mysql.

Если старт не происходит, увеличиваем цифру с шагом в единицу и пытаемся запустить бд.

innodb_force_recovery = 2

Чем больше цифра, тем больше будет ограничений при старте, так что имеет смысл постепенно повышать значение, подобрав минимально подходящую, максимальное значение innodb_force_recovery = 8

В моем случае старт пошёл на =2, но одна из бд падала при обращение к ней и заработала только на 6.

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

Внимание! Обязательно сделайте резервную копию БД перед началом работы. Остановите mysql и полностью скопируйте папку /var/lib/mysql, любые изменения в текущей бд могут привести к потере даных!

Делаем дамп всех БД, обычно рекомендуют сделать mysqldump -u root -p —all-databases —skip-lock-tables > alldb.sql с вариациями, но нам нужно понять кто не корректно и где дамптися так что я делаю по другому.

В начале посмотрим можем ли мы прочитать названия БД

mysql -uroot -p******** -e'show databases;'

[root@centos-75-64-minimal mysql]# mysql -uroot -p******s -e’show databases;' ±--------± | Database | ±--------± | information_schema | | dbami-com | | dbhikvisionpro | | performance_schema | | sitemanager | | sys | ±--------±

У нас есть список БД и мы можем сделать дамп каждой по отдельности.

Создадим директорию для бэкапов, я делаю это не в /tmp поскольку может понадобиться перезагрузиться а в зависимости от способа монтирования, она может перетереться при загрузке

mkdir -p /var/backup/mysql

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

for i in `mysql -uroot -p******** -e'show databases;' | grep -v information_schema | grep -v performance_schema | grep -v Database`; do mysqldump -uroot -p******** $i > /var/backup/mysql/$i.sql || echo "$i $?";done

Если дамп прошёл успешно, то можно запускать

mysqlcheck --auto-repair -o --all-databases

Если и он справился удачно то можно попробовать удалить innodb_force_recovery из my.cnf и перезагрузить mysql

Но мы будем разбирать менее оптимистичный сценарий.

[root@centos-75-64-minimal mysql]# for i in `mysql -uroot -e’show databases;' | grep -v information_schema | grep -v performance_schema | grep -v Database`; do mysqldump -uroot -no-create-info $i > /var/backup/mysql/$i.sql || echo «$i $?«;done mysqldump: Error: 'Lost connection to MySQL server during query' when trying to dump tablespaces mysqldump: Couldn’t execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': MySQL server has gone away (2006) dbhikvisionpro 2 mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect sitemanager 2 mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect

Как мы видим что-то пошло не так, при обращение к одной из бд произошла ошибка, и она привела к падению всего mysql, дальше дамп был не возможен. В данном случае mysql пришлось снимать kill −9 поскольку другим способом демон не желал ни работать ни корректно останавливаться.

Посмотрим что нам удалось выгрузить:

root@centos-75-64-minimal mysql]# ls -la total 597616 drwxr-xr-x 2 root root 4096 Feb 18 19:43 . drwxr-xr-x 3 root root 4096 Feb 18 19:37 .. -rw-r—r— 1 root root 611926379 Feb 18 19:43 dbami-com.sql -rw-r—r— 1 root root 1563 Feb 18 19:43 dbhikvisionpro.sql -rw-r—r— 1 root root 0 Feb 18 19:43 sitemanager.sql

Как мы видим, дамп корректно был завершена только для одной dbami-com.sql (не нулевой размер, dbhikvisionpro, это или часть некорректного дампа, или в нашем случае, ошибка была в первой же таблице по этому дамп содержал только общий заголовок и не имел внутри вообще никакой информации. Все последующие БД не имели размера поскольку sql уже не отвечал.

[root@centos-75-64-minimal mysql]# cat dbhikvisionpro.sql — MySQL dump 10.13 Distrib 5.7.23–25, for Linux (x86_64) - — Host: localhost Database: dbhikvisionpro — -------------------------- — Server version 5.7.23–25 /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */; /*!40103 SET TIME_ZONE='+00:00' */; /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */; /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */; /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */; /*!50717 SELECT COUNT(*) INTO @rocksdb_has_p_s_session_variables FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'performance_schema' AND TABLE_NAME = 'session_variables' */; /*!50717 SET @rocksdb_get_is_supported = IF (@rocksdb_has_p_s_session_variables, 'SELECT COUNT(*) INTO @rocksdb_is_supported FROM performance_schema.session_variables WHERE VARIABLE_NAME=\'rocksdb_bulk_load\'', 'SELECT 0') */; /*!50717 PREPARE s FROM @rocksdb_get_is_supported */; /*!50717 EXECUTE s */; /*!50717 DEALLOCATE PREPARE s */; /*!50717 SET @rocksdb_enable_bulk_load = IF (@rocksdb_is_supported, 'SET SESSION rocksdb_bulk_load = 1', 'SET @rocksdb_dummy_bulk_load = 0') */; /*!50717 PREPARE s FROM @rocksdb_enable_bulk_load */; /*!50717 EXECUTE s */; /*!50717 DEALLOCATE PREPARE s */;

Проверим догадку, так ли это, зайдем в mysql и попробуем посмотреть список таблиц.

mysql> use dbhikvisionpro Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with Databases changed~ Mysql> show tables; mysql> show tables; No connection. Trying to reconnect… ERROR 2002 (HY000): Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) ERROR:

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

ps aux | grep mysql

kill -9 ***

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

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

cd /var/lib/mysql/ваша бд/

Получаем список таблиц

Внимание! Такой способ возможен только при условии что innodb_file_per_table=1

ls *.ibd | grep -v "FTS"| cut -d '.' -f 1

[root@centos-75-64-minimal dbhikvisionpro]# ls *.ibd | grep -v «FTS»| cut -d '.' -f 1 b_abtest b_admin_notify b_admin_notify_lang b_adv_banner_2_country b_adv_banner_2_day b_adv_banner_2_group b_adv_banner_2_page b_adv_banner_2_site b_adv_banner_2_stat_adv b_adv_banner_2_weekday b_adv_banner b_adv_contract_2_page b_adv_contract_2_site b_adv_contract_2_type b_adv_contract_2_user b_adv_contract_2_weekday b_adv_contract b_adv_type b_agent b_app_password b_b24connector_buttons b_bitrixcloud_option b_blog_category b_blog_comment b_blog_group b_blog b_blog_image b_blog_post_category .

Имея список таблиц сделаем дамп каждой таблицы по отдельности и и будем смотреть что у нас с ними.

Создаем папку для дампа таблиц

mkdir /tmp/dbhikvisionpro

И делаем дамп таблиц. Поскольку мы делаем дамп каждой таблицы по отдельности, мы можем следить за кодом завершения каждой из них.

for i in `ls *.ibd | grep -v "FTS"| cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo "$i $?";done

# for i in `ls *.ibd | grep -v «FTS»| cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo «$i $?«;done mysqldump: Error: 'Lost connection to MySQL server during query' when trying to dump tablespaces mysqldump: Couldn’t execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': MySQL server has gone away (2006) b_xml_tree_import_1c 2 mysqldump: Got error: 2002: Can’t connect to local MySQL server through socket '/var/lib/mysqld/mysqld.sock' (111) when trying to connect

И видим что при обращение к таблице b_xml_tree_import_1c , код ответа 2, и опять упала бд, все последующие так же не читаются.

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

Делаем исключение битых таблиц grep -v исключает таблицу

for i in `ls *.ibd | grep -v "FTS"| grep -v "b_xml_tree_import_1c" | grep -v "b_session" | cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i > /tmp/dbhikvisionpro/$i.sql || echo "$i $?";done

drwxrwxrwt. 18 root 4096 Feb 18 21:36. -rw-r-r- 1 root 7459 Feb 18 21:35 b_abtest.sql -rw-r-r- 1 root 3166 Feb 18 21:35 b_admin_notify_lang.sql -rw-r-r- 1 root 3318 Feb 18 21:35 b_admin_notify.sql -rw-r-r- 1 root 3301 Feb 18 21:35 b_adv_banner_2_country.sql -rw-r-r- 1 root 3140 Feb 18 21:35 b_adv_banner_2_day.sql -rw-r-r- 1 root 3028 Feb 18 21:35 b_adv_banner_2_group.sql -rw-r-r- 1 root 3163 Feb 18 21:35 b_adv_banner_2_page.sql -rw-r-r- 1 root 3031 Feb 18 21:35 b_adv_banner_2_site.sql -rw-r-r- 1 root 3055 Feb 18 21:35 b_adv_banner_2_stat_adv.sql -rw-r-r- 1 root 3109 Feb 18 21:35 b_adv_banner_2_weekday.sql -rw-r-r- 1 root 5759 Feb 18 21:35 b_adv_banner.sql -rw-r-r- 1 root 3183 Feb 18 21:35 b_adv_contract_2_page.sql -rw-r-r- 1 root 3102 Feb 18 21:35 b_adv_contract_2_site.sql -rw-r-r- 1 root 3110 Feb 18 21:35 b_adv_contract_2_type.sql -rw-r-r- 1 root 3160 Feb 18 21:36 b_adv_contract_2_user.sql -rw-r-r- 1 root 5984 Feb 18 21:36 b_adv_contract_2_weekday.sql -rw-r-r- 1 root 4099 Feb 18 21:36 b_adv_contract.sql -rw-r-r- 1 root 3274 Feb 18 21:36 b_adv_type.sql -rw-r-r- 1 root 11749 Feb 18 21:36 b_agent.sql -rw-r-r- 1 root 3515 Feb 18 21:36 b_app_password.sql -rw-r-r- 1 root 3153 Feb 18 21:36 b_b24connector_buttons.sql -rw-r-r- 1 root 3424 Feb 18 21:36 b_bitrixcloud_option.sql -rw-r-r- 1 root 3063 Feb 18 21:36 b_blog_category.sql -rw-r-r- 1 root 3934 Feb 18 21:36 b_blog_comment.sql -rw-r-r- 1 root 3054 Feb 18 21:36 b_blog_group.sql -rw-r-r- 1 root 3402 Feb 18 21:36 b_blog_image.sql -rw-r-r- 1 root 3175 Feb 18 21:36 b_blog_post_category.sql -rw-r-r- 1 root 3200 Feb 18 21:36 b_blog_post_param.sql -rw-r-r- 1 root 5096 Feb 18 21:36 b_blog_post.sql -rw-r-r- 1 root 3155 Feb 18 21:36 b_blog_site_path.sql -rw-r-r- 1 root 3178 Feb 18 21:36 b_blog_socnet_rights.sql -rw-r-r- 1 root 2987 Feb 18 21:36 b_blog_socnet.sql -rw-r-r- 1 root 4513 Feb 18 21:36 b_blog.sql -rw-r-r- 1 root 3343 Feb 18 21:36 b_blog_trackback.sql -rw-r-r- 1 root 3054 Feb 18 21:36 b_blog_user2blog.sql ……

Теперь у нас есть все таблицы и мы можем смотреть каждую по отдельности. Убедившись что все с ними хорошо, поэтому нам больше не нужны таблицы по отдельности, нам нужен один файл.

for i in `ls *.ibd | grep -v "FTS"| grep -v "b_xml_tree_import_1c" | grep -v "b_session" | cut -d '.' -f 1`; do mysqldump -uroot dbhikvisionpro $i >> /tmp/dbhikvisionpro/dbhikvisiononpro.sql || echo "$i $?";done

В результате получаем полноценный дамб за исключением двух таблиц. Как вариант в mysqldump есть —ignore-table=DATABASE.table1 но там нужно писать баш скрипт и многие жалуются что он не работает корректно, в моем же случае цикл у меня уже был сделал и не принципиально как он будет делаться.

Все что нам остаётся удалить проблемные БД, если не получается их удалить то проверяем диск на вероятные сбои как физические так и логические, если же все хорошо но база не удаляется, остаётся только полностью переустановить mysql.

Заново инициализируем mysql

Поскольку все БД мы уже получили, нам нужно восстановить работоспособность mysql, DROP TABLES не помогает, в связи с этим, мы удалим физически все БД и инициализируем чистый mysql

systemctl stop mysqld

Удалим полностью папку mysql

rm -rf /var/lib/mysqld

Инициализируем новую БД

mysqld --initialize-insecure --basedir=/usr --datadir=/var/lib/mysql

mkfifo /var/lib/mysqld/mysqld.sock

chown -R mysql /var/lib/mysqld/mysqld.sock

Нам нужно установить root пароль, устанавливаем environment

systemctl set-environment MYSQLD_OPTS="--skip-grant-tables"

Заходим в mysql без пароля

systemctl start mysqld mysql -u root

Обновляем пароль root

mysql> UPDATE mysql.user SET authentication_string = PASSWORD('MyNewPassword') -> WHERE User = 'root' AND Host = 'localhost'; mysql> FLUSH PRIVILEGES; mysql> quit

новый вариант, просто делаем и тот и тот

mysql> ALTER USER 'root'@'localhost' IDENTIFIED BY 'MyNewPass';

Останавливаем sql и возвращаемся в нормальный режим

systemctl stop mysqld systemctl unset-environment MYSQLD_OPTS systemctl start mysqld

Использование journalctl для просмотра и анализа логов: подробный гайд

Journalctl — отличный инструмент для анализа логов, обычно один из первых с которым знакомятся начинающие администраторы linux систем. Встроенные возможности ротации, богатые возможности фильтрации и возможность просматривать логи всех systemd unit-сервисов одним инструментом очень удобны и заметно облегчают работу системным администраторам.

Эта статья рассматривает основные возможности утилиты journalctl и различные варианты ее применения. С помощью journalctl можно просматривать логи системы, чтобы решить возникшие проблемы на рабочей станции или сервере использующие дистрибутив linux с демоном инициализации systemd, де-факто уже ставшим стандартом в современных Linux-системах, например: RHEL, CentOS, Fedora, Debian и многих других.

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

Systemd

Systemd состоит из трех основных компонентов:

• systemd — менеджер системы и сервисов
• systemctl — утилита для просмотра и управление статусом сервисов
• systemd-analyze — предоставляет статистику по процессу загрузки системы, проверяет корректность unit-файлов и так же имеет возможности отладки systemd

Journald

Journald — системный демон журналов systemd. Systemd спроектирован так, чтобы централизованно управлять системными логами от процессов, приложений и т.д. Все такие события обрабатываются демоном journald, он собирает логи со всей системы и сохраняет их в бинарных файлах.

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

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

Файл конфигурации journald

Файл конфигурации можно найти по следующему пути: /etc/systemd/journald.conf, он содержит различные настройки journald, я бы не рекомендовал изменять этот файл, если вы точно не уверены в том, что делаете.

Каталог с журналом journald располагается /run/log/journal (в том случае, если не настроено постоянное хранение журналов, но об этом позже).

Файлы хранятся в бинарном формате, поэтому нормально их просмотреть с помощью cat или nano, как привыкли многие администраторы — не получится.

Использование journalctl для просмотра и анализа логов

Основная команда для просмотра:

# journalctl

Она выведет все записи из всех журналов, включая ошибки и предупреждения, начиная с того момента, когда система начала загружаться. Старые записи событий будут наверху, более новые — внизу, вы можете использовать PageUp и PageDown чтобы перемещаться по списку, Enter — чтобы пролистывать журнал построчно и Q — чтобы выйти.

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

# journalctl --utc 

Фильтрация событий по важности

Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
# journalctl -p 0

Для уровней важности, приняты следующие обозначения:

• 0: emergency (неработоспособность системы)
• 1: alerts (предупреждения, требующие немедленного вмешательства)
• 2: critical (критическое состояние)
• 3: errors (ошибки)
• 4: warning (предупреждения)
• 5: notice (уведомления)
• 6: info (информационные сообщения)
• 7: debug (отладочные сообщения)

Настройка хранения журналов

По умолчанию journald перезаписывает свои журналы логов при каждой перезагрузке, и вызов journalctl выведет журнал логов начиная с текущей загрузки системы.

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

Когда в конфигурационном файле /etc/systemd/journald.conf параметру Storage= задано значение auto) и каталога /var/log/journal/ не существует, журнал будет записываться в /run/log/journal без сохранения между перезагрузками, если /var/log/journal/ существует, журналы будут сохраняться в нем, на постоянной основе, но если каталог будет удален, systemd не пересоздаст его автоматически и вместо этого будет вести журнал снова в /run/systemd/journal без сохранения. Каталог может быть пересоздан в таком случае, если добавить Storage=persistent в journald.conf и перезапустить systemd-journald.service (или перезагрузиться).

Создадим каталог для хранения журналов, установим необходимые атрибуты и перезапустим службу:

# mkdir /var/log/journal # systemd-tmpfiles --create --prefix /var/log/journal # systemctl restart systemd-journald

Просмотр журналов загрузки

Если journald был настроен на постоянное хранение журналов, мы можем просматривать журналы логов по каждой отдельной загрузке, следующая команда выведет список журналов:

# journalctl --list-boots

Первый номер показывает номер журнала, который можно использовать для просмотра журнала определенной сессии. Второй номер boot ID так же можно использовать для просмотра отдельного журнала.

Следующие две даты, промежуток времени в течении которого в него записывались логи, это удобно если вы хотите найти логи за определенный период.

Например, чтобы просмотреть журнал начиная с текущего старта системы, можно использовать команду:

# journalctl -b 0

А для того, чтобы просмотреть журнал предыдущей загрузки:

# journalctl -b -1

Просмотр журнала за определенный период времени

Journalctl позволяет использовать такие служебные слова как “yesterday” (вчера), “today” (сегодня), “tomorrow” (завтра), или “now” (сейчас).

Поэтому мы можем использовать опцию «—since» (с начала какого периода выводить журнал).

С определенной даты и времени:

# journalctl --since "2020-12-18 06:00:00"

С определенной даты и по определенное дату и время:

# journalctl --since "2020-12-17" --until "2020-12-18 10:00:00

Со вчерашнего дня:

# journalctl --since yesterday

С 9 утра и до момента, час назад:

# journalctl --since 09:00 --until "1 hour ago"

Просмотр сообщений ядра

Чтобы просмотреть сообщения от ядра Linux за текущую загрузку, используйте команду с ключом -k:

# journalctl -k

Просмотр журнала логов для определенного сервиса systemd или приложения

Вы можете отфильтровать логи по определенному сервису systemd. Например, что бы просмотреть логи от NetworkManager, можно использовать следующую команду:

# journalctl -u NetworkManager.service

Если нужно найти название сервиса, используйте команду:

# systemctl list-units --type=service

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

# journalctl /usr/sbin/nginx --since today

Или указав конкретный PID:

# journalctl _PID=1

Дополнительные опции просмотра

Следить за появлением новых сообщений (аналог tail -f):

# journalctl -f

Открыть журнал «перемотав» его к последней записи:

# journalctl -e

Если в каталоге с журналами очень много данных, то фильтрация вывода journalctl может занять некоторое время, процесс можно значительно ускорить с помощью опции —file, указав journalctl только нужный нам журнал, за которым мы хотим следить:

journalctl --file /var/log/journal/e02689e50bc240f0bb545dd5940ac213/system.journal -f

По умолчанию journalctl отсекает части строк, которые не вписываются в экран по ширине, хотя иногда перенос строк может оказаться более предпочтительным. Управление этой возможностью производится посредством переменной окружения SYSTEMD_LESS, в которой содержатся опции, передаваемые в less (программу постраничного просмотра, используемую по умолчанию). По умолчанию переменная имеет значение FRSXMK, если убрать опцию S, строки не будут обрезаться.

SYSTEMD_LESS=FRXMK journalctl

Ограничение размера журнала

Если journald настроен что бы сохранять журналы после перезагрузки, то по умолчанию размер журнала ограничен 10% от объема файлового раздела и максимально может занять 4 Гб дискового пространства.

Максимальный объем журнала можно скорректировать, раскомментировав и отредактировав следующий параметр в файле конфигурации journald:

SystemMaxUse=50M

Удаление журналов

Удалить файлы архивных журналов, можно вручную с помощью rm или использовав journalctl.

Удалить журналы, оставив только последние 100 Мб:

# journalctl --vacuum-size=100M

Удалить журналы, оставив журналы только за последние 7 дней:

# journalctl --vacuum-time=7d

Заключение

Служба журналирования логов journald очень мощный и гибкий инструмент, и если вы знаете как его использовать, он может сделать вашу жизнь намного проще во время поиска причин проблем с системой или ее сервисами.

• ruvds_статьи
• серверное администрирование
• journalctl
• просмотр логов
• логи
• анализ логов

• Блог компании RUVDS.com
• Серверная оптимизация
• Серверное администрирование
• Облачные сервисы
• Лайфхаки для гиков