小编Ben*_*enM的帖子

当用户密码更改时，用户计划任务将失败，除非您更改与该任务关联的密码。这对我来说是一个问题，因为我有一个小脚本，每天在其他人的服务器上由计划任务运行。

他们制定了一项政策，每个月都需要更改用户密码。这会导致计划任务出现问题，因为它无法运行。这个问题有什么好的解决方案不需要每个月左右手动干预吗？

我想编写一个 shell 脚本（目前使用 bash）来自动备份远程服务器上几个 MySQL 模式的内容。远程服务器被锁定为只允许 SSH 访问，所以我必须在mysqldump针对各种模式运行之前创建一个 SSH 隧道。

我可以毫无问题地创建隧道，但是我希望能够在数据库转储完成后自动关闭它。

目前我的脚本正在这样做：

/usr/bin/ssh -T -f -L 4444:127.0.0.1:3306 -l remoteuser 208.77.188.166 sleep 600

/usr/bin/mysqldump --compress -h 127.0.0.1 -P 4444 -u user -ppassword db1 | gzip > /root/backups/snapshot/db1.sql.gz

/usr/bin/mysqldump --compress -h 127.0.0.1 -P 4444 -u user -ppassword db2 | gzip > /root/backups/snapshot/db2.sql.gz

/usr/bin/mysqldump --compress -h 127.0.0.1 -P 4444 -u user -ppassword db3 | gzip > /root/backups/snapshot/db3.sql.gz

在连接保持打开 600 秒的情况下，显然，如果第一个转储之一花费的时间比这更长，那么在其他转储完成之前连接将关闭。我想为每个模式备份保留单独的文件（因此--databases现在将避免使用mysqldump）。

有什么建议？

我们的一台服务器最近遇到了一些文件系统损坏，我们的根文件系统自动重新挂载为只读。我采取的恢复步骤是：

1. 尝试remount > mount -n -o remount /失败
2. 重新启动了服务器
3. 提示执行手动操作fsck，有 5 个孤立的 inode 需要修复。

执行这些步骤后，我能够获得访问权限并且文件系统再次可写。不幸的是，我没有任何内容丰富的日志，因为没有写过，否则我会包含这些日志。

建议的一个原因是我们的数据库太忙而无法将数据正确写入磁盘，这导致了问题，高级别缓存内存表明可能是这种情况。但是我不确定这一点，因为虽然缓存很高，但我们根本没有使用交换（free下面的输出）。

$ free -m
             total       used       free     shared    buffers     cached
Mem:          2041       1879        162          0         62       1599
-/+ buffers/cache:        216       1825
Swap:          471          0        471

故障发生后有什么方法可以诊断故障吗？MySQL 看起来像一个可能的候选者吗？

如果没有，如果再次发生这种情况，我将来应该采取什么措施？