- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
оно только для MyISAM, которое вполне переживет и простое копирование файлов.
Был ее порт под InnoDB, но там, вроде, патчилась и сама СУБД, что в Вашем случае, полагаю, не подойдет.
Pavel.Odintsov добавил 17.03.2010 в 21:14
Господа, чего вы бредите?
Фактически с точки зрения сохранности данных LVM снапшот аналогичен ребуту серверу по питанию. Для ext3 это штатная ситуация. Ровно как и для Innodb.
У myisam побъются индексы открытых таблиц. Что неприятно, но во многом помогает опция myisam-recover.
Только Вы упускаете одно но - у нас нету доступа к клиентскому DomU для каких-либо настроек MySQL демона / ручного восстановления таблиц.
Для клиента же это (MySQL crashed table после наката бэкапа) будет выглядеть как "хостер мне все сломал после восстановления из бэкапа".
Да и насчет InnoDB я бы не был так уверен, Percona не на пустом месте делала свои патчи для mysqlhotcopy для InnoDB: http://www.percona.com/docs/wiki/percona-xtrabackup:start
Pavel.Odintsov, не на пустом. но существование этой программы ведь не значит, что бекап innodb снапшотом может привести к аварии. логика где?
Учитывая что XEN - это сервер, то клиент должен сам обеспечить себе бекап изнутри или заплатить кому-то за это
Pavel.Odintsov, не на пустом. но существование этой программы ведь не значит, что бекап innodb снапшотом может привести к аварии. логика где?
Значит это или не значит не имеет значения.
Есть понятие "журналируемая файловая система" - innodb как раз оно и есть. И значит это всего лишь то, что нет потерянных файлов, кластеров и тому подобного, то есть что операции по изменению либо выполнились полностью, либо полностью не выполнились. Но это не значит, что не будет повреждения данных. В идеальном случае - да, не будет, если, например, абсолютно вся логика находится между begin transaction .. commit. Действительно, в этом случае можно ребутить и снапшотить в любой момент - будет потеряна одна транзакция.
А если у нас работа состоит из цепочки транзакций? Тогда первая, скажем, попадёт в бэкап, а вторая нет. С точки зрения базы всё хорошо, с точки зрения приложения всё плохо. Решается это сложными алгоритмами распределённых транзакций, но решается далеко не всегда.
А в большинстве случаев вообще ставится autocommit после каждой операции. Например, перемещение темы форума из одной категории в другую делается так:
1) удалить тему из категории 1
2) поместить тему в категорию 2
Если до 2-го пункта сделать снапшот, тема будет потеряна. Пример даже не надуманный, кстати.
Pilat, букв не жалко? я то все понимаю и возражаю не вам.
Если смотреть на ситуацию с точки зрения хостера, то ему нужно сделать хоть какой-нибудь бекап. Если он не ломает innodb и это уже хорошо.
Те, кто знает про транзакции и пишут правильный код - сами разберутся с бекапом.
netwind, ну всё равно надо понимать что делается и какие могут быть проблемы. Мне вот сейчас предстоит как раз эта задача - vmware машины бэкапить, вот я и волнуюсь...