Перейти к содержимому
Калькуляторы

Падает freeradius при mysqldup FreeBSD

Здравствуйте всех с Новым Годом!

Проблемма такая: при запуске mysqldump через 15-25 сек падает радиус (сначала начинает жрать больше памяти, а когда доходит до 900 мб падает. свободной памяти есть 10гб)

В логе вот такое

Thu Jan  2 00:27:59 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 11841 - ID: 160 due to unfinished request 1745305
Thu Jan  2 00:27:59 2014 : Error: Received conflicting packet from client 10.17.0.100 port 61393 - ID: 232 due to unfinished request 1745368.  Giving up on old request.
Thu Jan  2 00:28:00 2014 : Error: Received conflicting packet from client 10.17.0.100 port 56124 - ID: 100 due to unfinished request 1745371.  Giving up on old request.
Thu Jan  2 00:28:00 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 60168 - ID: 44 due to unfinished request 1745233
Thu Jan  2 00:28:00 2014 : Error: Received conflicting packet from client 10.17.0.100 port 62127 - ID: 222 due to unfinished request 1745385.  Giving up on old request.
Thu Jan  2 00:28:00 2014 : Error: Received conflicting packet from client 10.17.0.100 port 41988 - ID: 200 due to unfinished request 1745386.  Giving up on old request.
Thu Jan  2 00:28:01 2014 : Error: Received conflicting packet from client 10.17.0.100 port 31783 - ID: 45 due to unfinished request 1745401.  Giving up on old request.
Thu Jan  2 00:28:01 2014 : Error: Received conflicting packet from client 10.17.0.100 port 50771 - ID: 17 due to unfinished request 1745402.  Giving up on old request.
Thu Jan  2 00:28:01 2014 : Error: Received conflicting packet from client 10.17.0.100 port 19000 - ID: 188 due to unfinished request 1745404.  Giving up on old request.
Thu Jan  2 00:28:01 2014 : Error: Received conflicting packet from client 10.17.0.100 port 28954 - ID: 115 due to unfinished request 1745410.  Giving up on old request.
Thu Jan  2 00:28:02 2014 : Error: Received conflicting packet from client 10.17.0.100 port 30019 - ID: 202 due to unfinished request 1745412.  Giving up on old request.
Thu Jan  2 00:28:02 2014 : Error: Received conflicting packet from client 10.17.0.100 port 62891 - ID: 245 due to unfinished request 1745413.  Giving up on old request.
Thu Jan  2 00:28:02 2014 : Error: Received conflicting packet from client 10.17.0.100 port 32222 - ID: 196 due to unfinished request 1745414.  Giving up on old request.
Thu Jan  2 00:28:02 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 32588 - ID: 199 due to unfinished request 1745415
Thu Jan  2 00:28:02 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 62692 - ID: 64 due to unfinished request 1745292
Thu Jan  2 00:28:02 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 43417 - ID: 118 due to unfinished request 1745255
Thu Jan  2 00:28:03 2014 : Error: Received conflicting packet from client 10.17.0.100 port 63087 - ID: 161 due to unfinished request 1745432.  Giving up on old request.
Thu Jan  2 00:28:03 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 11841 - ID: 160 due to unfinished request 1745305
Thu Jan  2 00:28:03 2014 : Error: Received conflicting packet from client 10.17.0.100 port 46245 - ID: 7 due to unfinished request 1745435.  Giving up on old request.
Thu Jan  2 00:28:03 2014 : Error: Received conflicting packet from client 10.17.0.100 port 21362 - ID: 21 due to unfinished request 1745437.  Giving up on old request.
Thu Jan  2 00:28:03 2014 : Error: Received conflicting packet from client 10.17.0.100 port 45513 - ID: 84 due to unfinished request 1745439.  Giving up on old request.
Thu Jan  2 00:28:04 2014 : Error: Received conflicting packet from client 10.17.0.100 port 51188 - ID: 200 due to unfinished request 1745453.  Giving up on old request.
Thu Jan  2 00:28:05 2014 : Error: Received conflicting packet from client 10.17.0.100 port 13616 - ID: 115 due to unfinished request 1745456.  Giving up on old request.
Thu Jan  2 00:28:05 2014 : Error: Received conflicting packet from client 10.17.0.100 port 33794 - ID: 215 due to unfinished request 1745457.  Giving up on old request.
Thu Jan  2 00:28:06 2014 : Error: Received conflicting packet from client 10.17.0.100 port 25324 - ID: 127 due to unfinished request 1745478.  Giving up on old request.
Thu Jan  2 00:28:06 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 32588 - ID: 199 due to unfinished request 1745415
Thu Jan  2 00:28:06 2014 : Error: Received conflicting packet from client 10.17.0.100 port 34401 - ID: 62 due to unfinished request 1745481.  Giving up on old request.
Thu Jan  2 00:28:06 2014 : Error: Discarding duplicate request from client 10.17.0.100 port 62692 - ID: 64 due to unfinished request 1745292
Thu Jan  2 00:28:06 2014 : Error: Received conflicting packet from client 10.17.0.100 port 39236 - ID: 178 due to unfinished request 1745485.  Giving up on old request.

 

