ukmclient: отсутствует связь с сервером. Обратитесь к администратору : УКМ-4

Друзья! После перезагрузки кассы на экране появляются сообщения об ошибках, а в логах ukmclient вижу ошибки:

12:49:17.075: 0xad1f2b40: INFO: replication_from_server: Получение данных от сервера начато
12:49:17.123: 0xb5a1a980: FATAL: diag: КОД НЕИЗВЕСТЕН НЕИЗВЕСТНАЯ ОШИБКА При исполнении скрипта 'ukm.lua' произошла ошибка: std::runtime_error: 'При исполнении скрипта 'register.lua' произошла ошибка: std::runtime_error: 'Query failed: Error(2013) Lost connection to MySQL server during query: SQL select profile_id from trm_in_luaukm_profile where active = 1 and deleted = 0''
12:49:17.127: 0xad1f2b40: WARNING: debug#/home/user/build_ukm/build-br-86-2019_04_11_12_31_20/ukm/libukm/cprotocolmanager.cpp(302) TableAdjuster: Отсутствует связь с сервером. Обратитесь к администратору.
12:49:17.128: 0xad1f2b40: INFO: replication_from_server: Получение данных от сервера прервано из-за ошибки
12:50:53.730: 0xb59ae980: WARNING: debug#/home/user/build_ukm/build-br-86-2019_04_11_12_31_20/ukm/libukm/icontext.cpp(65) exec_do: Query failed: Error(2013) Lost connection to MySQL server during query: SQL update cnv_table_versions set latest_version = 550, oldest_version = 0 where mysterious_id = 1001008 and table_name = 'trm_out_logout'
12:50:58.528: 0xacaf2b40: INFO: NtlpTrnManager: Remote username: ukm3w5e111lb0q3k. ptr = ffffffffb4f03320
12:50:58.534: 0xacaf2b40: INFO: NtlpTrnManager: Answer for 192.168.6.202 host: remotehost, db = ukmclient, port = 3306, user = ukm3w5e111lb0q3k
12:50:58.814: 0xacaf2b40: INFO: replication_from_server: Получение данных от сервера начато
12:50:58.851: 0xacaf2b40: WARNING: debug#/home/user/build_ukm/build-br-86-2019_04_11_12_31_20/ukm/libukm/cprotocolmanager.cpp(302) TableAdjuster: Отсутствует связь с сервером. Обратитесь к администратору.
12:50:58.852: 0xacaf2b40: INFO: replication_from_server: Получение данных от сервера прервано из-за ошибки
12:51:04.706: 0xacaf2b40: INFO: NtlpTrnManager: Remote username: ukm3w5e111lb0q3k. ptr = ffffffffb4f03320
12:51:04.712: 0xacaf2b40: INFO: NtlpTrnManager: Answer for 192.168.6.202 host: remotehost, db = ukmclient, port = 3306, user = ukm3w5e111lb0q3k
12:51:05.812: 0xacaf2b40: INFO: replication_to_server: Передача данных на сервер завершена
12:51:29.714: 0xacaf2b40: INFO: NtlpTrnManager: Remote username: ukm3w5e111lb0q3k. ptr = ffffffffb4f03320
12:51:29.719: 0xacaf2b40: INFO: NtlpTrnManager: Answer for 192.168.6.202 host: remotehost, db = ukmclient, port = 3306, user = ukm3w5e111lb0q3k
12:51:29.991: 0xacaf2b40: INFO: replication_from_server: Получение данных от сервера начато
12:51:30.040: 0xacaf2b40: WARNING: debug#/home/user/build_ukm/build-br-86-2019_04_11_12_31_20/ukm/libukm/cprotocolmanager.cpp(302) TableAdjuster: Отсутствует связь с сервером. Обратитесь к администратору.
12:51:30.041: 0xacaf2b40: INFO: replication_from_server: Получение данных от сервера прервано из-за ошибки

В логах mysql тоже видно, что он циклически перезапускается:

200106 08:04:30 mysqld started
200106 8:04:31 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
200106 8:04:31 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
InnoDB: Log scan progressed past the checkpoint lsn 1 2451876118
200106 8:04:31 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1 2455623375
200106 8:04:34 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
200106 8:04:39 InnoDB: Started; log sequence number 1 2455623375
200106 8:04:39 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.
Version: '5.0.67' socket: '/tmp/mysql.sock' port: 3306 Source distribution
200106 8:04:49InnoDB: Assertion failure in thread 278543 in file trx0undo.c line 515
InnoDB: Failing assertion: free + TRX_UNDO_LOG_XA_HDR_SIZE < UNIV_PAGE_SIZE - 100
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
200106 8:04:49 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=1048576
read_buffer_size=524288
max_used_connections=6
max_connections=300
threads_connected=6
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 231424 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8c0a710
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbd9fcc88, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x8168b09
0x82ecfe8
0xb7562c18
0x82edc0a
0x82eb14a
0x82de94c
0x82d1fda
0x82cb94b
0x82cbf00
0x82b4a2c
0x82b39be
0x82b32d8
0x82b270e
0x82a0f58
0x821ccc4
0x81d84f6
0x817eaeb
0x81849bf
0x817c96d
0x8187fa9
0x817bbac
0xb77836de
0xb760fbc7
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8bfed50 = update cnv_table_versions set latest_version = 14937, oldest_version = 853 where mysterious_id = 1 and table_name = 'trm_in_classif'
thd->thread_id=7
The manual page at dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Получается, что mysql не может обработать запрос query at 0x8bfed50 = update cnv_table_versions set latest_version = 14937, oldest_version = 853 where mysterious_id = 1 and table_name = 'trm_in_classif'?

