本节介绍使用MySQL Enterprise Backup备份数据库的性能考虑因素。在优化和调优备份过程时,测量原始性能(完成备份所需的时间)和数据库服务器上的开销量。在衡量备份性能时,需要考虑:
备份过程施加的限制。例如,如果每8小时备份一次,则备份时间必须小于8小时。
网络和存储基础设施施加的限制。例如,如果需要在特定存储设备上安装多个备份,则可能使用压缩备份,即使这会使备份过程变慢。
备份时间和恢复时间之间的权衡。您可以选择一组选项,如果这些选项使恢复速度更快,则可能导致备份速度稍慢。看到第10.2节,“优化恢复性能”查看恢复进程的性能信息。
全量备份或增量备份
在执行完全备份之后,可以通过执行增量备份更快地执行后续备份,增量备份只备份更改的数据。对于增量备份,请指定——增量
或——incremental-with-redo-log-only
选项mysqlbackup.看到第15.7节“增量备份选项”有关这些选项的信息。有关增量备份的备份和应用阶段的使用说明,请参见第4.3.3节,“进行差异或增量备份”.
压缩备份
在将备份数据传输到另一台服务器之前对备份数据进行压缩,会增加备份所在的数据库服务器的CPU开销,但会减少作为备份数据最终目的地的服务器上的网络流量和磁盘I/O。在决定是否使用压缩时,要考虑数据库服务器上的负载、网络带宽以及数据库和目标服务器的相对容量。看到第4.3.4节“进行压缩备份”而且第15.6节“压缩选项”有关创建压缩备份的信息。
压缩涉及备份性能和恢复性能之间的权衡。在紧急情况下,在恢复备份数据之前解压缩备份数据所需的时间可能无法接受。如果数据库服务器上没有足够的空闲空间来同时保存压缩备份和未压缩数据,也可能存在存储问题。因此,数据越重要,就越有可能选择不使用压缩:接受较慢、较大的备份,以确保恢复过程尽可能快、可靠。
单文件备份
单文件备份本身并不一定比生成输出文件目录树的传统类型的备份快。它的性能优势来自于组合不同的步骤,否则您可能必须按顺序执行,例如将备份数据组合成一个输出文件并将其传输到另一个服务器。看到第14.5节“其他单文件备份操作”对于与单文件备份相关的选项,和第4.3.1节“进行单文件备份”有关使用说明。
InnoDB Configuration Options设置
在MySQL 5.5之前,通常的做法是保持重做日志相当小,以避免当MySQL服务器被杀死而不是正常关闭时启动时间过长。在MySQL 5.5及以上版本中,性能为崩溃恢复显著改善,如在优化InnoDB配置变量.使用这些版本,如果可以帮助您的备份策略和数据库工作负载,您可以使重做日志文件更大。
正如后面所讨论的,您可能更喜欢使用该设置运行的原因有很多innodb_file_per_table = 1
.
并行备份
mysqlbackup可以利用现代多核cpu和操作系统线程来并行执行备份操作。看到第15.10节,“性能/可伸缩性/容量选项”用于控制备份进程的不同方面使用多少线程的选项。如果在备份期间发现有未使用的系统容量,请考虑增加这些选项的值,并测试这样做是否会提高备份性能:
在使用RAID存储配置调优和测试备份性能时,请考虑选项设置的组合
——read-threads=3——process-threads=6——write-threads=3
.与组合进行比较——read-threads=1——process-threads=6——write-threads=1
.在使用非raid存储配置调优和测试备份性能时,请考虑选项设置的组合
——read-threads=1——process-threads=6——write-threads=1
.当你增加这3个中的任意一个的值”线程”选项,也增加了价值
——limit-memory
选项,为额外的线程提供足够的内存来完成它们的工作。如果CPU不太忙(CPU利用率小于80%),则增加
——流程线程
选择。如果要从(源驱动器)进行备份的存储设备可以处理更多的I/O请求,则增加
——read-threads
选择。属性的值,如果要备份到(目标驱动器)的存储设备可以处理更多I/O请求
——帖子的
选择。
根据您的操作系统,您可以使用以下命令来测量资源利用率前,iostat,特别行政区,dtrace,或图形性能监视器。不增加读或写线程的数量iowait
一旦系统iowait
价值达到20%左右。
MyISAM注意事项
虽然mysqlbackup在不中断数据库使用的情况下备份InnoDB表,最后阶段复制非InnoDB文件(如MyISAM表和
.frm
Files)使用语句将数据库暂时置于只读状态用读锁刷新表
.为了获得最佳的备份性能和对数据库处理的影响最小:不要跑太久
选择
查询或其他SQL语句在备份运行时。保持MyISAM表相对较小,主要用于只读或以读为主的工作。
然后是a末端的锁相mysqlbackup运行时间短(可能只有几秒钟),并且不影响正常的处理mysqld多。如果您的数据库应用程序不满足上述条件,请使用
——only-innodb
或——only-innodb-with-frm
选项只备份InnoDB表,或者使用——无固定
选项备份非innodb文件。注意MyISAM,.frm
,以及复制在——无固定
如果在备份的最后阶段更新了设置,则不能保证它们是一致的。对于大型数据库,备份运行可能需要很长时间。一定要检查mysqlbackup已成功完成,或通过验证mysqlbackup返回退出代码0,或者通过观察mysqlbackup打印了文本”mysqlbackup完成OK!”.
在不运行涉及表的DDL操作期间安排备份。看到附录B,MySQL企业备份的局限性对DDL操作同时进行备份的限制。
网络性能
对于数据处理操作,您可能知道Unix套接字在与数据库通信时比TCP/IP更快的传统建议。虽然mysqlbackup命令支持的选项——= tcp协议
,——协议=套接字
,——协议=管
,这些选项对备份或恢复性能影响不大。这些过程涉及文件复制操作,而不是客户机/服务器网络流量。控件控制的数据库通信——协议
期权交易量低。例如,mysqlbackup通过数据库连接检索有关数据库参数的信息,但不检索表或索引数据。
数据大小
如果某些表或数据库包含非关键信息,或者很少更新,则可以将它们从最频繁的备份中删除,并以较低的频率进行备份。看到第15.8节“部分备份和恢复选项”有关相关选项的信息,以及第4.3.5节“部分备份”有关从特定表、数据库或存储引擎中删除数据的说明。部分备份速度更快,因为它们复制、压缩和传输的数据量更小。
使…的整体尺寸最小化InnoDB
数据文件,考虑启用MySQL配置选项innodb_file_per_table
.此选项可使数据大小最小化InnoDB
表格的几种方式:
它可以防止
InnoDB
系统表空间的膨胀,分配的磁盘空间以后只能被MySQL使用。例如,有时大量的数据只是暂时需要的,或者是由于错误或在实验过程中加载的。没有innodb_file_per_table
选项,系统表空间将扩展以容纳所有这些数据,并且在此之后永不收缩。进程所占用的磁盘空间立即被释放
InnoDB
删除或截断表时,表及其索引。每个表及其关联索引由.ibd文件被这些DDL操作删除或清空。它允许未使用的空间
.ibd
文件优化表
语句,当删除大量数据或删除索引时。它支持部分备份
InnoDB
表而不是其他表,如中所讨论的第4.3.5节“部分备份”.它允许对InnoDB表使用表压缩。
一般情况下,使用表压缩由ROW_FORMAT =压缩
减少表大小并提高备份和恢复性能。然而,作为一种权衡,表压缩可能会增加重做日志的大小,从而降低增量备份和恢复的速度运用原木
操作。看到如何压缩InnoDB表获取详细信息。
避免创建查询不使用的索引。由于索引会占用备份数据的空间,不必要的索引会降低备份速度。使用的复制和扫描机制mysqlbackup不要依赖索引来完成它们的工作。)例如,在表的每一列上创建索引通常没有帮助,因为每个查询只使用一个索引。因为每个主键列都包含在其中InnoDB
辅助索引,定义由大量或长列组成的主键或具有相同列的不同排列的多个辅助索引会浪费空间。
高级:应用-日志阶段(仅适用于目录备份)
如果将备份数据存储在单独的机器上,并且该机器不像托管数据库服务器的机器那么繁忙,则可以卸载一些后处理工作(例如运用原木Phase)到那个独立的机器。运用原木操作
在初始备份之后立即执行apply-log阶段(使恢复更快)或将其推迟到恢复之前执行(使备份更快)之间总是存在性能权衡。在紧急情况下,恢复性能是最重要的考虑因素。因此,数据越重要,在备份之后立即运行apply-log阶段就越重要。属性将备份和应用程序日志阶段组合在同一服务器上backup-and-apply-log
选项,或执行快速初始备份,将备份数据传输到另一台服务器,然后使用其中一个选项执行apply-log阶段运用原木操作.