Jump to content
Калькуляторы

Падает 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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Edited by alexmern

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

@k781 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this