Бэкап SQL Базы

[mikkey finn]

я в свое время впоролся в то, что кронтаб не знал, где лежит mysqldump.
Вроде я модифицировал сам скрипт бекапа. Посмотрите в скрипте, как программа дампа вызывается, потом через which/locate или как там у вас проверьте, есть ли путь до этой программы в путях кронтаба.

[kaN5300]

Почему многие пишут про перевод типа таблиц в myisam или innodb? Разрабы ведь не просто так определили какой тип должен быть у каких таблиц. Способы бекапа к сожалению сильно разнятся для myisam и для innodb. Есть такие, кто перевел все таблицы UTM5 в innodb или все в myisam?

[Makariy]

я в myisam перевел, не жалуюсь

[Pulse]

есть проблема с таблицами в myisam, которые используют платёжные системы. payments в частности настоятельно рекомендуют держать в innodb

[littlesavage]

я в myisam перевел, не жалуюсь

Потерял возможность выполнения транзакций, что для биллинга, в принципе, не допустимо.

При Innodb, mysqldump надо запускать с --single-transaction и не будет никаких проблем с блокировками и работой UTM'а во время бекапа.

А вот время восстановления - это да, проблема Периодическое архивирование таблиц списаний в архивный myisam частично ее решает. Но вариант со Slave'ом все равно лучше

[Makariy]

я в myisam перевел, не жалуюсь

Потерял возможность выполнения транзакций, что для биллинга, в принципе, не допустимо.

а что утм наконец то стал работать с транзакциями?
надо будет, верну обратно - не проблема, alter table bla-bla-bla

[kaN5300]

я в myisam перевел, не жалуюсь

Потерял возможность выполнения транзакций, что для биллинга, в принципе, не допустимо.

При Innodb, mysqldump надо запускать с --single-transaction и не будет никаких проблем с блокировками и работой UTM'а во время бекапа.

А вот время восстановления - это да, проблема Периодическое архивирование таблиц списаний в архивный myisam частично ее решает. Но вариант со Slave'ом все равно лучше

Недавно копался в манах мускулдампа, там пишут действительно про рулезность фичи --single-transaction. Но можно ли ее применять к комбинированной БД с т.з. типа таблиц? У нас mysqldump работает ночью с дефолтными параметрами-аргументами и при запущенном utm5_core. Проблем особых нет вот уже 5 лет. Просто сейчас база разростается с такой скоростью, что придется вводить репликацию и готовить отдельный сервер. Но даже если заработает реплика, всё равно надо будет периодически дампить БД на слейве. По этому интересует оптимальный набор ключей для mysqldump при дефолтной конфигурации таблиц (без изменения Myisam -> Innodb или наоборот).

[kaN5300]

Щас читаю доки по репликации, наткнулся на кластер, но как я понял он еще очень сырой. А так было бы интересно:

http://dev.mysql.com/doc/refman/5.0/en/ ... uster.html

UPD:

Вот еще пишут при использовании InnoDB:

Note
For the greatest possible durability and consistency in a replication setup using InnoDB with transactions, you should use innodb_flush_log_at_trx_commit=1 and sync_binlog=1 in the master my.cnf file.

Стоит ли добавлять эти параметры в my.cnf на мастере?

[alexus]

А для кого написан скрипт идущий в комплекте?
# /netup/utm5/bin/utm5_backup.sh

Запустил этот скрипт из cron.
Но скрипт не хочет читать переменные из /netup/utm5/utm5.cfg
Хотя ,если запустить его вручную, то всё работает на ура.
Права доступа правильные.
Подскажите в чём проблема.
Подозреваю что надо что-то в скрипте подправить.
Спасибо

[gil]

переменные окружения

[alexus]

переменные окружения

Я просто не знаю что надо в скрипте подправить, чтобы он смог их из того файла читать при запуске из крона.
Крайний вариант тупо прописать в файле нужные данные и всё. Но хотелось бы этот вариант оживить