我正在尝试从从属服务器或 MySQL 实例为 MySQL 数据库设置每日备份。我的数据库是 InnoDb 和 MyISAM 表的混合体。我已经在另一台机器上安装了AutoMySQLBackup 。我正在尝试在 AutoMySQLBackup 的帮助下从该机器上对 MySQL 数据库进行完整备份和每日增量备份。
问问题
1295 次
1 回答
-1
Mysql 完整备份：-
https://dev.mysql.com/doc/mysql-enterprise-backup/3.12/en/mysqlbackup.full.html
命令行或配置文件中的选项？
为清楚起见，本手册中的示例通常显示一些与 mysqlbackup 命令一起使用的命令行选项。为了方便和一致，您可以将那些对于大多数备份作业保持不变的选项包含在您提供给 mysqlbackup 的 MySQL 配置文件的 [mysqlbackup] 部分中。mysqlbackup 还会从 [mysqld] 部分中获取选项（如果它们存在）。将选项放入配置文件可以为您简化备份管理：例如，将端口信息放入配置文件中，您可以避免每次数据库实例切换到不同端口时都需要编辑备份脚本。有关使用配置文件的详细信息，请参阅第 14 章，配置文件和参数。
在单个目录或时间戳子目录中输出？
为方便起见， --with-timestamp 选项在备份目录下创建唯一命名的子目录来保存每个备份作业的输出。带有时间戳的子目录使建立保留期变得更加简单，从而可以轻松删除和归档已超过一定期限的备份数据。
如果您确实使用单个备份目录（即，如果您省略 --with-timestamp 选项），请为每个备份作业指定一个新的唯一目录名称，或指定 --force 选项以覆盖现有备份文件。
对于使用 --incremental-base 选项指定包含先前备份的目录的增量备份，为了使目录名称可预测，您可能更愿意不使用 --with-timestamp 选项并生成目录名称序列用你的备份脚本代替。
始终完全备份，还是完全备份加增量备份？
如果您的 InnoDB 数据量很小，或者如果您的数据库非常繁忙以至于备份之间的数据更改百分比很高，您可能希望每次都运行完整备份。但是，您通常可以通过运行定期完整备份然后在它们之间进行几次增量备份来节省时间和存储空间，如第 4.3.2 节“进行差异或增量备份”中所述。
是否使用压缩？
创建压缩备份可以为您节省大量存储空间并显着减少 I/O 使用。使用 LZ4 压缩方法（自 3.10 版开始引入），处理压缩的开销非常低。如果数据库备份从活动数据库文件所在的更快的磁盘系统移动到可能更慢的存储，压缩通常会显着降低整体备份时间。它也可以减少恢复时间。一般来说，我们建议大多数用户使用 LZ4 压缩而不是不压缩，因为基于 LZ4 的备份通常会在更短的时间内完成。但是，请在您的环境中测试 MySQL Enterprise Backup 以确定最有效的方法。
增量备份功能主要用于 InnoDB 表或只读或很少更新的非 InnoDB 表。对于非 InnoDB 文件，如果该文件自上次备份以来发生更改，则整个文件将包含在增量备份中。
您不能使用 --compress 选项执行增量备份。
增量备份检测 InnoDB 数据文件中页面级别的更改，而不是表行；备份每个已更改的页面。因此，节省的空间和时间与更改的 InnoDB 行或列的百分比并不完全成正比。
当删除 InnoDB 表并执行后续增量备份时，应用日志步骤会从完整备份目录中删除相应的 .ibd 文件。由于备份程序无法对非 InnoDB 文件的用途具有相同的洞察力，因此当在完整备份和后续增量备份之间删除非 InnoDB 文件时，应用日志步骤不会从完整备份目录。因此，恢复备份可能会导致已删除的文件重新出现。
仅使用重做日志创建增量备份
--incremental-with-redo-log-only 可能比 --incremental 选项提供一些用于创建增量备份的好处：
InnoDB 表的更改是根据 InnoDB 重做日志的内容确定的。由于重做日志文件具有您预先知道的固定大小，因此从它们读取更改所需的 I/O 比扫描 InnoDB 表空间文件以定位更改的页面所需的 I/O 更少，具体取决于数据库的大小，数量DML 活动的数量和重做日志文件的大小。
由于重做日志文件充当循环缓冲区，随着新 DML 操作的发生，旧更改的记录会被覆盖，因此您必须按照由日志文件大小和生成的重做数据量决定的可预测时间表进行新的增量备份为您的工作量。否则，redo log 可能无法回溯到足以记录自上次增量备份以来的所有更改，在这种情况下 mysqlbackup 将很快确定它无法继续并返回错误。您的备份脚本应该能够捕获该错误，然后使用 --incremental 选项执行增量备份。
例如：
要计算重做日志的大小，请发出命令 SHOW VARIABLES LIKE 'innodb_log_file%' 并根据输出，将 innodb_log_file_size 设置乘以 innodb_log_files_in_group 的值。要在物理级别计算重做日志大小，请查看 MySQL 实例的 datadir 目录并总结与模式 ib_logfile* 匹配的文件的大小。
InnoDB LSN 值对应于写入重做日志的字节数。要在某个时间点检查 LSN，请发出命令 SHOW ENGINE INNODB STATUS 并查看 LOG 标题下。在规划备份策略时，定期记录 LSN 值并从当前值中减去较早的值，以计算每小时、每天等生成的重做数据量。
在 MySQL 5.5 之前，通常的做法是保持重做日志相当小，以避免在 MySQL 服务器被杀死而不是正常关闭时长时间启动。使用 MySQL 5.5 和更高版本，崩溃恢复的性能显着提高，如优化 InnoDB 配置变量中所述，因此如果这有助于您的备份策略和数据库工作负载，您可以使您的重做日志文件更大。
这种类型的增量备份不像标准的 --incremental 选项那样容忍太低的 --start-lsn 值。例如，您不能进行完整备份，然后使用相同的 --start-lsn 值进行一系列 --incremental-with-redo-log-only 备份。确保将上一次备份的精确结束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：在目录'/incr-backup/thursday'中创建备份 mysqlbackup：start_lsn：2654255717 mysqlbackup：incremental_base_lsn：2666733462 mysqlbackup：end_lsn：2666736714z
101208 17:14:58 mysqlbackup：mysqlbackup完成OK！请注意，如果您的上一次备份是单个文件而不是目录备份，您仍然可以通过为 dir:directory_path 指定您在备份过程中使用 --backup-dir 选项提供的临时目录的位置来使用 --incremental-base完全备份。
作为指定 --incremental-base=dir:directory_path 的替代方法，您可以使用 --incremental-base=history:last_backup 告诉 mysqlbackup 从服务器上的 backup_history 表中记录的上次成功备份中查询 end_lsn 值（这要求上次备份是使用连接到服务器的 mysqlbackup 进行的）。
您还可以使用 --start-lsn 选项指定增量备份应该从哪里开始。您必须在备份结束时记录mysqlbackup报告的先前备份的LSN：
mysqlbackup: was able to parse the log up to 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：在目录'/incr-backup/2010-12-08_17-14-48'中创建备份 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 指定的文件夹下创建：
$ 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
于 2016-04-05T20:12:10.450 回答