- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Я сейчас делаю бакап mysql вот так
mysql-server stop;
rsync -av path-to-mysql path-to-backup
mysql-server start;
На сколько нужна первая и последняя строчки, будет ли работать без них? или это будет плохо?
На открытых файлах делать дамп, конечно же, не следует. Ничего хорошего из этого не выйдет.
Используйте mysqldump.
Если выделенный сервер - делать lvm-снапшоты, потом rsync.
На vps - mysqlhotcopy (если неприменно хочется решение, копирующее
каталоги с таблицами). Или mysqldump, как советовали выше.
для бэкапа используйте mysqldump
mysqldump конечно же, бэкапить сами файлы - дурной тон
mysqldump конечно же, бэкапить сами файлы - дурной тон
Почему?
Если таблицы большие и достаточно интенсивно используются - лочить их
надолго mysqldump'ом - еще более дурной тон.
Почему?
Когда понадобится срочно восстановить на другой архитектуре/системе, SQLсервере другой версии и т.п. можно получить очень неприятные грабли.
Если таблицы большие и достаточно интенсивно используются - лочить их
надолго mysqldump'ом - еще более дурной тон.
"долго" понятие растяжимое, но если снятие дампа измеряется часами тогда надо применять другие средства типа репликации и снятия дампа уже с копии.
myhand, так mysqlhotcopy тоже лочит.
Изначально товарищ собирался вообще весь мускул шатдаунить :)
Так что mysqldump по сравнению с этим — вершина технологического прогресса! )
Когда-то давным давно я тоже пытался копировать "живые" файлики, но если файл не лочится, а во время копирования mysql в него что-то записывает, с большой долей вероятности скопированный файл получится битый.
Ну и из дампа удобней восстанавливать.
Иногда нужно восстановить не всю таблицу, а просто пару удалённых записей.
Бекапим какую то базу:
mysqldump -u login -p pass _имя_базы_которую_бекапим_ | gzip > куда_сохранить.gz
Либо все базы:
mysqldump -u login -p pass --all-databases | gzip > куда_сохранить.gz
Ну и самое главное :) Зачем бекап, который непонятно как восстановить?
Восстановим:
mysql -u root -p _имя_базы_которую_хотим_восстановить_ < распакованный_файл_дампа.sql
[umka], я имел в виду, скорее, lvm-бекап. Там лочится все на мизерное время.
А для больших баз - mysqlhotcopy шустрее mysqldump, естественно. У Вас же
не вся база в памяти сидит. Можно, конечно, и репликацию поднять, что более
универсальный, но и более "тяжелый" вариант.
На тему "удобно" - есть же mysql bin-log. Он иногда полезен для восстановления
небольшого числа записей.
Когда понадобится срочно восстановить на другой архитектуре/системе, SQLсервере другой версии и т.п. можно получить очень неприятные грабли.
Ну, такого никто и не обещал, если бекапите каталог данных физически. Зато быстро.
myhand добавил 06.02.2010 в 01:28
mysqldump -u login -p pass _имя_базы_которую_бекапим_ | gzip > куда_сохранить.gz
А канал в gzip направляем специально?
Чтобы таблицы лочились подольше?
А канал в gzip направляем специально?
Чтобы таблицы лочились подольше?
Ну так уберите gzip