主库出现问题的几率比从库小的多！
我这里是只监测从库是否为2个Yes。如果不是就发邮件提醒（邮件部分是php开发人员给的url，直接访问就可以发送邮件）。
#!/bin/bash
mysql -uroot -pYOURPASSWORD -e "show slave status\G;" | grep -i Running | egrep "IO|SQL" | grep -i yes | wc -l > /tmp/cms
if [ "$(cat /tmp/cms)" = "2" ];
then
echo ok > /tmp/ok
else
links URL > /tmp/links
fi
exit
用任务计划，一分钟一执行！你要是发现更好办法分享下~~~
❷ 如何做一个mysql的sql脚本来测试数据还原
还原数据，一定要还原成自己之前的某个版本的数据，你随机生成的不可能是你想要的。
随便写的一个sql脚本都可以导入到数据库，最主要还是你自己备份出来的数据，导入数据库才正确呀。
如果是导入慢的话，你可以先清理掉数据库中的内容，然后再导入，就会省掉很多判断，会快很多。
❸ 如何通过shell脚本来检查或监控MYSQL数据库
db2 connect to [dbname] db2 "select min(a) from b;" > t.txtdb2 terminatedate=`cat t.txt | tail -2 | head -1` echo $date
❹ 怎么查看mysql数据库中的表是否损坏
可以使用语句检查表。如果结果的msg_text部分是好的，那么你的表是健康的。反之，则表明mysql数据库中的表有损坏。另外有些厉害的高手一额可以通过运行脚本来检测。
MyISAM表可以采用以下方法进行修复：使用reapair table或myisamchk来修复。如果修复无效，采用备份恢复表。
阶段1：检查你的表
如果你有很多时间，运行myisamchk *.MYI或myisamchk -e *.MYI。使用-s（沉默）选项禁止不必要的信息。如果mysqld服务器处于宕机状态，应使用--update-state选项来告诉myisamchk将表标记为'检查过的'。
你必须只修复那些myisamchk报告有错误的表。对这样的表，继续到阶段2。如果在检查时，你得到奇怪的错误(例如out of memory错误)，或如果myisamchk崩溃，到阶段3。
阶段2：简单安全的修复
注释：如果想更快地进行修复，当运行myisamchk时，你应将sort_buffer_size和Key_buffer_size变量的值设置为可用内存的大约25%。
首先，试试myisamchk -r -q tbl_name(-r -q意味着“快速恢复模式”)。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：
在继续前对数据文件进行备份。使用myisamchk -r tbl_name(-r意味着“恢复模式”)。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败，使用myisamchk --safe-recover tbl_name。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况(但是更慢)。如果在修复时，你得到奇怪的错误(例如out of memory错误)，或如果myisamchk崩溃，到阶段3。
阶段3：困难的修复
只有在索引文件的第一个16K块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：
把数据文件移到安全的地方。使用表描述文件创建新的(空)数据文件和索引文件：
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit
如果你的MySQL版本没有TRUNCATE TABLE，则使用DELETE FROM tbl_name。将老的数据文件拷贝到新创建的数据文件之中。回到阶段2。现在myisamchk -r -q应该工作了。你还可以使用REPAIR TABLE tbl_name USE_FRM，将自动执行整个程序。
阶段4：非常困难的修复
只有.frm描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3。你也可以恢复索引文件然后回到阶段2。对后者，你应该用myisamchk -r启动。
如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD数据文件独自留下来了。回到阶段2并且尝试重建索引文件。
❺ 如何检查mysql从数据库是否正常运行，脚本
一般在从库执行show slave status，看behind值是否为0来判断。
更准确的一些的方法是在主库做一个表，每秒insert一个时间戳，在从库读取，来看时间差是否超过1秒。