radiusd: FreeRADIUS Version 2.2.2, for host amd64-portbld-freebsd9.2, built on Dec 7 2013 at 17:51:06

mysql 5.6.14

Посоветуйте что-нибудь пожалуйста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если база в InnoDB - делайте бекап с ключиком --single-transaction.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Биного! Бинго!

Огромное спасибо! помогло, а пока таже база была в MYISAM без ключика работало.

Ещё раз спасибо, с Новым Годом Вас!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сливать воду. Т.к. только иннодб поддерживает транзакции. В прочих случах - на выходе будет каша из данных (порой - верная, порой - бредовая) вместо консистентного бекапа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Блин рано я обрадовался. До сегодняшнего дампа всё работало замечательно, а сегодня опять упал радиус с теме же ошибками в логе. Когда запускаю mysqldump из 10 раз примерно 4 раза радиус падает с теме же симптомами (сначала начинает жрать больше памяти, а когда доходит до 900 мб падает.) а в случаях удачного дамиа радиус даже не вздрагивает.

Размер бекапа базы 620мб и каждый день ростёт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По нормальному радиус должен не падать, а тормозить. Посмотрите, есть ли его свежая версия и поищите в гугле эту ошибку. Как временное решение попробуйте его останавливать на время бекапа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

временное решение у меня по лучше есть, я его monit'ом подпёр

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тоже сталкивался с такими проблемами. Потом сравнили время падений с кроном, оказалось падает во время бекапов. Перевели базу в innodb и добавили ключ "--single-transaction" к mysqldump. А потом вообще настроили репликацию базы данных и делаем бекап с другого сервера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Значит у Вас тоже в innodb и ключом периодически падало?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не, не падало... не помню, сколько по времени занимал бекап и какого размера была таблица.

 

Еще была такая же проблема с памятью фрирадиуса во время использования биллинга Abills, там в функции выделения рандомного ip адреса, ставится лок на таблицу, а после выделения адреса снимается. А у нас стоял пул из 65535 адресов и эта функция долго отрабатывала если одновременно сотня пользователей пытается подключиться (например во время фейла pppoe-сервера или в начале месяца). фрирадиус умирал за пару минут с 12 гигами памяти :) Возможно это особенность работы фрирадиус+rlm_perl. В итоге мы нашли узкое место и уменьшили пул адресов с 65535 до 4096. Но искали это место долго. Тоже был костыль - monit перезапускал freeradius при превышении определенного лимита занятой памяти.

 

Еще попробуйте увеличить таймаут на радиус-клиенте, может он мало ждет и шлет повторный запрос.

 

Я в mysql слабо разбираюсь... c ключом --single-transaction таблицы не лочатся, а изменения пишутся в какое-то другое место, пока бекап не закончится. Если у вас продолжаются проблемы с фрирадиусом, то где-то проблема с производительностью. Включите в нем логов побольше. Может база данных начинает тормозить из-за ввода/вывода во время бекапа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А потом вообще настроили репликацию базы данных и делаем бекап с другого сервера.

Самое логичное и 100% рабочее решение. Сам пользуюсь уже несколько лет.

А бэкапить базу на "живом" радиусе, ИМХО, вообще зло и нереально без проблем.

Единственное серъёзное "НО" в варианте с репликой - это вероятность бэкапа при упавшей реплике..

Перед бэкапом желательно убедиться, что она (реплика) живая.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А бэкапить базу на "живом" радиусе, ИМХО, вообще зло и нереально без проблем.

Здесь глюк не в бекапе, в самом радиусе - он не должен падать, должен тормозить или выдавать таймаут. Фиксить радиус.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Запустить через exec, а не rlm_perl пробовал?

Изменено пользователем alexmern

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всё правильно, кроме одного - приложение при отвале от базы не должно падать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну это уже на совести авторов приложения...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

страдание дурью это

Проблема в самом freeradius и такое его падение может произойти не только при бекапе, а при любом другом локе бд.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

тогда слезайте на авторизацию перловым скриптом, с кэшем запросов в памяти, с отдельным "драйвером" базы данных, который будет работать с базой и при её отвале накапливать входящий поток с радиуса и делать некое одно или несколько действий чтобы её вернуть к жизни и отдавать в этот момент некие заранее прокешированные из базы данные

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А у меня еще интереснее отваливается первого числа всегда 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@k781 

Ничего интересного. Криво настроена ротация логов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

радиус очень нежный в этом плане, я б его подпирал чем-то

системд с каких-то пор, пока сервис не принудительно остановлен будет перезапускать приложуху

ну и monit всегда есть

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Очень спорно. У нас радиус сам по себе не падает, база бекапится ежедневно.

Никаких подпорок или хитрых настроек нет, база в innodb, бекап снимается с --single-transaction

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну очевидно же. Сделать репликацию master-slave и бэкапить слейв

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 Рекомендую mysqlhotcopy, она хоть и платная, но лицензию можно и слегка hex-едитором попилить. Комментариев и рекомендаций не будет:) И этого я не делал :) Я ж не какер :) там туповатая защита была....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.