Comments 13
Это ж какой обьем можно так бекапить? 10К?
а если база innodb? а если размеры базы в 20-30 гигабайт и интенсивное использование? как быть в этом случае?
Бэкаплю раз в час базу из 70-и таблиц… база пока весит 400 метров и растёт… таблицы myisam.
Такой бэкап юзаю уже у недели — репо в сжатом виде весит 30 метров.
в случае InnoDB и настолько больших баз данный вид бэкапа наверное не прокатит — там лучше снэпшотами. думаю для таких ситуций тоже рассмотреть возможности инкрементального бэкапа.
Такой бэкап юзаю уже у недели — репо в сжатом виде весит 30 метров.
в случае InnoDB и настолько больших баз данный вид бэкапа наверное не прокатит — там лучше снэпшотами. думаю для таких ситуций тоже рассмотреть возможности инкрементального бэкапа.
гм, а чем обусловлена необходимость частого бекапа? если желанием манимизировать потери — то может бинарные логи лучше подойдут? (http://dev.mysql.com/doc/refman/5.0/en/binary-log.html)
Ну и –skip-extended-insert — увеличит время восстановления базы из дампа на порядок.
Ну и –skip-extended-insert — увеличит время восстановления базы из дампа на порядок.
если не использовать –skip-extended-insert то при расширеном инсерте куча записей набивается в одну строку текстового файла. Допустим в строку при таком инсерте будет писаться 50 записей… хоть одна из них изменится — всю эту строку гит перезапишет… Щас у меня дифы весят 10 — 50М, без опции –skip-extended-insert они весили по 180 — 200М
Месье знает толк в извращениях.
Имхо если нужно минимизировать размер дампа, советую использовать 7zip (7za — *nix) для упаковки дампа. Вот сравнение размеров упакованного дампа (в байтах):
Sql — 1,246,423,306 (~ 1.2 GiB)
GZip — 164,229,483 (~ 160 MiB)
7Zip — 80,686,333 (~ 78 MiB)
Имхо если нужно минимизировать размер дампа, советую использовать 7zip (7za — *nix) для упаковки дампа. Вот сравнение размеров упакованного дампа (в байтах):
Sql — 1,246,423,306 (~ 1.2 GiB)
GZip — 164,229,483 (~ 160 MiB)
7Zip — 80,686,333 (~ 78 MiB)
Помойму git хранит не дифы а сами файлы и делает из них дифы только в случае необходимости.
Поэтому использовать git для тих целей не очень кошерно — сам об этом задумылваося раньше.
+ старые коммиты удалять геморойно. (Посмотрел бы на размер репозитория через 10 лет)
Поэтому использовать git для тих целей не очень кошерно — сам об этом задумылваося раньше.
+ старые коммиты удалять геморойно. (Посмотрел бы на размер репозитория через 10 лет)
он хранит не файлы, а объекты и их изменения… да, я иногда меня юепозиторий на свежий у больших баз, но оч уж удобно за нужное время бэкапа изъимать базу, или её кусок… месяц бэкапов в гит гиговой базы занимает гиг после убирания мусора ночного…
Хе, а вы таки правы
После сжатия базы он использует дельты для хранения данных.
Из приведенной ссылки следует что вам стоит поиграть с глубиной упаковки (параметр --depth), и это может ощутимо сказаться на размере базы.
После сжатия базы он использует дельты для хранения данных.
Из приведенной ссылки следует что вам стоит поиграть с глубиной упаковки (параметр --depth), и это может ощутимо сказаться на размере базы.
Sign up to leave a comment.
Резервное копирование mysql-базы. мой путь =)