Lost connection to mysql server at reading initial communication packet system error 104

Доброго времени суток, уважаемые Хабровчане! Разрешите представиться, Александр. Системный администратор одной маленькой но гордой WEB-студии. Мы очень хотим, чтобы все работало быстро, безопасно и со свежим софтом. Для этого даже подняли на внутриофисном компе связку nagios+PhantomJS и каждые 30 минут проверяем скорость загрузки страниц. По условиям обслуживания, мы так-же следим за обновлениями 1С-Битрикс и регулярно устанавливаем их. И вот однажды после очередного обновления видим сообщение в админке о том, что с лета 2019 1С-Битрикс перестает работать с MySQL 5.5 и надо обновляться. Ребята из ISPSystem красавцы и регулярно расширяют функционал панели за что им отдельное спасибо. Но в этот раз не получилось накликать все мышью. А вот о том, что получилось и сколько седых волос теперь в моей бороде можно узнать под катом.

Был только вариант ставить “альтернативный сервер СУБД” который ставится в Docker-контейнер. Я конечно понимаю, что Docker весьма бережлив с ресурсами, но как-бы здорово он ни работал, оверхед все равно будут >0. А мы тут как-бы за десятые доли секунд бьемся и на входе все сайты оптимизируем прежде чем опубликовать у себя и подписать договор. Так что не мой вариант.
Ок, что там в документации написано? Backup всего, добавить в yum.repos.d файл со ссылкой на репозиторий MariaDB, далее

rpm -e --nodeps MariaDB-server MariaDB-client MariaDB-common

Yum впоследствии будет ругаться на то, что кто-то пакеты удалялставил без его ведома. Но во первых — пусть ругается, ничего страшного. А во вторых если делать удаление через yum, то он пытается вместе с MariaDB снести и все, что по зависимостям с ним связано, а это и PHP и ISPManager и PHPmyadmin. Поэтому с ругачками потом разберемся.

yum clean all
yum update
yum install MariaDB-server MariaDB-client MariaDB-common

В общем все поставилось и завелось. Приятно то, что базы подхватились и не надо было их восстанавливать из дампов. Я проверил сайты — работают и быстро. Зашел в пару админок чтобы удостовериться, что ничего не отвалилось и отписался директору, что все ОК. Не прошло и 30 минут как выяснилось, что совсем даже не ОК…

При попытке зайти в админку и добавитьотредактировать что угодно в контенте вываливалось сообщение

MySQL Query Error: INSERT INTO b_iblock_element_property (ID, IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID, VAL UE, VALUE_NUM) SELECT 10555 ,2201 ,P.ID ,'3607' ,3607.0000 FR OM b_iblock_property P WHERE ID = 184 [[1062] Duplicate entry '10555' for key 'PRIMARY']

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

Из текста ошибки можно сделать вывод о том, что Битрикс пытается добавить новую запись в базу при этом указав тот-же primary key, что был у редактируемой статьи. Значит есть основания подозревать, что проблема возникает на стороне Битрикс. Идем на их сайт и обращаемся в поддержку. Почти сразу получаем ответ “сложная проблема. Отдали старшим инженерам — ждите…”

Ждать пришлось довольно долго (весь диалог происходил в период с 25.06.2019 по 9.07.2019гг.) и итогом стало сообщение “данная проблема не связана с работой CMS Битрикс, а связана с работой самой базы данных в mariadb 10.4.6 и к сожалению со стороны сайта данную проблему решить возможность отсутствует необходимо будет перейти на старую версию MariaDB.”

Приплыли… Про downgrade я думал еще в начале истории, но тут черным по белому сказано, что никакого downgrade быть не может. Сливайте дампы и разворачивайте заново на начисто установленном сервере. Т.е. это хорошо, что я не все сервера разом обновил. Т.е. “всего-то” сотня сайтов (нервный смешок:-)). Еще в поддержке сказали: “Для решения проблемы при использовании базы MariaDB 10.4.6 вам необходимо будет обратиться в техническую поддержку MariaDB, что в транзакции не выполнятся удаление записи из БД, если делается запрос:

$DB->Query("DELETE FROM ".$strTable." WHERE ID = ".$res["ID"]);
$results = $DB->Query("SELECT * FROM ".$strTable." WHERE ID = ".$res["ID"]);”

Надежда теплилась пару часов с момента начала общения с поддержкой MariaDB, но потом пришло письмо в котором предельно корректно мне сообщили, что я не коммерческий пользователь и потому мою проблему целенаправленно решать никто не будет, но есть форум на их сайте и там можно попробовать поискать варианты… Не буду утомлять подробностями. Нет там вариантов.
О! У нас же купленная лицензия на ISP!
— Алло, поддержка? Ребята, помогите!
— Извините, мы не поддерживаем отморозков которые нативные версии СУБД меняют. Хотите — есть вариант с альтернативным сервером в докере.
— Но как-же туда попадут пользователи и базы? В докер?
— Ну вы их туда руками затащите…
— Да! И не забудьте, что порт для mysql поменяется и надо будет по всем конфигам пройтись и переписать.
— Ок, спасибо, буду думать…
Подумал я и решил таки ручками снести 10.4 и поставить 10.2 с которым на других серверах проблем небыло.

