企业备份MySQL 4.1发行说明
本节描述的性能考虑备份数据库和MySQL企业备份。当优化和调优备份过程,测量的原始性能(需要多长时间备份完成)和在数据库服务器上的开销。当测量备份性能,考虑:
所强加的限制备份程序。举个例子,如果你每8小时进行备份,备份必须少于8小时来完成。
所强加的限制你的网络和存储基础设施。举个例子,如果你需要适应许多备份在一个特定的存储设备,您可以使用压缩备份,即使做了备份过程较慢。
备份和恢复时间之间的权衡。你可以选择一组选项导致稍微慢备份,如果这些选项启用恢复要快得多。看到11.2节,“优化恢复性能”为恢复过程性能信息。
完整或增量备份
在完整的备份之后,可以执行后续备份更快通过增量备份,只改变了数据备份。增量备份,指定——增量或——incremental-with-redo-log-only选项mysqlbackup。看到16.7节,“增量备份选项”对这些选项的信息。为使用指令备份和增量备份的应用阶段,明白了4.3.3节”,使得微分或增量备份”。
压缩备份
压缩备份数据传输到另一台服务器需要额外的CPU开销之前在数据库服务器上的备份,但减少网络流量和磁盘I / O服务器上的备份数据的最终目的地。考虑您的数据库服务器上的负载,您的网络的带宽,和数据库的相对能力和目标服务器在决定是否使用压缩。看到4.3.4节”,使得压缩备份”和16.6节,“压缩选项”创建信息压缩备份。
压缩涉及备份性能和还原性能之间的权衡。在紧急情况下,解压之前备份数据恢复所需的时间可能是不可接受的。也有可能是存储问题如果没有足够的空闲空间在数据库服务器上进行压缩备份和未压缩的数据。因此,至关重要的数据越多,越有可能,你可能会选择不使用压缩:接受较慢,更大的备份,以确保恢复过程尽可能快速和可靠。
单文件备份
单个文件备份本身并不一定比传统的备份类型生成一个输出文件的目录树。其性能优势来自结合不同,你可能需要执行的步骤序列,如结合备份数据到一个单独的输出文件并将它转移到另一个服务器。看到15.5节,“其他单文件备份操作”选择相关的单个文件备份,和4.3.1节”,使得单个备份”使用指令。
InnoDB配置选项设置
稍后讨论,有很多原因你可能倾向于运行设置innodb_file_per_table = 1。
并行备份
mysqlbackup可以利用现代多核cpu和操作系统的线程并行执行备份操作。看到16.10节,“性能/可伸缩性/容量选项”选项来控制有多少线程用于备份过程的不同方面。如果你发现有未使用的系统容量在备份过程中,考虑增加这些选项的值和测试是否这样做增加备份性能:
当调优和测试备份性能使用RAID存储配置,考虑选项的组合设置
——read-threads = 3——流程线程= 6——帖子= 3。比较相结合——read-threads = 1——流程线程= 6帖子= 1。当调优和测试使用raid存储备份性能配置,考虑选项的组合设置
——read-threads = 1——流程线程= 6帖子= 1。当你增加任何3的值”线程”选项,也增加的价值
——limit-memory足够的内存选项,给额外的线程来做他们的工作。如果CPU不是太忙(CPU利用率不到80%),增加的价值
——流程线程选择。如果你备份的存储设备(源驱动)可以处理更多的I / O请求,增加的价值
——read-threads选择。如果你备份存储设备(目标驱动)可以处理更多的I / O请求,增加的价值
——帖子的选择。
根据您的操作系统,您可以使用命令,如测量资源利用率前,iostat,特别行政区,dtrace或图形性能监视器。不增加读或写线程的数量iowait一旦系统iowait值达到大约20%。
MyISAM注意事项
重要的
虽然mysqlbackup备份数据库而不中断InnoDB表使用,最后阶段,non-InnoDB文件(如MyISAM表和副本
.frm文件)暂时把数据库为只读状态,使用的声明刷新表读锁。最佳备份对数据库处理性能和最小的影响:不跑长
选择查询或其他SQL语句的时候备份运行。保持你的MyISAM表相对较小,主要为只读或读为主的工作。
然后锁定阶段的末尾mysqlbackup运行很短(可能几秒钟),并且不打扰的正常处理mysqld多。如果上述条件不满足在数据库应用程序中,使用
——only-innodb或——only-innodb-with-frm选择备份只InnoDB表,或者使用——无固定选择备份non-InnoDB文件。注意,MyISAM,.frm和其它文件复制下——无固定设置不能保证是一致的,如果他们是更新在这最后阶段的备份。对于一个大型数据库,备份运行可能需要很长时间。总是检查mysqlbackup已经成功完成,通过验证吗mysqlbackup退出代码返回0,或通过观察mysqlbackup已经打印的文本”mysqlbackup完成好的!”。
计划备份期间当没有涉及表的DDL操作正在运行。看到附录B,企业备份MySQL的局限性为限制备份的同时DDL操作。
网络性能
对于数据处理操作,您可能知道传统的建议,Unix socket通信速度比TCP / IP数据库。虽然mysqlbackup命令支持选项——= tcp协议,——协议=套接字,——协议=管,这些选项没有显著影响备份或恢复性能。这些过程涉及文件复制操作,而不是客户机/服务器网络流量。数据库通信控制的——协议选择是容量。例如,mysqlbackup检索数据库的信息通过数据库连接参数,但不表或索引数据。
数据大小
如果特定的表或数据库包含非关键信息,或很少更新,你可以把他们从你的最频繁的备份和备份它们不那么频繁的时间表。看到16.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二级索引,它浪费空间定义主键由无数或冗长的列,或多个二级索引与不同排列相同的列。
高级:运用原木阶段(仅用于目录备份)
如果你备份数据存储在一个单独的机器,这台机器并不是机器一样忙碌托管数据库服务器,你可以卸载一些(后处理工作运用原木阶段),不同的机器上。运用原木操作
总有一个性能权衡后立即做运用原木阶段初始备份(使恢复更快),或推迟,直到恢复之前(使备份更快)。在紧急情况下,恢复性能是最重要的考虑。因此,至关重要的数据越多,更重要的是运用原木阶段后立即备份运行。要么把备份和运用原木阶段被指定在同一台服务器上backup-and-apply-log选项,或执行快速初始备份,备份数据转移到另一个服务器,然后执行运用原木阶段使用的选项之一运用原木操作。