Форум компании Ритм - НПО «Ритм»

Lost connection to MySQL server during query

Поиск  Пользователи  Правила  Войти  
Форум » Программы РИТМ
Страницы: 1
RSS
Lost connection to MySQL server during query, IS с вынесенным MySQL
#1
10.08.2012 11:21:07
Подниму данный вопрос здесь, выведя его из личной переписки с Максимом.

Заключается он в проблеме при работе IS с вынесенным MySQL, которая связана с возникновением ошибки
Цитата

#### !!! Ошибка (MyWriteEventToDataBase): Lost connection to MySQL server during query Socket error on write. WSAGetLastError return 10053($2745)

и как результатом - потере части данных ...

Переписка с Максимом и с ТП хостера ни к какому результату пока не привела.

Однако ... Учитывая тот факт, что ошибка возникает при попытке записи информации о входящем вызове в базу получаем, что данная информация теряется, а дальше происходит успешная запись информации о полученном сигнале. Т.е. соединение с MySQL-сервером каким-то "чудесным образом" восстанавливается ...

Напрягает в этой ситуации лишь факт потери данных ...

Со слов Максима подобных проблем при нахождении серверов с IS и MySQL в локальной сети не наблюдается. Т.е. все "камни" летят в "А" - хостера, "Б" - интернет-шлюз, "В" - канал связи ...

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

Вот так вкратце ...
 
 
#2
14.12.2012 11:27:18
В продолжение ...

Провели эксперимент:
1. Подключили сервер к другому каналу связи (другой шлюз). Сервер находился за NAT. Ситуация аналогичная ...
2. Подключили сервер к этому же каналу напрямую (без шлюза, без NAT). Проблема сохраняется ...

Таким образом, остается либо косяк хостера, либо косяк ПО ...

P.S. Пытаемся пока что-нибудь добиться от ТП хостера ...
 
 
#3
14.12.2012 15:22:05
Данные в любом случае не теряются. Если подключение оборвалось, то inetserver переподключается к серверу.
Между этим сообщением и предыдущей записью в БД по этому потоку сколько времени прошло?
На сервере MySQL выполните пожалуйста запросы:
SHOW GLOBAL VARIABLES like 'wait_timeout';
SHOW GLOBAL VARIABLES like 'interactive_timeout';
 
 
#4
14.12.2012 15:57:45
Цитата
Максим Саяпин пишет:
Данные в любом случае не теряются. Если подключение оборвалось, то inetserver переподключается к серверу.
...

Теряться может и не теряются, но в базу не попадают ...
Цитата
Максим Саяпин пишет:
...
Между этим сообщением и предыдущей записью в БД по этому потоку сколько времени прошло?
...

более 2-х минут ...
Цитата
Максим Саяпин пишет:
...
На сервере MySQL выполните пожалуйста запросы:
SHOW GLOBAL VARIABLES like 'wait_timeout';
SHOW GLOBAL VARIABLES like 'interactive_timeout';

Код

wait_timeout    300
interactive_timeout    28800


P.S. IS ver. 3.2.0.286
 
 
#5
14.12.2012 16:12:23
Цитата
Алексей Федотов пишет:
Код


wait_timeout    300

interactive_timeout    28800




Скорее всего в этом и проблема. У Вас установлена MySQL с нестандартной настройкой wait_timeout. В нашем дистрибутиве включена MySQL с wait_timeout = 28800.
Чтобы исправить, в my.cnf (my.ini) в секции
[mysqld]
нужно добавить 2 строки
wait_timeout=28800
interactive_timeout=28800

затем перезапустите демон (службу) MySQL
 
 
#6
14.12.2012 16:22:33
Максим Саяпин, мы не можем изменять настройки MySQL, ибо он на площадке хостера. Установить параметр wait_timeout в значение 8 часов, которое Вы предлагаете, для них непозволительная роскошь!

