Вопрос или проблема
Я столкнулся с необычной проблемой в нашем кластере MariaDB на базе Ubuntu. Все узлы испытывали постоянную загрузку ЦП от 100% до 400%, и после этого всплеска как SSH-доступ, так и попытки входа в консоль завершились неудачей. Когда я пытаюсь войти прямо из консоли, сообщается, что имя пользователя и пароль неверны, хотя они правильные.
Мне интересно, могла ли высокая нагрузка на ЦП вызвать повреждение системы, затрагивающее службы входа или аутентификацию на узлах. Повреждение возникло после длительной нагрузки на ЦП в 100-400%.
Кто-нибудь сталкивался с чем-то подобным или может поделиться сведениями о том, как перегрузка ЦП может повлиять на функциональность входа и SSH на узле кластера MariaDB? Любые советы по восстановлению или отладке этой проблемы будут очень полезны.
[mysqld]
bind-address = 0.0.0.0
binlog_format = row
default_storage_engine = InnoDB
innodb_autoinc_lock_mode = 2
wsrep_on = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name = "mariadb_cluster"
wsrep_cluster_address = "gcomm://2.2.2.11,3.3.3.11,4.4.4.11"
wsrep_node_address = "2.2.2.11"
wsrep_node_name = "myserver1"
wsrep_sst_method = mariabackup
wsrep_sst_auth = "mariabackup_user:Password"
Да, если системные процессы не могут получить необходимое время ЦП, они не будут функционировать должным образом. Вам следует проверить журналы ssh, MariaDB и системы:
sudo cat /var/log/auth.log | grep ssh
sudo cat /var/log/auth.log | grep failed
sudo journalctl -xe
sudo dmesg | less
sudo cat /var/log/mysql/error.log
sudo cat /var/log/mysql/mariadb.log
Вы можете перезапустить службы PAM и аутентификации, чтобы восстановиться после сбоя:
sudo systemctl restart systemd-logind
sudo systemctl restart sshd
Эта команда покажет 10 процессов с наибольшим потреблением ЦП:
ps aux --sort=-%cpu | head -n 10
Ответ или решение
Итак, ситуация, с которой вы столкнулись в вашем кластере MariaDB, действительно вызывает беспокойство. Когда все узлы вашего кластера испытывают нагрузку на CPU до 100-400%, существует высокий риск, что это может повредить системные процессы, а именно аутентификацию и доступ через SSH. Позвольте мне предложить план действий, чтобы помочь вам разобраться с этой проблемой.
1. Анализ проблемы
Пиковые нагрузки на CPU могут вызвать замедление или полное отсутствие работы критически важных процессов в системе. Это может привести, среди прочего, к сбоям в обслуживании SSH-сессий, а также проблемам с аутентификацией. Когда ресурсы системы исчерпаны, процессам может просто не хватать времени для обработки запросов, что объясняет неправильные данные при вводе логина и пароля, даже если они верные.
2. Проверка журналов системы
Первым шагом будет анализ логов системы, чтобы понять причину перегрузки и связанные с ней ошибки. Рекомендуется просмотреть следующие файлы журнала:
sudo cat /var/log/auth.log | grep ssh
sudo cat /var/log/auth.log | grep failed
sudo journalctl -xe
sudo dmesg | less
sudo cat /var/log/mysql/error.log
sudo cat /var/log/mysql/mariadb.logЭти команды помогут вам найти записи о сбоях аутентификации и другие ошибки, которые могли проявиться во время нагрузки на систему.
3. Оценка текущего состояния системы
Используйте следующую команду, чтобы увидеть процессы, потребляющие больше всего ресурсов:
ps aux --sort=-%cpu | head -n 10Это поможет вам определить, какие процессы вызывают основную нагрузку. Следует обратить внимание на процессы MariaDB и системные службы, так как их неправильная работа может препятствовать выполнению таких задач, как аутентификация.
4. Перезагрузка служб
Если вы обнаружите, что нагрузка на сервер наконец-то снизилась, можно попытаться перезапустить службы аутентификации и SSH. Попробуйте выполнить следующие команды:
sudo systemctl restart systemd-logind
sudo systemctl restart sshdЭти действия могут помочь восстановить доступ к SSH, если службы зависли или не функционируют должным образом.
5. Рассмотрите возможность проверки системы на наличие повреждений
При устойчивой перегрузке CPU возможно возникновение системной коррупции. Поэтому, если проблема с доступом сохраняется, есть смысл проверить целостность файловой системы с помощью инструмента fsck, а также рассмотреть возможность использования резервной копии, если это потребуется.
6. Мониторинг и профилактика
После решения данной проблемы стоит установить системы мониторинга CPU и производительности, чтобы предотвратить повторение этой ситуации. Настройте уведомления, чтобы знать о высокой нагрузке до того, как она приведет к таким серьезным сбоям.
Заключение
Эта проблема требует быстрого реагирования для обеспечения доступности и целостности данных на вашем кластере MariaDB. Используйте предложенные шаги для диагностики и устранения неполадок. Не забывайте, что заблаговременные меры по мониторингу производительности помогут избежать подобных инцидентов в будущем.