由于我的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客户端和服务器没有注意到.