В /etc/my.cnf установил опцию innodb_force_recovery=1, теперь можно прочекать таблицы:
mysqlcheck -u root -pCtHDbCGK.C --all-databases
Все таблицы ОК

Сделал дамп базы ukmclient.

Какие могут быть у меня варианты?
1. Удалить базу ukmclient и восстановить из дампа?
2. Разбираться с таблицей cnv_table_versions? Только ее восстановить? Или что-то сделать с содержимым? Её назначение не знаю.

Да.
Или перезалить базу по данным сервера.
Возиться с "починкой" отдельных таблиц на кассе - обычно лишняя трата времени.

Результата нет.
В my.ini указал параметр 6, удалил базу (физически папка с базой тоже удалилась), создал пустую. Убрал параметр 6. импортировал из дампа. Ошибка та же - thd->query at 0x8bfed50 = update cnv_table_versions set latest_version = 14937, oldest_version = 853 where mysterious_id = 1 and table_name = 'trm_in_classif'.

Удалял отдельно эту таблицу cnv_table_versions и восстанавливал из дампа - аналогично.

Что за дамп, когда и как создан?

Та же - это "Lost connection to MySQL server during query" ?

С точностью описаний у вас не очень.

Вот этот скрипт освойте.

Все эксперименты с бэкапом, удалением базы, созданием новой происходили после остановки net stop ukmclient

Дамп создан следующим образом:
mysqldump -u root -pCtHDbCGK.C ukmclient > /backup/dumpukm.sql

Дамп заливался так:

mysql -uroot -pCtHDbCGK.C -Dukmclient
drop database ukmclient;

Получаю ошибку ERROR 2013 (HY000): Lost connection to MySQL server during query

net stop mysql
В /etc/my.cnf прописываю innodb_force_recovery=1,
net start mysql
Смотрю /usr/local/mysql-5.0.67-ukm/var/localhost.err - система видит параметр innodb_force_recovery и предупреждает, что база в режиме восстановления.

mysql -uroot -pCtHDbCGK.C -Dukmclient
drop database ukmclient;
Получаю ошибку соединения с сервером mysql.

Далее прописываю innodb_force_recovery=4 - ошибка соединения при удалении базы сохраняется. Ставлю innodb_force_recovery=6, и тогда база удаляется со статусом ОК.

mysql -u root -pCtHDbCGK.C -e "create database ukmclient";

В /etc/my.cnf убираю параметр innodb_force_recovery=6, перезапускаю mysql.

mysql -u root -pCtHDbCGK.C ukmclient < /backup/dumpukm.sql; - результат ОК. Кол-во совпадает с исходной базой.

Запускаю net start ukmclient, смотрю лог /usr/local/ukmclient/2020/01/2020-01-08.log и вижу старые ошибки:

WARNING: debug#/home/user/build_ukm/build-br-86-2019_04_11_12_31_20/ukm/libukm/icontext.cpp(65) exec_do: Query failed: Error(2013) Lost connection to MySQL server during query: SQL update cnv_table_versions set latest_version = 550, oldest_version = 0 where mysterious_id = 1001008 and table_name = 'trm_out_logout'

INFO: replication_from_server: Получение данных от сервера начато
00:17:06.872: 0xacaf2b40: WARNING: debug#/home/user/build_ukm/build-br-86-2019_04_11_12_31_20/ukm/libukm/cprotocolmanager.cpp(302) TableAdjuster: Отсутствует связь с сервером. Обратитесь к администратору.
00:17:06.873: 0xacaf2b40: INFO: replication_from_server: Получение данных от сервера прервано из-за ошибки

В /usr/local/mysql-5.0.67-ukm/var/localhost.err те же самые ошибки:
mysqld got signal 11 ;
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8bfed50 = update cnv_table_versions set latest_version = 14937, oldest_version = 853 where mysterious_id = 1 and table_name = 'trm_in_classif'

Вот эта строка с запросом "update cnv_table_versions set latest_version = …" появляется на мониторе кассира как окно с тестом запроса и кнопкой ОК.

Если остановить ukmclient, то сообщения в лог localhost.err не приходят, последняя строчка ready for connections.
Так же если переименовать папку с базой /usr/local/mysql-5.0.67-ukm/var/ukmclient в любую, например ukmclient.bak - ошибки не появляются, сервис не перезапускается.

Косвенным признаком циклического перезапуска mysql является недоступность страницы кассы в УКМ через монитор оборудования по адресу ip_adress/ukmcli/system.php - получаю ошибку DB Error: connect failed. Иногда появляется, иногда нет, если попадаю на перезапуск mysql.

