我正在尝试从从属服务器或MySQL实例设置MySQL数据库的每日备份。我的数据库是InnoDb和MyISAM表的混合体。我在另一台机器上安装了AutoMySQLBackup。我试图在AutoMySQLBackup的帮助下从该机器上获取完整备份和MySQL数据库的每日增量备份。
答案 0 :(得分：-1)
Mysql完全备份： -
https://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/mysqlbackup.full.html
命令行或配置文件中的选项？
为清楚起见，本手册中的示例经常显示一些 与mysqlbackup命令一起使用的命令行选项。对于 方便性和一致性，您可以包括剩余的选项 大多数备份作业都没有改变到[mysqlbackup]部分 您提供给mysqlbackup的MySQL配置文件。 mysqlbackup 如果是的话，也可以从[mysqld]部分中选择 在那里。将选项放入配置文件中即可 为您简化备份管理：例如，放置端口 将信息转换为配置文件，可以避免编辑 每次数据库实例切换到a时都会备份脚本 不同的港口。请参见第14章，配置文件和参数 有关配置文件使用的详细信息。
单目录或带时间戳的子目录中的输出？
为方便起见， - with-timestamp选项创建唯一命名 备份目录下的子目录，用于保存每个子目录的输出 备份工作。带时间戳的子目录使其更简单 建立保留期，便于删除和存档 已超过一定年龄的备份数据。
如果你确实使用了一个备份目录（也就是说，如果你省略了 --with-timestamp选项），为每个备份作业指定一个新的唯一目录名，或指定--force选项以覆盖 现有的备份文件。
对于使用--incremental-base选项的增量备份 指定包含先前备份的目录，以便进行 目录名称可预测，您可能更愿意不使用 --with-timestamp选项，并使用备份脚本生成一系列目录名称。
始终完全备份，还是完全备份还是增量备份？
如果您的InnoDB数据量很小，或者您的数据库太忙了 您可能需要备份之间的大部分数据更改 每次运行完整备份。但是，您通常可以节省时间和 通过运行定期完整备份然后运行几个存储空间 它们之间的增量备份，如第4.3.2节所述， “进行差异备份或增量备份”。
是否使用压缩？
创建压缩备份可以为您节省大量存储空间 并显着降低I / O使用率。并采用LZ4压缩 方法（从3.10版开始引入），处理的开销 压缩率很低。在数据库备份正在移动的情况下 从更快的磁盘系统，其中活动数据库文件坐在一个 可能更慢的存储，压缩往往会显着降低 整个备份时间。它可以减少恢复时间 好。一般来说，我们建议LZ4压缩而不压缩 大多数用户，因为基于LZ4的备份通常在较短的时间内完成 期。但是，测试你的MySQL企业备份 环境，以确定什么是最有效的方法。
增量备份功能主要用于InnoDB表，或非只读或很少更新的非InnoDB表。对于非InnoDB文件，如果该文件自上次备份以来发生了更改，则整个文件都包含在增量备份中。
您无法使用--compress选项执行增量备份。
增量备份检测InnoDB数据文件中页面级别的更改，而不是表格行;已备份的每个页面都已备份。因此，节省的空间和时间与改变的InnoDB行或列的百分比不完全成比例。
当删除InnoDB表并执行后续增量备份时，apply-log步骤会从完整备份目录中删除相应的.ibd文件。由于备份程序无法对非InnoDB文件的目的有同样的了解，因此在完全备份和后续增量备份之间删除非InnoDB文件时，apply-log步骤不会从中删除该文件完整的备份目录。因此，恢复备份可能会导致删除的文件重新出现。
仅使用重做日志创建增量备份
--incremental-with-redo-log-only可能会带来一些好处 - 用于创建增量备份的增量选项：
对InnoDB表的更改是根据内容确定的 InnoDB重做日志。由于重做日志文件具有固定的大小 你事先知道，它可以需要更少的I / O来读取更改 他们比扫描InnoDB表空间文件找到更改的 页面，取决于数据库的大小，DML活动的数量， 和重做日志文件的大小。
由于重做日志文件充当循环缓冲区，其记录为 当你进行新的DML操作时，旧的更改会被覆盖 必须按照可预测的时间表采取新的增量备份 通过日志文件的大小和为其生成的重做数据量 你的工作量。否则，重做日志可能无法恢复到足够远的程度 记录自上次增量备份以来的所有更改 哪种情况下mysqlbackup会很快确定它无法继续 并将返回错误。您的备份脚本应该能够捕获 该错误然后执行增量备份 - 改为选择。
例如：
要计算重做日志的大小，请发出命令SHOW VARIABLES LIKE＆＃39; innodb_log_file％＆＃39;并且，基于输出，乘以 innodb_log_file_size设置的值为 innodb_log_files_in_group。计算重做日志大小 物理级别，查看MySQL实例的datadir目录 并总结匹配模式ib_logfile *。
的文件的大小InnoDB LSN值对应于写入的字节数 重做日志。要在某个时间点检查LSN，请发出命令 SHOW ENGINE INNODB状态并查看LOG标题下的内容。而 规划备份策略，定期记录LSN值 从当前值中减去先前的值来计算多少 每小时，每天等都会生成重做数据。
在MySQL 5.5之前，通常的做法是保留重做日志 相当小，以避免MySQL服务器时的长启动时间 杀死而不是正常关闭。使用MySQL 5.5及更高版本 如上所述，崩溃恢复的性能得到显着改善 在优化InnoDB配置变量，以便您可以 您的重做日志文件更大，如果这有助于您的备份策略和您的 数据库工作量。
这种类型的增量备份不是太低了 --start-lsn值作为标准 - 增量选项。例如，您无法进行完整备份然后进行一系列备份 - 使用相同的--start-lsn值，仅使用重做日志备份。确保将上一个备份的精确结束LSN指定为下一个增量备份的起始LSN;做 不使用任意值。
注意确保LSN值在连续之间准确匹配 增量备份，建议您始终使用 - 使用--incremental-with-redo-log-only选项时的--incremental-base选项。
判断此类增量备份是否切实可行 对特定的MySQL实例有效：
测量InnoDB重做日志文件中数据更改的速度。 定期检查LSN以确定重做数据累积的数量 在几个小时或几天的过程中。
比较重做日志累积的速率和重做的大小 日志文件。使用此比率可以查看增量的频率 备份，以避免备份失败的可能性，因为 历史数据在重做日志中不可用。例如，如果 您每天生成1GB的重做日志数据和组合大小 您的重做日志文件是7GB，您可以安排增量备份 比一周一次更频繁。您可以执行增量 每天或每两天备份，以避免突然发生的潜在问题 一连串的更新产生了比平时更多的重做。
使用--incremental和 - 的基准增量备份时间 --incremental-with-redo-log-only选项，用于确认重做日志备份技术是否执行速度更快，开销更低 传统的增量备份方法。结果可能取决于 您的数据大小，DML活动的数量以及您的数据大小 重做日志文件。在具有真实数据的服务器上进行测试 数量和实际工作量。例如，如果你有巨大的重做 日志文件，在增量备份过程中读取它们可以 只要使用传统的方式读取InnoDB数据文件即可 增量技术。相反，如果您的数据量很大， 读取所有数据文件以查找少数已更改的页面可能会更少 比处理更小的重做日志文件更有效。
增量备份的其他注意事项
增量备份功能主要用于InnoDB 表或非InnoDB表，它们是只读的或很少更新的。 增量备份检测InnoDB中页面级别的更改 数据文件，而不是表行;每个已更改的页面都是 备份。因此，节省的空间和时间并不完全 与改变的InnoDB行或列的百分比成比例。
对于非InnoDB文件，整个文件包含在增量中 备份，如果该文件自上次备份以来已更改，这意味着 比较时，备份资源的节省不太重要 与InnoDB表的情况。
您无法使用--compress选项执行增量备份。
进行基于备份的增量备份时（完整或 使用--no-locking选项创建的增量），使用 --skip-binlog选项跳过二进制日志的备份，因为二进制日志信息对mysqlbackup不可用 情况。
增量备份示例
此示例使用mysqlbackup对MySQL服务器进行增量备份，包括所有数据库和表。我们展示了两种选择，一种使用--incremental-base选项，另一种使用--start-lsn选项。
使用--incremental-base选项，您不必跟踪一个备份和下一个备份之间的LSN值。相反，您可以只指定先前备份的目录（完整备份或增量备份），并且mysqlbackup根据前一备份的元数据确定此备份的起点。因为您需要一组已知的目录名，所以您可能希望在自己的备份脚本中使用硬编码名称或生成一系列名称，而不是使用--with-timestamp选项。
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--incremental-base=dir:/incr-backup/wednesday \
--incremental-backup-dir=/incr-backup/thursday \
backup
......多行输出...... mysqlbackup：在目录＆＃39; / incr-backup / thursday＆＃39;中创建的备份 mysqlbackup：start_lsn：2654255717 mysqlbackup：incremental_base_lsn：2666733462 mysqlbackup：end_lsn：2666736714z
101208 17:14:58 mysqlbackup：mysqlbackup完成OK！ 请注意，如果您的上一次备份是单个文件而不是目录备份，您仍然可以使用--incremental-base通过指定dir：directory_path在您提供的--backup-dir选项期间提供的临时目录的位置完全备份。
作为指定--incremental-base = dir：directory_path的替代方法，您可以告诉mysqlbackup使用--incremental-base = history查询服务器上backup_history表中记录的上次成功备份的end_lsn值： last_backup（这要求最后一次备份是在mysqlbackup连接到服务器的情况下完成的。）
您还可以使用--start-lsn选项指定增量备份应从何处开始。您必须在备份结束时记录mysqlbackup报告的先前备份的LSN：
mysqlbackup：能够将日志解析为lsn 2654255716 该数字还记录在备份期间由--backup-dir指定的文件夹中的meta / backup_variables.txt文件中。然后使用--start-lsn选项将该数字提供给mysqlbackup。然后，增量备份包括指定LSN之后的所有更改。从那以后，之前备份的位置不是很重要，您可以使用--with-timestamp自动创建命名子目录。
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--start-lsn=2654255716 \
--with-timestamp \
--incremental-backup-dir=/incr-backup \
backup
......多行输出...... mysqlbackup：在目录＆＃39; / incr-backup / 2010-12-08_17-14-48＆＃39;中创建的备份 mysqlbackup：start_lsn：2654255717 mysqlbackup：incremental_base_lsn：2666733462 mysqlbackup：end_lsn：2666736714
101208 17:14:58 mysqlbackup：mysqlbackup完成OK！ 要创建增量备份映像，请使用以下命令，使用--incremental-backup-dir指定用于存储备份元数据的临时目录和一些临时文件：
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--start-lsn=2654255716 \
--with-timestamp \
--incremental-backup-dir=/incr-tmp \
--backup-image=/incr-backup/incremental_image.bi
backup-to-image
在下面的示例中，因为--backup-image不提供要创建的映像文件的完整路径，所以在--incremental-backup-dir指定的文件夹下创建增量备份映像： p>
$ mysqlbackup --defaults-file=/home/pekka/.my.cnf --incremental \
--start-lsn=2654255716 \
--with-timestamp \
--incremental-backup-dir=/incr-images \
--backup-image=incremental_image1.bi
backup-to-image
https://dev.mysql.com/doc/mysql-enterprise-backup/3.7/en/mysqlbackup.incremental.html