Как устранить эту ошибку MariaDB? => ОШИБКА 1296 (HY000): Получена ошибка 122 «Не удается получить сообщение об ошибке» из CONNECT - PullRequest
0 голосов
/ 15 апреля 2020

Кто-нибудь знает, как я могу устранить неполадки ниже Ошибка механизма хранения MariaDB CONNECT?

ОШИБКА 1296 (HY000): Получена ошибка 122 "Не удается получить сообщение об ошибке" из CONNECT

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

Как можно отладить больше?

Я попробовал connect_xtrace = 1023. Вывод идет в mysqld.log, но все еще не так много информации, чтобы проверить дальше. Также попытался изменить драйверы JDB C, и он все тот же.

У меня установлен MariaDB-server-10.3.21-1.el7.centos.x86_64.rpm. & использую MariaDB 10.3.21.

Спасибо и наилучшими пожеланиями, KH

1 Ответ

0 голосов
/ 17 апреля 2020

Самостоятельно разрешен.

Таким образом, я понял, что пытался использовать connect_xtrace = 1023, но установил его как глобальную переменную и не установил как переменную сеанса, поэтому его влияние не было немедленным. После установки его в качестве переменной сеанса удалось отследить его до сбоя выделения памяти.

После использования таблиц JDB C механизма CONNECT для получения данных за день или 2, ошибка при выборе из хранилища CONNECT внешняя таблица механизма JDB C: «ОШИБКА 1296 (HY000): получена ошибка 122« Не удается получить сообщение об ошибке »из CONNECT» ... и ошибка при попытке создать внешнюю таблицу механизма хранения CONNECT JDB C: ОШИБКА 1030 (HY000): Получена ошибка 122 «Внутренняя (неуказанная) ошибка в обработчике» из механизма хранения CONNECT »

Я только недавно заметил, что в mysqld.log также появилось несколько строк ниже: Рабочая область: Ошибка выделения памяти : mallo c вернул Null

Итак, попытался снова устранить неполадки ...

Возможно, ранее я использовал set global connect_xtrace = 1023; который только изменяет настройки для глобального, но не текущего сеанса. Поэтому на этот раз попытался вместо этого установить сеанс connect_xtrace = 1023, и начали появляться соответствующие записи в журнале ниже.

Таким образом, ключом было установить connect_xtrace = 1023 для сеанса. Мой плохой.

В любом случае, записи mysqld.log теперь содержат больше информации: ... Новый CONNECT 0x7fc46403de80, таблица: mssql_CURRENCY_RATE open: name =. / _ TMP_D / mssql_CURRENCY_RATE mode = 2 test = 18 PlugInit: Language = ' Null 'SareaAllo c: ошибка выделения памяти: mallo c возвращено. Null Delete CONNECT 0x7fc46403de80, таблица: mssql_CURRENCY_RATE, xp = (nil) count = 0 ... PlugInit: Language =' Null 'SareaAllo c: распределение памяти не удалось: mallo c вернул Null New CONNECT 0x7fc46403de80, таблица: mssql_CURRENCY_RATE open: name =. / _ TMP_D / mssql_CURRENCY_RATE mode = 2 test = 18 ...

Поэтому попытался установить намного более низкое значение connect_work_s (по умолчанию), и все снова заработало! Больше ошибок нет.

Таким образом, можно заключить, что механизм CONNECT прекратил выделять средства на основе connect_work_size через некоторое время, так как mysqld & OS со временем использовали все больше и больше памяти.

Тогда попытался установить connect_work_size на 1 ГБ и снова попытался выбрать, все еще работает. Увеличение еще на 1 ГБ и выберите еще раз, повторяя еще несколько раз. Начал замечать из mysqld.log, что память, установленная для connect_work_size, перестает следовать через некоторое время и используется последнее успешное значение. (это похоже на документацию).

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

Было бы здорово, если бы: a) connect_work_size были реализованы аналогичным образом to: innodb_buffer_pool_instances, innodb_buffer_pool_chunk_size, innodb_buffer_pool_size b) может быть полезно иметь что-то вроде connect_work_size_guaranteed, которое может быть объемом выделенной памяти, но никогда не освобожденным, чтобы иметь минимальную гарантию памяти для плагина. c) иметь более подробную документацию; ie: если приблизительный размер строки таблицы равен xxx, а количество строк, запрошенных в памяти в любой момент времени, равно yyy, то connect_work_size должно быть (xxx * yyy) * 1.1.

...