Изучил страницу .../showthread.php?t=28608 - там так и советуют восстановление из бэкапа.

Изучил скрипты в dbrepair6700+ x3pack vX readme v4.7z (в той же ветке) ...attachment.php?attachmentid=9199&d=1518116605 (ссылку не могу опубликовать, не хватает прав). Не работают, видать версия кассы не совпадает ( у меня 86 сп1).

Много пишут про создание чистой базы, не из бэкапа. Меня пугает регистрация в УКМ - подскажите, есть ли инструкции по регистрации?

Изображения

	WhatsApp Image 2020-01-06 at 10.19.14.jpeg (80.4 Кб, 34 просмотров)
	WhatsApp Image 2020-01-06 at 10.19.15.jpeg (110.1 Кб, 31 просмотров)

Вложения

	localost_err.txt (7.6 Кб, 13 просмотров)
	2020-01-08.txt (14.0 Кб, 14 просмотров)

Вот нашел пост:

0. Блокируем кассу в web-е. Проверяем, что магазин и конфигурация по умолчанию соответствуют настройкам нашей кассы.
1. Заходим на кассу по ssh
2. ukmoff (останавливаем автозапуск ukmclient)
3. \etc\init.d\ukmclient stop или service ukmclient stop
4. \etc\init.d\mysql stop или service mysql stop
5. делаем копию (\usr\local\mysql\var\ и удаляем файлы базы данных (\usr\local\mysql\var\ ib_logfile0, ib_logfile1, ibdata1)
6. скачиваем с сервера
wget хттп://ukmserver/ukminstall/ukmcli-build.tgz[
достаем из него ukm.sql и setver.sql
7. запускаем mysql \etc\init.d\mysql start или service mysql start
8. подключаемся к
mysql -uroot -pCtHDbCGK.C
9. удаляем базу данных
drop database ukmclient;
10. создаем её снова
create database ukmclient;
11. use ukmclient;
12. по очереди выполняем оба скачанных скрипта:
source ukm.sql;
source setver.sql;
13. выходим из mysql - exit
14. ukmon
15. \etc\init.d\ukmclient start или service ukmclient start
16. Просим кого-нибудь дойти до кассы и ввести номер кассы.
Это при уверенности что все выгружено.

Вы все правильно делаете.
Осталось набить руку.
У меня уже отработан порядок действий.

1. Сразу ставлю innodb_force_recovery=6, чтоб не мелочиться. По ощущениям, помогает в 4 случаях из 5. Автоматизация.

2. Не помогло. Обычно это "lost connection to mysql" в процессе дампа или его импорта. При желании можно покопаться. Бывает, процессы не все прибиты, бывает, еще по какой-то мелочи скрипт сбойнул, например, что-то случилось в процессе создания БД и выдачи грантов, это отловил, сделал все руками, и импорт прошел. Лично я уже этот этап прошел (лишняя трата времени) и сразу перехожу к созданию БД с нуля.

3. Ниже у вас описано как раз то, что делает скрипт создания БД. Как правило, все данные с кассы лежат на УКМ-сервере, и при пересоздании БД они будут на кассе для дальнейшего штатного закрытия смены. Достаточно заблокировать терминал в web-интерфейсе, запустить скрипт пересоздания БД, и заново зарегистрировать ее на сервере под тем же номером.

>>> Меня пугает регистрация в УКМ - подскажите, есть ли инструкции по регистрации?

Очень просто: при регистрации кассы вводите тот номер, который касса имела до переустановки БД. Будут вопросы "терминал с таким номером уже существует, вы уверены? разблокировать терминал? перенести данные?" Отвечать "да", т.е. ВВОД ШК.

4. Проблема уже в ОС, не запускается не только mysql, но и все остальное. Перезаливаем УКМ с флэшки. Если проблема аппаратная - решаем ее, замена материнки, жесткого диска и т.п. Тут бывает, и что касса была в оффлайне, и чеки потеряны, и придется эту смену учесть в ревизию.

Заблокировал кассу в УКМ. Скрипт отработал без ошибок. Однако не могу зарегистрировать её под тем же номером. Никаких подсказок в логе нет.

Изображения

	WhatsApp Image 2020-01-09 at 12.17.03.jpeg (181.9 Кб, 39 просмотров)
	WhatsApp Image 2020-01-09 at 12.17.35 (1).jpeg (119.8 Кб, 40 просмотров)
	WhatsApp Image 2020-01-09 at 12.17.35.jpeg (151.9 Кб, 39 просмотров)

Вложения

2020-01-09_txt.txt (43.0 Кб, 15 просмотров)

перезалей еще раз, кассу в вебе укм явно лочил постфактум.
//у тебя ж там сервер под боком, можно и флешку загрузочную соорудить)
///Беги из Мега-Опта, беги! xD

Попробуйте заблокировать кассу на сервере

Подключиться к mysql на кассе и выполнить

Delete from trm_in_pos;

Перезагрузить укм клиент на кассе

Зарегистрировать кассу под тем же номером