slavikeks Posted January 1, 2014 · Report post Здравствуйте всех с Новым Годом! Проблемма такая: при запуске 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
NiTr0 Posted January 1, 2014 · Report post Если база в InnoDB - делайте бекап с ключиком --single-transaction. Share this post Link to post Share on other sites
slavikeks Posted January 1, 2014 · Report post Биного! Бинго! Огромное спасибо! помогло, а пока таже база была в MYISAM без ключика работало. Ещё раз спасибо, с Новым Годом Вас! Share this post Link to post Share on other sites
Mackiavelly Posted January 16, 2014 · Report post А если база не InnoBD?.. Share this post Link to post Share on other sites
NiTr0 Posted January 16, 2014 · Report post Сливать воду. Т.к. только иннодб поддерживает транзакции. В прочих случах - на выходе будет каша из данных (порой - верная, порой - бредовая) вместо консистентного бекапа. Share this post Link to post Share on other sites
slavikeks Posted January 17, 2014 · Report post Блин рано я обрадовался. До сегодняшнего дампа всё работало замечательно, а сегодня опять упал радиус с теме же ошибками в логе. Когда запускаю mysqldump из 10 раз примерно 4 раза радиус падает с теме же симптомами (сначала начинает жрать больше памяти, а когда доходит до 900 мб падает.) а в случаях удачного дамиа радиус даже не вздрагивает. Размер бекапа базы 620мб и каждый день ростёт. Share this post Link to post Share on other sites
adsh Posted January 17, 2014 · Report post По нормальному радиус должен не падать, а тормозить. Посмотрите, есть ли его свежая версия и поищите в гугле эту ошибку. Как временное решение попробуйте его останавливать на время бекапа. Share this post Link to post Share on other sites
slavikeks Posted January 17, 2014 · Report post временное решение у меня по лучше есть, я его monit'ом подпёр Share this post Link to post Share on other sites
Painter Posted January 17, 2014 · Report post Тоже сталкивался с такими проблемами. Потом сравнили время падений с кроном, оказалось падает во время бекапов. Перевели базу в innodb и добавили ключ "--single-transaction" к mysqldump. А потом вообще настроили репликацию базы данных и делаем бекап с другого сервера. Share this post Link to post Share on other sites
slavikeks Posted January 17, 2014 · Report post Значит у Вас тоже в innodb и ключом периодически падало? Share this post Link to post Share on other sites
Painter Posted January 17, 2014 · Report post не, не падало... не помню, сколько по времени занимал бекап и какого размера была таблица. Еще была такая же проблема с памятью фрирадиуса во время использования биллинга 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
AlKov Posted January 18, 2014 · Report post А потом вообще настроили репликацию базы данных и делаем бекап с другого сервера. Самое логичное и 100% рабочее решение. Сам пользуюсь уже несколько лет. А бэкапить базу на "живом" радиусе, ИМХО, вообще зло и нереально без проблем. Единственное серъёзное "НО" в варианте с репликой - это вероятность бэкапа при упавшей реплике.. Перед бэкапом желательно убедиться, что она (реплика) живая. Share this post Link to post Share on other sites
adsh Posted January 18, 2014 · Report post А бэкапить базу на "живом" радиусе, ИМХО, вообще зло и нереально без проблем. Здесь глюк не в бекапе, в самом радиусе - он не должен падать, должен тормозить или выдавать таймаут. Фиксить радиус. Share this post Link to post Share on other sites
alexmern Posted January 18, 2014 (edited) · Report post Запустить через exec, а не rlm_perl пробовал? Edited January 18, 2014 by alexmern Share this post Link to post Share on other sites
alkanaft Posted January 18, 2014 · Report post страдание дурью это. при дампе таблицы она лочится на и если дампить долго и много --- получай полный отвал приложения от базы, вам коллеги правильно про репликацию и про архивирование с реплики сказали это самое правильное решение. Share this post Link to post Share on other sites
adsh Posted January 18, 2014 · Report post Всё правильно, кроме одного - приложение при отвале от базы не должно падать. Share this post Link to post Share on other sites
alkanaft Posted January 18, 2014 · Report post ну это уже на совести авторов приложения... Share this post Link to post Share on other sites
alexmern Posted January 18, 2014 · Report post страдание дурью это Проблема в самом freeradius и такое его падение может произойти не только при бекапе, а при любом другом локе бд. Share this post Link to post Share on other sites
alkanaft Posted January 18, 2014 · Report post тогда слезайте на авторизацию перловым скриптом, с кэшем запросов в памяти, с отдельным "драйвером" базы данных, который будет работать с базой и при её отвале накапливать входящий поток с радиуса и делать некое одно или несколько действий чтобы её вернуть к жизни и отдавать в этот момент некие заранее прокешированные из базы данные Share this post Link to post Share on other sites
k781 Posted February 1, 2018 · Report post А у меня еще интереснее отваливается первого числа всегда Share this post Link to post Share on other sites
kayot Posted February 1, 2018 · Report post @k781 Ничего интересного. Криво настроена ротация логов. Share this post Link to post Share on other sites
GrandPr1de Posted February 1, 2018 · Report post радиус очень нежный в этом плане, я б его подпирал чем-то системд с каких-то пор, пока сервис не принудительно остановлен будет перезапускать приложуху ну и monit всегда есть Share this post Link to post Share on other sites
kayot Posted February 1, 2018 · Report post Очень спорно. У нас радиус сам по себе не падает, база бекапится ежедневно. Никаких подпорок или хитрых настроек нет, база в innodb, бекап снимается с --single-transaction Share this post Link to post Share on other sites
s.lobanov Posted February 5, 2018 · Report post Ну очевидно же. Сделать репликацию master-slave и бэкапить слейв Share this post Link to post Share on other sites
YuryD Posted February 5, 2018 · Report post Рекомендую mysqlhotcopy, она хоть и платная, но лицензию можно и слегка hex-едитором попилить. Комментариев и рекомендаций не будет:) И этого я не делал :) Я ж не какер :) там туповатая защита была.... Share this post Link to post Share on other sites
