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