Процесс не особо отличался от процесса обновления. Только надо было в ссылке на репозиторий поменять 10.4 на 10.2, сбросить и заново создать кэш для yum. Ну и еще одна “мелочь”: после удаления 10.4, идем в /var/lib/mysql и все оттуда удаляем. Без этого шага после установки 10.2, сервис будет постоянно падать и будете видеть

Не удалось подключиться к базе данных '' Lost connection to MySQL server at 'reading initial communication packet', system error: 104 "Connection reset by peer"

Или

Lost connection to MySQL server at 'handshake: reading inital communication packet', system error: 104

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

Текст скрипта для дампа баз:

#!/bin/bash
echo 'show databases' | mysql -u root --password="ПаРоЛь_РУТА" --skip-column-names | grep -v information_schema | xargs -I {} -t bash -c 'mysqldump -u root --password="ПаРоЛь_РУТА" {} | gzip > /BACK/back-$(hostname)-{}-$(date +%Y-%m-%d-%H.%M.%S).sql.gz'

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

gunzip /BACK/*.gz

И последнее: по какой-то причине в названии баз (если создаете через ISPmanager) допускаются дефисы. А вот при создании или попытке залить дамп в базу у которой в названии дефис, вы получаете сообщение о том, что синтаксис запроса неправильный.

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

UPD1:

Чуть не забыл упомянуть: пока я пытался найти решение проблемы без downgrade MariaDB, надо было как-то инфу обновлять. Обновлялась так: вся база конвертируется из InnoDB в MyISAM, обновляется инфа и пото конвертится обратно в InooDB.
UPD2:

Только что пришло письмо от 1С-Битрикс следующего содержания:

Заявка на доработку реализована
«После обновления mariadb до 10.4.6 ошибка при сохранении элемента инфоблока»
Модуль: iblock, версия: не известна
Решение: отклонено

Так что пока до 10.4 обновляться видимо нельзя

Lost connection to MySQL server at reading initial communication packet, is an error we get while connecting to a MySQL database.

As part of our Server management services, Bobcares provides solutions for every query.

Let’s take a look at how our Support team handled this situation.

Lost connection to MySQL server at ‘reading initial communication packet

While connecting to a MySQL database, we might run into this error: Lost connection to MySQL server at reading initial communication packet, system error: 0

There appears to be an issue with the firewall, which is preventing outside connections. We should check the firewall rules to see if they are blocking any MySQL connections.

If the firewall isn’t the problem, check the list below to see if we have any of the following:

1. Verify that MySQL is running on the server’s IP address.
2. Then, Make sure MySQL is listening on port 3306.
3. Ensure that the user has permission to connect to the server IP.
4. Make sure we’re using the correct password for connecting from the host address we’re connecting from if one is required.

Most of the time, MySQL only listens on localhost and does not accept connections from other computers. As a result, we can’t connect from the outside leading to the Lost Connection to MySQL Server error.

In the my.cnf file, look at the bind-address variable. Because it defaults to localhost, only connections from that host will work.

• Comment out the line: to ensure MySQL listens on all addresses. #bind-address = 127.0.0.1

• Then restart the server as follows: sudo service mysql restart

• GRANT ALL PRIVILEGES ON ourDB.* TO 'username'@'OUR_APPLICATION_IP' IDENTIFIED BY 'OUR_PASSWORD' WITH GRANT OPTION;

If we still get the error, then:

1. Allow applications through the Windows Firewall.
2. The path to mysql is typically C:/Program Files (x86)/MySQL/bin/mysql, so we’ll need to add it to the list.
3. Click Apply after marking both private and public networks.

If the IP address is blocked by Firewalld. Use the following commands to grant access: firewall-cmd --permanent --zone=trusted --add-source=OUR_IP/32 firewall-cmd --permanent --zone=trusted --add-port=3306/tcp firewall-cmd --reload

Another solution for the Lost Connection to MySQL Server error is to choose + to add a new connection in the workbench and enter the following information:

• TCP/IP over SSH is the connection method.
• xxx.xxx.xx.xx:xx (replace xx with remote SSH server IP and port(optional)) is the SSH Hostname
• Enter the SSH username
• At the prompt, we can set a password.
• MYSQL Localhost or 127.0.0.1 is the hostname.
• Port:3306 MYSQL Server
• At the prompt, we can enter a password or add a new one.

Then, check the connection. If it is successful, click OK.

If nothing else works, flush the privileges. mysql> FLUSH PRIVILEGES;

[Looking for a solution to another query? We are just a click away.]

Conclusion

To sum up, our Support team was successful in resolving the error: Lost connection to MySQL server at reading initial communication packet with the above steps