Самостоятельно разрешен.
Таким образом, я понял, что пытался использовать 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.