New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mysqldump + mysql restore bug #1924
Comments
|
@PavelShilin89 please reproduce and prepare an MRE from the provided data to find out what exactly causes the issue. |
no progress? |
I've reproduced the issue on our side:
Version:
|
The MRE is:
results in:
and this in the searchd log:
|
@donhardman pls check if this is smth you should fix or it's an issue of the SQL parser, then it makes sense to reassign to @djklim87 . |
Вот это, кстати, постоянная ошибка для всех строк. В том числе успешно вставленных. Ну, мне кажется, это происходит потому, что мы вставляем в MVA атрибут строку, а не набор чисел. |
Если вы видите ошибку (не ворнинг, а ошибку), но документ при этом вставляется, то это баг (независимо от текста ошибки). Скажите в таком случае, как повторить это поведение. |
We're not currently using an SQL parser for this case, but we probably need to validate and understand the original cause of the issue. We've already fixed this before, but it might be due to some very specific and unique cases in the data. I'll check and make sure that regular expressions can't be used for this and confirm if we really need to switch to something like an SQL parser. |
Fixed in 0c74eb3 :
|
В тех же самых логах и в моем примере выше это наблюдалось. 4 документа вставлены, на всех четырех - такой ворнинг в searchd.log, падаем на пятом. При этом документы вставлены, MVA атрибуты записаны корректно. |
А, вы про query log. Да, так было в 6.2.12, что:
приводит к
Это уже исправлено в dev версии. Теперь аналогичные запросы выглядят так в query log'е:
При этом ошибка |
У меня видимо неправильная версия 6.2.12, потому что выдавалась :) |
Нужен MRE демонстрирующий это. В таком случае это серьёзный баг, который мы не фиксили. Показывать пользователю ошибку на инсерте и при этом вставлять документ - это неправильно. |
Describe the bug
Есть RT-индекс, заполняется скриптом (SQL-запросами), заполняется успешно, без ошибок. Индекс создан через файл конфига:
Дампим:
(уже первая бага: перечисление таблиц/индексов игнорируется, дампится ВСЁ)
Очищаем индекс:
Пытаемся залить дамп:
Проверяем, что там у нас в индексе?
То есть, что-то залилось, НО...
Что там на 26-ой строчке? Вроде бы валидный инсерт:
Последовательным удалением проблемных строк выяснилось, что проблемные запросы:
итд.
Поэтому я оставляю в файле 100 latest строк и прикрепляю его к issue.
_articles.zip
Describe the environment:
Messages from log files:
Оставляю значимое:
Интересно, что первая ошибка присутствует у ВСЕХ строк, в том числе и успешно вставленных.
(по SQL-файлу видно, что вставляется успешно)
The text was updated successfully, but these errors were encountered: