如何优化大型数据库的mysqldump？

我有一个带有InnoDB数据库的symfony应用程序,大约2GB,有57个表.数据库的大部分大小都驻留在一个表中(~1.2GB).我目前正在使用 mysqldump每晚备份数据库.

由于我的comcast连接,通常如果我手动运行转储,我与服务器的连接将在转储完成之前超时,导致我必须重新运行转储. [我目前运行的是每晚进行转储的cron,这仅适用于我手动运行的转储.]

有没有办法加快连接超时问题的转储,还限制服务器占用此进程的时间？

顺便说一句,我目前正在努力减少整个数据库的大小来解决这个问题.

解决方法

>确保您的输出转移到与存储数据库文件的驱动器不同的驱动器 – 这将使旋转磁盘产生巨大差异,因为驱动器磁头不会在读取的位置之间不断闪烁从和写入的位置.
> mysqldump的输出将是非常可压缩的,因此如果您不能将输出与输入分开,如上所述通过gzip或类似方法输出输出.这将减少写入的数量(因此减少整体IO负载和磁头移动量),但代价是一些CPU时间(在这些时候你可能会有很多空闲).此外,(同样或代替压缩)通过管道实用程序(如pv)传递输出,该实用程序支持大写缓冲区,以便将写入驱动器的块组合在一起,再次减少头部移动延迟的影响 – 这将使如果使用–quick选项来减少备份大表的RAM影响,则会有很大的不同.
>仅在IO负载较低时运行备份过程.

您可能正在修复错误的问题：可能更容易解决连接丢失问题(尽管减少备份所带来的I / O负载将有助于降低您对其他用户的影响,因此无论如何都值得尝试).你可以通过screen(或像tmux这样的类似工具)运行手动备份吗？这样,如果您与服务器的连接断开,您可以重新连接并重新连接到屏幕会话,而不会中断任何进程.

如果您通过连接直接发送数据(即您在本地计算机上针对远程数据库运行mysqldump,因此转储出现在本地),您可能最好先在服务器上运行转储,根据需要进行压缩,然后再转移使用支持部分传输的工具(例如rsync)通过网络传输数据,以便在连接丢弃中断传输时恢复传输(而不是重新启动).

作为“减少整个数据库的大小来解决此问题”的一部分,我猜你的大部分数据都不会改变.您可以将1.2Gb的大块从主表移动到另一个主表中,并将其从mysqldump调用复制的那些中删除.如果数据永不改变,则无需每次都备份这些数据.以这种方式在表和数据库之间拆分数据通常称为数据分区,还可以允许您在多个驱动器上分布数据和I / O负载.高端数据库已内置支持自动分区,但在mysql中,您可能必须手动执行此操作并更改数据访问层以解决此问题.

偏离该站点的偏离主题(因此您可能应该扼杀到ServerFault或SuperUser以询问您是否需要更多详细信息)：如果您似乎因为不活动而丢失连接,请检查SSH服务器和SSH客户端中的选项以进行确保保持活动包已启用并且经常发送.即使连接处于活动状态,如果看到丢弃,您也可以尝试使用OpenVPN或类似方法来封装连接 – 它应该处理一个短暂的丢弃,即使整个连接断开几秒钟也会完全丢弃,这样SSH客户端和服务器没有注意到.

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!