Sportcar: Или ну его - не нужно держать все яйца в одной корзине?
Условие -надежность, цена в пределах 1К рублей в месяц, хорошие отзывы по хостобзорам...
Конечно не держать все яйца в одной корзине, почитайте тут темы шаред хостингов, у некоторых неделями сайты не работают и бэкапы людям не отдают. А еще привыкните к одной корзине и перенос сайтов в другую будет большой проблемой.
ThePriest: Маломощный сервер-реплика никаких запросов не выполняет. Удалить он ничего не может.
Все что он делает - копирует к себе бинлог в реальном времени.
Это не SQL запросы, а события апдейтов, он их все выполняет. И если пришло событие удалить таблицу - он ее удалит. Он не копирует к себе бинлог, а именно применяет. Можете проверить. Как это вы так много лет занимаетесь и не понимаете, как mysql работает?
И там все правильно написано real-time back-up - это и есть копия базы в текущий момент, а не в любой момент времени, т.е. откатиться на день никак нельзя.
Это вы предлагаете бинлог для бэкапов приспособить. А я не предлагаю, можете наступать на эти грабли сколько влезет.
Но я расскажу, так и быть. Бэкап - не репликация. Он нужен для ситуаций, когда какие-то данные потерлись, например был послан запрос, который удалил полностью какую-то отдельную часть данных, например таблицу, если это sql база данных, этот же запрос успешно выполниится на вашем маломощном сервере-реплике и вы останитесь без таблицы на обоих серверах. Восстановление этой таблицы, как и любых других данных из бэкапа не может длиться месяц, вы скорее лишитесь бизнеса, потому бэкап должен быть структурирован и в простых форматах, чтобы с ним было очень легко разобраться и работать, но никак не бинлог.
А то что mysql полон всякой неадекватчины - это мы в курсе, на их решения нужно смотреть, как на идеи студентов, они как и студенты не сильно задумываются о последствия, а вы можете загробить свой проект.
Так это не для бэкапа, а для репликации, в нем будут все повторяющиеся апдейты присутствовать, зачем их в бэкап ложить? Конечно такое будет долго рековэриться, все апдейты за все существование проекта нужно будет выполнить за раз.
Den73: бывают которые парсят ответ сервера и вынимают куку - таких обмануть легко.
еще бывают на основе настоящего браузера - с такими справиться намного сложнее тут уже нужен поведенческий анализ каждого клиента и за ранее накопленная статистика по сайту так что реалтайм можно забыть, там свои подходы, я пока не видел такую умную брутилку.
Рилтайм работает, только конечно не так, что в момент атаки включили, статистика должна копиться заранее. Это уже из категории средств предотвращения атак.
cap: получается при следующем обращении, если бот съел куку, .htaccess его пропустит?
Все способы с кукой пропустят ботов, которые работают на движке реального браузера, например на фантоме. Такие боты обнаруживаются только сбором статистики и анализом аномального поведения.
Mikanoshi: Поделитесь?) При условии, что подбор идёт запросами ничем не отличающимися от реальных посетителей, а логины и профили на сайтах должны работать.
Неотличимы, да отличимы :)
Я уже кому-то один простой давал, можно в паблик выложить [удалено] , есть еще с limit_req'ом варианты и совмещенный, для придержания запросов всех-всех ботов.
globalmoney: Что-то коммерческое там вообще лучше не держать, т.к. в итоге будет больше потерь, чем экономии!
Например, каких? Вот упадет или заблокируют сервер, ну и пускай, есть в других ДЦ, которые спокойно примут трафик, а тем временем смогу заказать новый.
Или ну его - не нужно держать все яйца в одной корзине?
Условие -надежность, цена в пределах 1К рублей в месяц, хорошие отзывы по хостобзорам...
Конечно не держать все яйца в одной корзине, почитайте тут темы шаред хостингов, у некоторых неделями сайты не работают и бэкапы людям не отдают. А еще привыкните к одной корзине и перенос сайтов в другую будет большой проблемой.
Маломощный сервер-реплика никаких запросов не выполняет. Удалить он ничего не может.
Все что он делает - копирует к себе бинлог в реальном времени.
Это не SQL запросы, а события апдейтов, он их все выполняет. И если пришло событие удалить таблицу - он ее удалит. Он не копирует к себе бинлог, а именно применяет. Можете проверить. Как это вы так много лет занимаетесь и не понимаете, как mysql работает?
И там все правильно написано real-time back-up - это и есть копия базы в текущий момент, а не в любой момент времени, т.е. откатиться на день никак нельзя.
Это вы предлагаете бинлог для бэкапов приспособить. А я не предлагаю, можете наступать на эти грабли сколько влезет.
Но я расскажу, так и быть. Бэкап - не репликация. Он нужен для ситуаций, когда какие-то данные потерлись, например был послан запрос, который удалил полностью какую-то отдельную часть данных, например таблицу, если это sql база данных, этот же запрос успешно выполниится на вашем маломощном сервере-реплике и вы останитесь без таблицы на обоих серверах. Восстановление этой таблицы, как и любых других данных из бэкапа не может длиться месяц, вы скорее лишитесь бизнеса, потому бэкап должен быть структурирован и в простых форматах, чтобы с ним было очень легко разобраться и работать, но никак не бинлог.
А то что mysql полон всякой неадекватчины - это мы в курсе, на их решения нужно смотреть, как на идеи студентов, они как и студенты не сильно задумываются о последствия, а вы можете загробить свой проект.
Так это не для бэкапа, а для репликации, в нем будут все повторяющиеся апдейты присутствовать, зачем их в бэкап ложить? Конечно такое будет долго рековэриться, все апдейты за все существование проекта нужно будет выполнить за раз.
бывают которые парсят ответ сервера и вынимают куку - таких обмануть легко.
еще бывают на основе настоящего браузера - с такими справиться намного сложнее тут уже нужен поведенческий анализ каждого клиента и за ранее накопленная статистика по сайту так что реалтайм можно забыть, там свои подходы, я пока не видел такую умную брутилку.
Рилтайм работает, только конечно не так, что в момент атаки включили, статистика должна копиться заранее. Это уже из категории средств предотвращения атак.
получается при следующем обращении, если бот съел куку, .htaccess его пропустит?
Все способы с кукой пропустят ботов, которые работают на движке реального браузера, например на фантоме. Такие боты обнаруживаются только сбором статистики и анализом аномального поведения.
Поделитесь?) При условии, что подбор идёт запросами ничем не отличающимися от реальных посетителей, а логины и профили на сайтах должны работать.
Неотличимы, да отличимы :)
Я уже кому-то один простой давал, можно в паблик выложить [удалено] , есть еще с limit_req'ом варианты и совмещенный, для придержания запросов всех-всех ботов.
А что никто nginx перед апачем не ставит? Есть целая куча способов избавиться от подобных атак nginx'ом и сразу для всех сайтов за ним.
Юзаю resellerclub.com где-то с 2006-го, принимают вебмани.
Что-то коммерческое там вообще лучше не держать, т.к. в итоге будет больше потерь, чем экономии!
Например, каких? Вот упадет или заблокируют сервер, ну и пускай, есть в других ДЦ, которые спокойно примут трафик, а тем временем смогу заказать новый.