- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева

Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Это вы предлагаете бинлог для бэкапов приспособить.
Я предлагаю?
Еще раз цитирую официальную документацию из mysql: These binary logs are the incremental backup
Если вы по-английски не можете читать: "Эти бинарные логи и есть инкрементальный бекап".
Но я расскажу, так и быть. Бэкап - не репликация.
Зачем мне ваша банальщина? :) Я этим уже много лет занимаюсь.
Он нужен для ситуаций, когда какие-то данные потерлись, например был послан запрос, который удалил полностью какую-то отдельную часть данных, например таблицу, если это sql база данных, этот же запрос успешно выполниится на вашем маломощном сервере-реплике и вы останитесь без таблицы на обоих серверах.
Вы ничего не поняли.
Маломощный сервер-реплика никаких запросов не выполняет. Удалить он ничего не может.
Все что он делает - копирует к себе бинлог в реальном времени.
То есть по определению из документации выше, это инкрементальный бекап данных в реальном времени.
http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html
Remote Binlog Back-up
Enhances operational efficiency by using the replication channel to create real-time back-ups from the binary log.
By adding a raw flag, the binlog is written out to remote back-up servers, without having a MySQL database instance translating it into SQL statements
А то что mysql полон всякой неадекватчины - это мы в курсе, на их решения нужно смотреть
О ну так просветите нас, как в правильных базах это делают? :)
Только, пожалуйста, ссылку на ресурс, а не словоблудие.
Маломощный сервер-реплика никаких запросов не выполняет. Удалить он ничего не может.
Все что он делает - копирует к себе бинлог в реальном времени.
Это не SQL запросы, а события апдейтов, он их все выполняет. И если пришло событие удалить таблицу - он ее удалит. Он не копирует к себе бинлог, а именно применяет. Можете проверить. Как это вы так много лет занимаетесь и не понимаете, как mysql работает?
И там все правильно написано real-time back-up - это и есть копия базы в текущий момент, а не в любой момент времени, т.е. откатиться на день никак нельзя.
Это не SQL запросы, а события апдейтов, он их все выполняет. И если пришло событие удалить таблицу - он ее удалит. Он не копирует к себе бинлог, а именно применяет. Можете проверить.
Стандартный mysql replication server так и делает - все выполняет.
Но, как я уже писал, в 5.6 добавили новую фичу - копирование логов в реальном времени, без выполнения. Ссылки я уже дал. И пишу это уже в 3-й раз.
Как это вы так много лет занимаетесь и не понимаете, как mysql работает?
А сколько лет назад вас учили в школе чтению, и почему вы до сих пор читать не научились?
И там все правильно написано real-time back-up - это и есть копия базы в текущий момент, а не в любой момент времени, т.е. откатиться на день никак нельзя.
А вот и можно :)
Теперь там есть опция - репликация с задержкой.
Можно поставить задержку на час.
И если кто-то случайно дропнул таблицу, этот дроп можно выкусить из бинлогов. И в репликацию это событие не попадет.
Да, и real-time backup - это не копия базы на текущий момент. Это именно инкрементальный бекап, где можно выбрать время на которое откатиться, убрать какое-то событие и т.п.
Так что там с правильными базами? Ссылку-то дадите?
Как в течении 90 дней делать инкрементальный бекап, который быстро восстанавливается?
Mutabors, hetzner не панацея.
Хранилище будет надежнее и быстрее, чем этот древний сервер с полумертвыми винтами.
А вот если бы у хедзнера, была бы такая же реф программа, как и у того сервиса, который Вы рекламируете, аргументы изменились бы?
А если реф. программа Хедзнера была еще более выгодна? :-)
Отсутствие возможности заработать на Хедзнере как посредник, меня тоже напрягает, но это самый большой их недостаток. Технически же, провайдер отличный. Сижу там с нагруженными комерческими проектами уже больше года, потому и советую его...