написание perl-скрипта для создания инкрементной резервной копии mysql с помощью mysqldump

Метод инкрементного резервного копирования, который вы рассматривали, задокументирован MySQL здесь:

http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

По сути, вам нужно настроить свой экземпляр mysql для записи любых изменений в вашей базе данных в этот двоичный журнал. Это означает, что любые обновления, удаления, вставки и т. д. заносятся в двоичный журнал, но не операторы выбора (которые не изменяют базу данных, поэтому не заносятся в двоичный журнал).

Как только вы запустите свой экземпляр mysql с включенным двоичным ведением журнала, вы сделаете полную резервную копию и запишите положение мастера. Затем позже, чтобы сделать инкрементную резервную копию, вы хотите запустить mysqlbinlog из главной позиции, и результатом этого будут все изменения, внесенные в вашу базу данных с тех пор, как вы сделали полную резервную копию. В этот момент вам нужно будет снова принять к сведению основную позицию, чтобы вы знали точку, из которой вы хотите сделать следующую инкрементную резервную копию.

Понятно, что если вы затем снова и снова создаете несколько инкрементных резервных копий, вам необходимо сохранить все эти инкрементные резервные копии. Я бы рекомендовал делать полную резервную копию довольно часто.

Действительно, я бы рекомендовал всегда делать полную резервную копию, если это возможно. Создание добавочных резервных копий просто причинит вам боль, IMO, но если вам нужно это сделать, это, безусловно, один из способов сделать это.

mysqldump - это билет.

Пример:

mysqldump -u [user_name] -p[password] --database [database_name] >/tmp/databasename.sql

-u = имя пользователя базы данных mysql

-p = пароль базы данных mysql

Примечание: после параметра -p пробела нет. И если вам нужно сделать это в perl, вы можете использовать системную функцию, чтобы вызвать ее следующим образом:

system("mysqldump -u [user_name] -p[password] --database [database_name] >/tmp/databasename.sql") or die "system call failed: $?";

Однако помните о рисках безопасности, связанных с этим. Если бы кто-то сделал список текущих процессов, запущенных в системе во время ее работы, он смог бы увидеть учетные данные, которые использовались для доступа к базе данных.