- чего-то я Вас не понял :( Во первых ведение бинлогов вещь не декларируемая хостером и их наличие у хостера - это большой вопрос (растут они, при интенсивном использовании базы, дико и не факт что хостер их ведет). Во вторых - не понял куда из бинарного лога денется инфа? т. е. если лог есть, он содержит данные (как правило от момента последнего "нормального" бэкапа).
- кто может отличить VPS от "облачного хостинга"? 😂 Уже неоднократно в этой теме высказывалась мысль, что большинство компаний предлагающих "облачный хостинг", фактически предлагают VPS с удобной панелью по изменению квот на этот VPS (диск/память/ЦПУ) и, иногда, с живой миграцией между физическими серверами. Такие "облачные хостинги" всегда имеют лимит по ЦПУ/памяти, не превышающий возможности используемого железа (т. е. не мощнее чем дедик заказанный у той же компании). Т. е. фактически в большинстве случаях речь идет о маркетинговом ходе (раньше клиента ловили на безлимит, теперь раздувают "облака"). По настоящему "облачный хостинг", на данный момент, требует от клиента написания приложений под специальный API, предлагаемый хостером, позволяющий работать с кластеризованными ресурсами (БД/сервер приложений).
- если он есть ;)
+ 1, кроме бэкапирования часто хостеры используют опцию бинарного логирования (в MySQL). По binlog-у элементарно все восстанавливается.
- неизвестно как хостер делает бэкап (если на живой БД, то легко представить что в бэкап попадет "битая" таблица). Можно обойтись и без дампа - тупо взять папку с базой (если речь о MySQL) скопировать на локальный комп. в локальную MySQL, запустить "починку" таблицы, а затем снять дамп на локальной базе. Но думаю что хостер ничего не даст, а вся переписка про "битую таблицу" - это отмазка при полном отсутствии бэкапа.
Цитаты с указанного сайта:
- все это уже обсудили в данной ветке: виртуалки с живой миграцией, которые никак не могут получить больше ресурсов (ЦПУ, память) чем есть у сервера на котором они размещены, а учитывая что ресурсы железа лимитированы, особенный интерес вызывает фраза:
- видимо мощность площадки scalaxy выше мощности "всех датацентров компании Яндекс" ;) верить или не верить? Слишком мало технических деталей, чтобы можно было что-то уверенно утверждать (во всяком случае Xen больше чем есть ресурсов у одной ноды, не даст)
Brim.ru добавил 15.06.2010 в 11:34
- либо сайты должны ориентироваться на спец. API хостера (тогда требования к ПО идут лесом), либо максимально необходимое (для 1-2 "легких" сайтов + 10 "тяжелых") количество ресурсов (ЦПУ, память) не должно превышать возможности самого мощного VPS у хостера (а его возможности лимитируются возможностями железа на котором этот VPS живет, т. е. в типичном случае лимиты: 8 ядер и 24Гб ОП), т. е. строго говоря в этом случае масштабируемость "облака" имеет границы.
- учить клиентов - это не та работа которой должен заниматься хостер, работа хостера раелизовывать пожелания клиента. Возможно для Вас, как для консультанта, приемлемо давать клиенту советы и рекомендации, а в нашем случае мы даем советы только по просьбе со стороны клиента (говорить вебмастеру что его г..сайт еле работает из-за того что он не знает программирования и не умеет работать с БД, просто не этично, да и коммерческой выгоды от таких разговоров для нас не предвидится, разве что получим раздраженного клиента). Короче - если клиенту нужны террабайты дисков и гигабайты памяти, нам нужно думать о том как это сделать, а не о том для чего это нужно клиенту ;)
- кстати если заплатить кодеру, можно получить сайт работающий с Google API и "немерянными" ресурсами гугловского облака, но жизнь показывает что владельцы сайтов не особенно стремятся воспользоваться облачным хостингом с эксклюзивным API.
- вот Вы можете сформулировать что Вам нужно от хостинга кроме модного слова "облако"? диск? память? ЦПУ? uptime? трафик? требования к ПО? поддержка?
- кому "не нужно"? есть клиент, у него есть БД, в которой таблица размером 50Гб, для ускорения операций с которой клиент желает пихнуть ее в ОП и готов за это заплатить. Клиент не имеет желания менять структуру таблиц в своей базе и вообще менять приложение, он хочет решить проблему путем покупки большего количества ресурсов. Вы ему говорите - "не нужно держать всю базу на одном узле, так как есть шардинг". Внимание вопрос: какие дальнейшие действия клиента?
- можно, но тогда не ясно в чем смысл Вашего замечания про шардинг (излишне лаконичный стиль общения ухудшает понимание сказанного)
- готовы сравнивать шардинг и базу висящую в ОП по быстродействию? ;)
- всегда найдется клиент пожелания которого превосходят имеющиеся возможности самого мощного сервера у хостера (который к тому же уже может быть занят другим клиентом также нуждающемся в большом количестве ресурсов). То о чем Вы пишите - это не "облако", о обычный кластер использующий расшаренное дисковое хранилище на котором запущены виртуалки (мигрировать между узлами кластера без перезапуска виртуалки умеют уже сто лет и никто это облаком не называл).
