Форум Сайтостроение Администрирование серверов

Проблема с FEDERATED tables и запросами к ним

M
На сайте с 22.06.2007
Offline
55
marienplatz
800

Возник такой вопрос по FEDERATED tables. Есть таблиза на одном сервере там лежат данные клиентов (назовем хостинг 1) и ест ее federated на другом (назовем хостинг 2). До последнего времени все нормально работало и вот с прошлой недели начались проблемы, при чем странные.

Допустим довольно часто надо сделать запрос к federated table вида SELECT * FROM table - он висит ровно три минуты и потом выдает: Error Code: 1159 Got timeout reading communication packets

Иду на хостинг, где физически лежит та таблица, проверяю базу, все нормально, не битая.

Иду назад в хостинг 2 и пишу запрос типа SELECT * FROM table WHERE id=1 - работает

Ну ладно, может дело в обьеме данных, если выбирать все, но применяю фиктивный WHERE: SELECT * FROM table WHERE id>0 - выдает все записи, длится не больше 0,2 Секунды. В итоге получается, что не работает только запрос SELECT * FROM table (без WHERE!)

В итоге нашел типа "решение", которое помогло всего на два дня - на первом хостинге скопировал все данние в другую таблицу, на втором хостинге удалил старую federated и создал новую с connection string к новой таблице - заработало на всех запросах.

Ну ладно думаю, решено. И вот вчера тоже самое, но уже с новой таблицей-копией и ее federated.

Списался и горовил с обоими хостерами - типа проблема не у них и если что кивают друг на друга. Ну и как бороться с этим, может кто встречал решение, бо создавать и пересоздавать копии каждые два дня это ж не метод....

IL
На сайте с 20.04.2007
Offline
435
ivan-lev
#1

Вообще, это скорее в администрирование нужно было писать.

версия базы (на обоих серверах, надеюсь, совпадает)? пинг между хостингами стабильный? fail2ban или другая "временная" банилка не может мешать?

Можно попробовать таймауты ( connect_timeout? net_read_timeout? ) в my.cnf увеличить... хотя, видимо, какой-то из них и равен 3 минутам..

... :) Облачные серверы от RegRu - промокод 3F85-3D10-806D-7224 ( http://levik.info/regru )
Ап пр? Глобальная Дилема с ТИЦ Антиграббер контента
M
На сайте с 22.06.2007
Offline
55
marienplatz
#2

Спасибо за ответ - сижу вот читаю всякие страшилки с похожими ошибками, все же такое ощущение, что что-то там хостеры поменяли или улучшили. "Покращення" во всей красе и видимо оно теперь отлавливает connection string к federated table, достигает какого-то порога и отрубает такой коннект. Просто при копировании таблицы и создании новой федеретед таблицы поменялись только connection string в create table engine=federated... В итоге он и используется при каждом запросе и по идее вот он ответ, но чего тогда оно работает для простых запросов. Банит еще на уровне разбора самого запроса?

Версии к сожалению не совпадают - на первом где данные физически лежат MySQL-Servers 5.0.51a, на втором с федератед - 5.1.56. Тут я особо выбирать не могу - на первом у нас обычный хостинг аккаунт и у них по дефолту 5-я версия, на другом наш виртуал сервер, можно его конечно понизить до 5-й, но не знаю поможет ли это и не получится ли еще больше проблем в других местах.

Что касается пинга - ну наверное стабильный, ведь запросы с WHERE id=1 все проходят беспроблемно.

fail2ban етц - ну на первом хостинге говорят что ничего не меняли (хотя кто там проверит...), а на своем виртуальном мы тоже ничего такого не ставили. И хостер тоже разводит руками

connect_timeout=10, net_read_timeout=30, никого с 180 не нашел, может если их там конечно в разном порядке поскладывать, то и получится 180, но... странно это все :)

А можно попросить администрацию перенести вопрос в раздел "Администриривание"?

PhpBB3 - требуется помощь Не работает в а masterhost в дауне

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий