Условия доставки ещё иногда непонятны. Например, однажды на сайте «доставляем всюду» я воспользовалась корзиной, после чего выяснилось, что в мой подмосковный город не доставляют. Пришлось искать другого продавца. А это минус день ожидания. Позвонила бы сразу — минус 10 минут максимум.
> Даже если Ваши сервера находятся в России, но адресат за ее пределами или сервер адресата использует подписку спамхауса для борьбы со спамом — то Ваше письмо просто не будет принято…
Я в курсе
> Потому можно долго ругаться и плевать на всех, а можно взять и играть по одним с другими странами правилам и бороться со спамом.
И каким образом я, клиент shared хостинга, могу бороться со спамом?
> Ну так предложите другое решение, или давайте узаконим анархию в интернете…
Ну вот я честный пользователь, но мне выгодно держать свой домен на shared хостинге. Почему для того, чтобы мои пиьма получили, я должна пользоваться gmail.com и прочими сервисами, которые мне лично не нужны? Или переезжать на более дорогое решение?
Проблема в том, что из-за одного спамера создают проблемы тысячам порядочных пользователей.
Вообще со Спамхаусом основная проблема — это то, что им ещё пользуются зарубежные провайдеры. Соответственно невозможно кому-то отослать письмо, если у тебя домен расположен на любом shared хостинге. Что с этим делать из России — непонятно.
Оооо, то есть если соль засыпал и ополаскиватель залил можно таблетку не класть? Или что-то нужно ещё? И, соответственно, наоборот: при пользовании таблеткой не обращать внимание на красные лампочки нехватки соли?
Сорри за дурацкий вопрос, у нас просто посудомойка с инструкцией на турецком и моё знание языка не позволяет прояснить этот вопрос самостоятельлно =)
> Для MySQL да, но для сервера в целом нет, так как не нужно форматировать весь дамп и сжимать его, поэтому в целом нагрузка уменьшится. Да и в принципе в любом блочном бэкапе проверяются все блоки (если конечно где-то не фиксируется время изменения).
В бинарном incremental backup этот процесс хотя бы на текущие запросы никак не влияет. Но у вас другая ниша, это понятно.
У меня ещё вопросик:
> Для каждого блока считается идентификатор (CRC32 + MD5 + Размер блока), по этому идентификатору определяется уникальность блока.
А как вы неуникальные строки идентифицируете. Например, есть такая таблица:
> Обязательно наличие прав доступа FILE у вашего MySQL пользователя и MySQL-сервер должен находиться на localhost. Если будет много желающих добавлю версию и с простыми селектами.
Это сразу уменьшает полезность вашей программы для пользователей хостинга. В принципе, если можно дать FILE, как правило можно и бинарные бэкапы делать.
> Работая над форматом SXB и блочной дедупликацией для файлов, появилась идея, что неплохо бы попробовать и дедупликацию для самой БД. Ведь в базе данных меняется не так много данных между бэкапами.
…
> Для каждого блока считается идентификатор (CRC32 + MD5 + Размер блока), по этому идентификатору определяется уникальность блока.
…
> Таким образом, если мы встречаем блок, который уже есть в нашем бэкапе (текущем или предыдущих), то мы используем ссылку на этот блок, и не добавляем сам повторяющийся блок в текущий бэкап. Благодаря чему экономим место для бэкапа, процессорное время (не нужно сжимать одни и те же данные), а также из-за меньших размеров значительно ускоряется загрузка бэкапа в облачные хранилища.
То есть для MySQL-сервера — это всё тот же полный бэкап? Это хорошо только для небольших объёмов.
> Учитывая, что бэкап обычно делается значительно чаще, чем восстановление. То естественно лучше перенести дополнительную нагрузку на процесс восстановления.
Справедливое замечание, но не стоит забывать, что восстановление иногда требуется для того, чтобы вернуть работоспособность приложения, а тут каждая секунда на счету. В то время как бэкап может запускаться в максимально ненагруженное время и работать как угодно долго.
> Инкрементальность просаживает надёжность. Если помрёт начальный бэкап, на который делались инкрементальные, то абсолютно все последующие потеряют смысл (в некоторых кейсах можно будет что-то восстановить, но в целом — так).
Инкрементальные бэкапы нужно правильно планировать. Когда я рассказываю про backup, я привожу в пример такую схему: full backup раз в неделю и incremental backup ежедневно. Это для не очень активных изменений, в общем-то. Другие специалисты могут предлагать какие-то другие общие схемы в вакууме, но вряд ли кто в своём уме предложит делать full backup-ы реже.
Почитайте ещё рекомендации для MySQL Enterprise Backup. Искать нужно whitepapers, соответствующие страницы в официальном мануале и в Team Blog (https://blogs.oracle.com/mysqlenterprisebackup/) есть ссылки на слайды с презентаций.
Хорошая фишка.
3) Рассылки что хочешь сменят
Я в курсе
> Потому можно долго ругаться и плевать на всех, а можно взять и играть по одним с другими странами правилам и бороться со спамом.
И каким образом я, клиент shared хостинга, могу бороться со спамом?
> Ну так предложите другое решение, или давайте узаконим анархию в интернете…
Хотя бы один IP банить, а не всю подсетку.
Проблема в том, что из-за одного спамера создают проблемы тысячам порядочных пользователей.
А где искать место, куда его засыпать?
Сорри за дурацкий вопрос, у нас просто посудомойка с инструкцией на турецком и моё знание языка не позволяет прояснить этот вопрос самостоятельлно =)
В бинарном incremental backup этот процесс хотя бы на текущие запросы никак не влияет. Но у вас другая ниша, это понятно.
У меня ещё вопросик:
> Для каждого блока считается идентификатор (CRC32 + MD5 + Размер блока), по этому идентификатору определяется уникальность блока.
А как вы неуникальные строки идентифицируете. Например, есть такая таблица:
Делаем бэкап.
Как вы последние две строчки от первых трёх отличаете?
> Обязательно наличие прав доступа FILE у вашего MySQL пользователя и MySQL-сервер должен находиться на localhost. Если будет много желающих добавлю версию и с простыми селектами.
Это сразу уменьшает полезность вашей программы для пользователей хостинга. В принципе, если можно дать FILE, как правило можно и бинарные бэкапы делать.
> Работая над форматом SXB и блочной дедупликацией для файлов, появилась идея, что неплохо бы попробовать и дедупликацию для самой БД. Ведь в базе данных меняется не так много данных между бэкапами.
…
> Для каждого блока считается идентификатор (CRC32 + MD5 + Размер блока), по этому идентификатору определяется уникальность блока.
…
> Таким образом, если мы встречаем блок, который уже есть в нашем бэкапе (текущем или предыдущих), то мы используем ссылку на этот блок, и не добавляем сам повторяющийся блок в текущий бэкап. Благодаря чему экономим место для бэкапа, процессорное время (не нужно сжимать одни и те же данные), а также из-за меньших размеров значительно ускоряется загрузка бэкапа в облачные хранилища.
То есть для MySQL-сервера — это всё тот же полный бэкап? Это хорошо только для небольших объёмов.
> Учитывая, что бэкап обычно делается значительно чаще, чем восстановление. То естественно лучше перенести дополнительную нагрузку на процесс восстановления.
Справедливое замечание, но не стоит забывать, что восстановление иногда требуется для того, чтобы вернуть работоспособность приложения, а тут каждая секунда на счету. В то время как бэкап может запускаться в максимально ненагруженное время и работать как угодно долго.
Бэкап бэкапов нужно делать всегда.
> Инкрементальность просаживает надёжность. Если помрёт начальный бэкап, на который делались инкрементальные, то абсолютно все последующие потеряют смысл (в некоторых кейсах можно будет что-то восстановить, но в целом — так).
Инкрементальные бэкапы нужно правильно планировать. Когда я рассказываю про backup, я привожу в пример такую схему: full backup раз в неделю и incremental backup ежедневно. Это для не очень активных изменений, в общем-то. Другие специалисты могут предлагать какие-то другие общие схемы в вакууме, но вряд ли кто в своём уме предложит делать full backup-ы реже.
Почитайте ещё рекомендации для MySQL Enterprise Backup. Искать нужно whitepapers, соответствующие страницы в официальном мануале и в Team Blog (https://blogs.oracle.com/mysqlenterprisebackup/) есть ссылки на слайды с презентаций.