"How would you compress your MySQL Backup (http://www.mysqlperformanceblog.com/2008/06/05/how-would-you.../)" - выбор оптимального способа сжатия бэкапов СУБД с минимальной нагрузкой на CPU. Наиболее оптимальный вариант сжатия в плане скорости работы и минимизации нагрузки на сервер - LZO (http://www.lzop.org/).URL: http://www.mysqlperformanceblog.com/2008/06/05/how-would-you.../
Новость: http://www.opennet.me/opennews/art.shtml?num=16482
Спасибо, капитан Очевидность. ^^)
Кстати говоря, если спросить у гугля и именно про рекордно быстрое сжатие с непозорной степенью - окажется что есть (не менее открытые) LZ-based алгоритмы быстрее LZO и даже порой лучше сжимающие.С другой стороны, lzop - нормальная такая замена gzip с похожим на него интерфейсом и со скоростью сжатия на минимальных уровнях сравнимой с производительностью дисковой подсистемы (так что в итоге если через него пропустить порой даже быстрее получится чем просто запись на диск - за счет того что на диск меньше данных записывать).
оптимальным способом сжатия бекапов будет задание правильных приоритетов
через nice / ionice, и максимальный уровень компрессии, bzip2 -9 mysql-dump.sql
>оптимальным способом сжатия бекапов будет задание правильных приоритетов
>через nice / ionice, и максимальный уровень компрессии, bzip2 -9 mysql-dump.sqlИз ит Ъ?
После того, как дам сжат, его надо передать куда-то, причём чем дальше, тем лучше. Скорее всего, это будет передача поверх ssl, значит проблема с CPU снова встанет. Поэтому, лучше всего сжимать gzip-ом с опцией --rsyncable и затем использовать rsync/zsync для передачи.