Однако, текущее значение - 5 минут, но проблемы начинаются при паузе между событиями менее данного времени (от 2-3 минут) ...
 
 
#7
14.12.2012 16:46:18
Цитата
Алексей Федотов пишет:
Максим Саяпин, мы не можем изменять настройки MySQL, ибо он на площадке хостера. Установить параметр wait_timeout в значение 8 часов, которое Вы предлагаете, для них непозволительная роскошь!

Это обычная проблема использования хостинга - нет возможности настраивать сервер под свои нужды.
 
 
#8
27.12.2012 09:26:11
В общем, провели еще один блиц-эксперимент на сторонней площадке с таймаутом в 8 часов. Все работает вроде бы как ...

Если будет возможность, попробуем поиграться со значением данного параметра ...
 
 
#9
12.07.2018 09:17:34
У меня эта ошибка возникла когда PCN6 и InetServer с Mysql работали на одном компьютере, но было запущено много программ. Сигнал был принят, но не вывелся в PCN6.

Цитата

12.07.2018 8:54:59:807 # === "AT+CMGL="ALL"/r/r/n+CMGL: 0,"REC UNREAD","+79995555444",,"18/07/06,10:25:30+12"/r/n300218113101005E/r/n/r/nOK"
12.07.2018 8:54:59:807 # AT+CMGL="ALL"

+CMGL: 0,"REC UNREAD","+79995555444",,"18/07/06,10:25:30+12"
300218113101005E

OK
12.07.2018 8:54:59:812 # BEGIN: saveMessages
12.07.2018 8:54:59:812 # >>> "AT+CMGD=0"
12.07.2018 8:54:59:812 # wait for response
12.07.2018 8:54:59:855 # === "AT+CMGD=0/r/r/nOK"
12.07.2018 8:54:59:855 # AT+CMGD=0

OK
12.07.2018 8:54:59:855 # Разбираем сообщение: "300218113101005E"
12.07.2018 8:54:59:855 # unpacked: "300218113101005E"
12.07.2018 8:54:59:872 # ACID event: 300218113101005E
12.07.2018 8:55:01:186 # [ERROR] (MyAddConactIDToDataBase): Lost connection to MySQL server during query Socket error on read. WSAGetLastError return 10053($2745)
12.07.2018 8:55:01:201 # *** "+CMGL:" not found in modem response: "OK"
12.07.2018 8:55:01:201 # End: saveMessages
12.07.2018 8:55:02:212 # BEGIN: WaitForNet - Ожидание регистрации в сети
12.07.2018 8:55:02:212 # >>> "AT+CNMI=0"
12.07.2018 8:55:02:212 # wait for response
12.07.2018 8:55:02:255 # === "AT+CNMI=0/r/r/nOK"
12.07.2018 8:55:02:255 # >>> "AT+CREG?"
12.07.2018 8:55:02:255 # wait for response
12.07.2018 8:55:02:305 # === "AT+CREG?/r/r/n+CREG: 0,1"
12.07.2018 8:55:02:305 # wait for data
12.07.2018 8:55:03:355 # no data received
12.07.2018 8:55:03:355 # COM порт открыт и модем в сети
12.07.2018 8:55:03:355 # END: WaitForNet - Ожидание регистрации в сети
12.07.2018 8:55:03:355 # >>> "AT+CMGF=1"
12.07.2018 8:55:03:355 # wait for response
12.07.2018 8:55:03:398 # === "AT+CMGF=1/r/r/nOK"
12.07.2018 8:55:03:398 # >>> "AT+CMGL="ALL""
12.07.2018 8:55:03:398 # wait for response
12.07.2018 8:55:03:445 # === "AT+CMGL="ALL"/r/r/nOK"
12.07.2018 8:55:03:445 # AT+CMGL="ALL"



Версия 6.3.0.704
 
 
#10
12.07.2018 12:12:57
Видимо в этом потоке у вас редко приходят события. Если события приходят раз в сутки, необходимо увеличить таймаут wait_timeout=172800
interactive_timeout=172800
 
 
 
Страницы: 1