slavikeks Posted January 1, 2014 Posted January 1, 2014 Здравствуйте всех с Новым Годом! Проблемма такая: при запуске 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 Посоветуйте что-нибудь пожалуйста. Вставить ник Quote
NiTr0 Posted January 1, 2014 Posted January 1, 2014 Если база в InnoDB - делайте бекап с ключиком --single-transaction. Вставить ник Quote
slavikeks Posted January 1, 2014 Author Posted January 1, 2014 Биного! Бинго! Огромное спасибо! помогло, а пока таже база была в MYISAM без ключика работало. Ещё раз спасибо, с Новым Годом Вас! Вставить ник Quote
Mackiavelly Posted January 16, 2014 Posted January 16, 2014 А если база не InnoBD?.. Вставить ник Quote
NiTr0 Posted January 16, 2014 Posted January 16, 2014 Сливать воду. Т.к. только иннодб поддерживает транзакции. В прочих случах - на выходе будет каша из данных (порой - верная, порой - бредовая) вместо консистентного бекапа. Вставить ник Quote
slavikeks Posted January 17, 2014 Author Posted January 17, 2014 Блин рано я обрадовался. До сегодняшнего дампа всё работало замечательно, а сегодня опять упал радиус с теме же ошибками в логе. Когда запускаю mysqldump из 10 раз примерно 4 раза радиус падает с теме же симптомами (сначала начинает жрать больше памяти, а когда доходит до 900 мб падает.) а в случаях удачного дамиа радиус даже не вздрагивает. Размер бекапа базы 620мб и каждый день ростёт. Вставить ник Quote
adsh Posted January 17, 2014 Posted January 17, 2014 По нормальному радиус должен не падать, а тормозить. Посмотрите, есть ли его свежая версия и поищите в гугле эту ошибку. Как временное решение попробуйте его останавливать на время бекапа. Вставить ник Quote
slavikeks Posted January 17, 2014 Author Posted January 17, 2014 временное решение у меня по лучше есть, я его monit'ом подпёр Вставить ник Quote
Painter Posted January 17, 2014 Posted January 17, 2014 Тоже сталкивался с такими проблемами. Потом сравнили время падений с кроном, оказалось падает во время бекапов. Перевели базу в innodb и добавили ключ "--single-transaction" к mysqldump. А потом вообще настроили репликацию базы данных и делаем бекап с другого сервера. Вставить ник Quote
slavikeks Posted January 17, 2014 Author Posted January 17, 2014 Значит у Вас тоже в innodb и ключом периодически падало? Вставить ник Quote
Painter Posted January 17, 2014 Posted January 17, 2014 не, не падало... не помню, сколько по времени занимал бекап и какого размера была таблица. Еще была такая же проблема с памятью фрирадиуса во время использования биллинга Abills, там в функции выделения рандомного ip адреса, ставится лок на таблицу, а после выделения адреса снимается. А у нас стоял пул из 65535 адресов и эта функция долго отрабатывала если одновременно сотня пользователей пытается подключиться (например во время фейла pppoe-сервера или в начале месяца). фрирадиус умирал за пару минут с 12 гигами памяти :) Возможно это особенность работы фрирадиус+rlm_perl. В итоге мы нашли узкое место и уменьшили пул адресов с 65535 до 4096. Но искали это место долго. Тоже был костыль - monit перезапускал freeradius при превышении определенного лимита занятой памяти. Еще попробуйте увеличить таймаут на радиус-клиенте, может он мало ждет и шлет повторный запрос. Я в mysql слабо разбираюсь... c ключом --single-transaction таблицы не лочатся, а изменения пишутся в какое-то другое место, пока бекап не закончится. Если у вас продолжаются проблемы с фрирадиусом, то где-то проблема с производительностью. Включите в нем логов побольше. Может база данных начинает тормозить из-за ввода/вывода во время бекапа. Вставить ник Quote
AlKov Posted January 18, 2014 Posted January 18, 2014 А потом вообще настроили репликацию базы данных и делаем бекап с другого сервера. Самое логичное и 100% рабочее решение. Сам пользуюсь уже несколько лет. А бэкапить базу на "живом" радиусе, ИМХО, вообще зло и нереально без проблем. Единственное серъёзное "НО" в варианте с репликой - это вероятность бэкапа при упавшей реплике.. Перед бэкапом желательно убедиться, что она (реплика) живая. Вставить ник Quote
adsh Posted January 18, 2014 Posted January 18, 2014 А бэкапить базу на "живом" радиусе, ИМХО, вообще зло и нереально без проблем. Здесь глюк не в бекапе, в самом радиусе - он не должен падать, должен тормозить или выдавать таймаут. Фиксить радиус. Вставить ник Quote
alexmern Posted January 18, 2014 Posted January 18, 2014 (edited) Запустить через exec, а не rlm_perl пробовал? Edited January 18, 2014 by alexmern Вставить ник Quote
alkanaft Posted January 18, 2014 Posted January 18, 2014 страдание дурью это. при дампе таблицы она лочится на и если дампить долго и много --- получай полный отвал приложения от базы, вам коллеги правильно про репликацию и про архивирование с реплики сказали это самое правильное решение. Вставить ник Quote
adsh Posted January 18, 2014 Posted January 18, 2014 Всё правильно, кроме одного - приложение при отвале от базы не должно падать. Вставить ник Quote
alkanaft Posted January 18, 2014 Posted January 18, 2014 ну это уже на совести авторов приложения... Вставить ник Quote
alexmern Posted January 18, 2014 Posted January 18, 2014 страдание дурью это Проблема в самом freeradius и такое его падение может произойти не только при бекапе, а при любом другом локе бд. Вставить ник Quote
alkanaft Posted January 18, 2014 Posted January 18, 2014 тогда слезайте на авторизацию перловым скриптом, с кэшем запросов в памяти, с отдельным "драйвером" базы данных, который будет работать с базой и при её отвале накапливать входящий поток с радиуса и делать некое одно или несколько действий чтобы её вернуть к жизни и отдавать в этот момент некие заранее прокешированные из базы данные Вставить ник Quote
k781 Posted February 1, 2018 Posted February 1, 2018 А у меня еще интереснее отваливается первого числа всегда Вставить ник Quote
kayot Posted February 1, 2018 Posted February 1, 2018 @k781 Ничего интересного. Криво настроена ротация логов. Вставить ник Quote
GrandPr1de Posted February 1, 2018 Posted February 1, 2018 радиус очень нежный в этом плане, я б его подпирал чем-то системд с каких-то пор, пока сервис не принудительно остановлен будет перезапускать приложуху ну и monit всегда есть Вставить ник Quote
kayot Posted February 1, 2018 Posted February 1, 2018 Очень спорно. У нас радиус сам по себе не падает, база бекапится ежедневно. Никаких подпорок или хитрых настроек нет, база в innodb, бекап снимается с --single-transaction Вставить ник Quote
s.lobanov Posted February 5, 2018 Posted February 5, 2018 Ну очевидно же. Сделать репликацию master-slave и бэкапить слейв Вставить ник Quote
YuryD Posted February 5, 2018 Posted February 5, 2018 Рекомендую mysqlhotcopy, она хоть и платная, но лицензию можно и слегка hex-едитором попилить. Комментариев и рекомендаций не будет:) И этого я не делал :) Я ж не какер :) там туповатая защита была.... Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.