mysql性能的检查和调优方法

作者：Lightning@小宝发布时间：November 6, 2009 分类：MySQL备份&优化&架构

mysql性能的检查和调优方法来源:sudone.com

我一直是使用mysql这个数据库软件，它工作比较稳定，效率也很高。在遇到严重性能问题时，一般都有这么几种可能：

1、索引没有建好；
2、sql写法过于复杂；
3、配置错误；
4、机器实在负荷不了；

1、索引没有建好

如果看到mysql消耗的cpu很大，可以用mysql的client工具来检查。

在linux下执行

/usr/local/mysql/bin/mysql -hlocalhost -uroot -p

输入密码，如果没有密码，则不用-p参数就可以进到客户端界面中。

看看当前的运行情况

show full processlist

可以多运行几次

这个命令可以看到当前正在执行的sql语句，它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息

在我的cache后端，这里面大部分时间是看不到显示任何sql语句的，我认为这样才算比较正常。如果看到有很多sql语句，那么这台mysql就一定会有性能问题

如果出现了性能问题，则可以进行分析：

1、是不是有sql语句卡住了？

这是出现比较多的情况，如果数据库是采用myisam，那么有可能有一个写入的线程会把数据表给锁定了，如果这条语句不结束，则其它语句也无法运行。

查看processlist里的time这一项，看看有没有执行时间很长的语句，要留意这些语句。

2、大量相同的sql语句正在执行

如果出现这种情况，则有可能是该sql语句执行的效率低下，同样要留意这些语句。

然后把你所怀疑的语句统统集合一下，用desc（explain）来检查这些语句。

首先看看一个正常的desc输出：

mysql> desc select * from imgs where imgid=1651768337;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | imgs  | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)

注意key、rows和Extra这三项，这条语句返回的结果说明了该sql会使用PRIMARY主键索引来查询，结果集数量为1条，Extra没有显示，证明没有用到排序或其他操作。由此结果可以推断，mysql会从索引中查询imgid=1651768337这条记录，然后再到真实表中取出所有字段，是很简单的操作。

key是指明当前sql会使用的索引，mysql执行一条简单语句时只能使用到一条索引，注意这个限制；rows是返回的结果集大小，结果集就是使用该索引进行一次搜索的所有匹配结果；Extra一般会显示查询和排序的方式，。

如果没有使用到key，或者rows很大而用到了filesort排序，一般都会影响到效率，例如：

mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows  | Extra                       |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
|  1 | SIMPLE      | imgs  | ALL  | NULL          | NULL | NULL    | NULL | 12506 | Using where; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
1 row in set (0.00 sec)

这条sql结果集会有12506条，用到了filesort，所以执行起来会非常消耗效率的。这时mysql执行时会把整个表扫描一遍，一条一条去找到匹配userid="7mini"的记录，然后还要对这些记录的clicks进行一次排序，效率可想而知。真实执行时如果发现还比较快的话，那是因为服务器内存还足够将12506条比较短小的记录全部读入内存，所以还比较快，但是并发多起来或者表大起来的话，效率问题就严重了。

这时我把userid加入索引：

create index userid on imgs (userid);

然后再检查：

mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
|  1 | SIMPLE      | imgs  | ref  | userid        | userid | 51      | const |    8 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

嗯，这时可以看到mysql使用了userid这个索引搜索了，用userid索引一次搜索后，结果集有8条。然后虽然使用了filesort一条一条排序，但是因为结果集只有区区8条，效率问题得以缓解。

但是，如果我用别的userid查询，结果又会有所不同：

mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
|  1 | SIMPLE      | imgs  | ref  | userid        | userid | 51      | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

这个结果和userid="7mini"的结果基本相同，但是mysql用userid索引一次搜索后结果集的大小达到2944条，这2944条记录都会加入内存进行filesort，效率比起7mini那次来说就差很多了。这时可以有两种办法可以解决，第一种办法是再加一个索引和判断条件，因为我只需要根据点击量取最大的10条数据，所以有很多数据我根本不需要加进来排序，比如点击量小于10的，这些数据可能占了很大部分。

我对clicks加一个索引，然后加入一个where条件再查询：

create index clicks on imgs(clicks);

mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
|  1 | SIMPLE      | imgs  | ref  | userid,clicks | userid | 51      | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

这时可以看到possible_keys变成了userid,clicks，possible_keys是可以匹配的所有索引，mysql会从possible_keys中自己判断并取用其中一个索引来执行语句，值得注意的是，mysql取用的这个索引未必是最优化的。这次查询mysql还是使用userid这个索引来查询的，并没有按照我的意愿，所以结果还是没有什么变化。改一下sql加上use index强制mysql使用clicks索引：

mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>10 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key    | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
|  1 | SIMPLE      | imgs  | range | clicks        | clicks | 4       | NULL | 5455 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

这时mysql用到了clicks索引进行查询，但是结果集比userid还要大！看来还要再进行限制：

mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>1000 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key    | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
|  1 | SIMPLE      | imgs  | range | clicks        | clicks | 4       | NULL |  312 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)

加到1000的时候结果集变成了312条，排序效率应该是可以接受。

不过，采用换索引这种优化方式需要取一个采样点，比如这个例子中的1000这个数字，这样，对userid的每个数值，都要去找一个采样点，这样对程序来说是很难办的。如果按1000取样的话，那么userid='7mini'这个例子中，取到的结果将不会是8条，而是2条，给用户造成了困惑。

当然还有另一种办法，加入双索引：

create index userid_clicks on imgs (userid, clicks)

mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys        | key           | key_len | ref   | rows | Extra       |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
|  1 | SIMPLE      | imgs  | ref  | userid,userid_clicks | userid_clicks | 51      | const | 2944 | Using where |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
1 row in set (0.00 sec)

这时可以看到，结果集还是2944条，但是Extra中的filesort不见了。这时mysql使用userid_clicks这个索引去查询，这不但能快速查询到userid="admin"的所有记录，并且结果是根据clicks排好序的！所以不用再把这个结果集读入内存一条一条排序了，效率上会高很多。

但是用多字段索引这种方式有个问题，如果查询的sql种类很多的话，就得好好规划一下了，否则索引会建得非常多，不但会影响到数据insert和update的效率，而且数据表也容易损坏。

以上是对索引优化的办法，因为原因可能会比较复杂，所以写得比较的长，一般好好优化了索引之后，mysql的效率会提升n个档次，从而也不需要考虑增加机器来解决问题了。

但是，mysql甚至所有数据库，可能都不好解决limit的问题。在mysql中，limit 0,10只要索引合适，是没有问题的，但是limit 100000,10就会很慢了，因为mysql会扫描排好序的结果，然后找到100000这个点，取出10条返回。要找到100000这个点，就要扫描100000条记录，这个循环是比较耗时的。不知道会不会有什么好的算法可以优化这个扫描引擎，我冥思苦想也想不出有什么好办法。对于limit，目前直至比较久远的将来，我想只能通过业务、程序和数据表的规划来优化，我想到的这些优化办法也都还没有一个是万全之策，往后再讨论。

2、sql写法过于复杂

sql写法假如用到一些特殊的功能，比如groupby、或者多表联合查询的话，mysql用到什么方式来查询也可以用desc来分析，我这边用复杂sql的情况还不算多，所以不常分析，暂时就没有好的建议。

3、配置错误

配置里主要参数是key_buffer、sort_buffer_size/myisam_sort_buffer_size，这两个参数意思是：

key_buffer=128M：全部表的索引都会尽可能放在这块内存区域内，索引比较大的话就开稍大点都可以，我一般设为128M，有个好的建议是把很少用到并且比较大的表想办法移到别的地方去，这样可以显著减少mysql的内存占用。
sort_buffer_size=1M：单个线程使用的用于排序的内存，查询结果集都会放进这内存里，如果比较小，mysql会多放几次，所以稍微开大一点就可以了，重要是优化好索引和查询语句，让他们不要生成太大的结果集。

另外一些配置：
thread_concurrency=8：这个配置标配=cpu数量x2
interactive_timeout=30
wait_timeout=30：这两个配置使用10-30秒就可以了，这样会尽快地释放内存资源，注意：一直在使用的连接是不会断掉的，这个配置只是断掉了长时间不动的连接。
query_cache：这个功能不要使用，现在很多人看到cache这几个字母就像看到了宝贝，这是不唯物主义的。mysql的query_cache在每次表数据有变化的时候都会重新清理连至该表的所有缓存，如果更新比较频繁，query_cache不但帮不上忙，而且还会对效率影响很大。这个参数只适合只读型的数据库，如果非要用，也只能用query_cache_type=2自行用SQL_CACHE指定一些sql进行缓存。
max_connections：默认为100，一般情况下是足够用的，但是一般要开大一点，开到400-600就可以了，能超过600的话一般就有效率问题，得另找对策，光靠增加这个数字不是办法。

其它配置可以按默认就可以了，个人觉得问题还不是那么的大，提醒一下：1、配置虽然很重要，但是在绝大部分情况下都不是效率问题的罪魁祸首。2、mysql是一个数据库，对于数据库最重要考究的不应是效率，而是稳定性和数据准确性。

4、机器实在负荷不了

如果做了以上调整，服务器还是不能承受，那就只能通过架构级调整来优化了。

1、mysql同步。

通过mysql同步功能将数据同步到数台从数据库，由主数据库写入，从数据库提供读取。

我个人不是那么乐意使用mysql同步，因为这个办法会增加程序的复杂性，并常常会引起数据方面的错误。在高负荷的服务中，死机了还可以快速重启，但数据错误的话要恢复就比较麻烦。

2、加入缓存

加入缓存之后，就可以解决并发的问题，效果很明显。如果是实时系统，可以考虑用刷新缓存方式使缓存保持最新。

在前端加入squid的架构比较提倡使用，在命中率比较高的应用中，基本上可以解决问题。

如果是在程序逻辑层里面进行缓存，会增加很多复杂性，问题会比较多而且难解决，不建议在这一层面进行调整。

3、程序架构调整，支持同时连接多个数据库

如果web加入缓存后问题还是比较严重，只能通过程序架构调整，把应用拆散，用多台的机器同时提供服务。

如果拆散的话，对业务是有少许影响，如果业务当中有部分功能必须使用所有的数据，可以用一个完整库+n个分散库这样的架构，每次修改都在完整库和分散库各操作一次，或定期整理完整库。

当然，还有一种最笨的，把数据库整个完完整整的做拷贝，然后程序每次都把完整的sql在这些库执行一遍，访问时轮询访问，我认为这样要比mysql同步的方式安全。

4、使用 mysql proxy 代理

mysql proxy 可以通过代理把数据库中的各个表分散到数台服务器，但是它的问题是没有能解决热门表的问题，如果热门内容散在多个表中，用这个办法是比较轻松就能解决问题。

我没有用过这个软件也没有认真查过，不过我对它的功能有一点点怀疑，就是它怎么实现多个表之间的联合查询？如果能实现，那么效率如何呢？

5、使用memcachedb

数据库换用支持mysql的memcachedb，是可以一试的想法，从memcachedb的实现方式和层面来看对数据没有什么影响，不会对用户有什么困扰。

为我现在因为数据库方面问题不多，没有试验过这个玩意。不过，只要它支持mysql的大部分主要的语法，而且本身稳定，可用性是无需置疑的

MySql的一些性能监控方法

作者：Lightning@小宝发布时间：October 30, 2009 分类：MySQL备份&优化&架构

一，获取mysql用户下的进程总数

ps -ef | awk '{print $1}' | grep "mysql" | grep -v "grep" | wc-1

二，主机性能状态

# uptime
[root@ ~]# uptime
13:05:52 up 53 days, 52 min, 1 user, load average: 0.00, 0.00, 0.00
三，CPU使用率

# top
或
# vmstat

四，磁盘IO量

# vmstat 或 # iostat
五，swap进出量[内存]

# free
六，数据库性能状态
(1)QPS(每秒Query量)
QPS = Questions(or Queries) / seconds
mysql > show /*50000 global */ status like 'Question';

(2)TPS(每秒事务量)
TPS = (Com_commit + Com_rollback) / seconds
mysql > show status like 'Com_commit';
mysql > show status like 'Com_rollback';

(3)key Buffer 命中率
key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%
key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%

mysql> show status like 'Key%';

(4)InnoDB Buffer命中率
innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads / innodb_buffer_pool_read_requests) * 100%

mysql> show status like 'innodb_buffer_pool_read%';

(5)Query Cache命中率
Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;

mysql> show status like 'Qcache%';
(6)Table Cache状态量
mysql> show status like 'open%';

(7)Thread Cache 命中率
Thread_cache_hits = (1 - Threads_created / connections ) * 100%

mysql> show status like 'Thread%';

mysql> show status like 'Connections';

(8)锁定状态
mysql> show status like '%lock%';

(9)复制延时量
mysql > show slave status

(10) Tmp Table 状况(临时表状况)
mysql > show status like 'Create_tmp%';
(11) Binlog Cache 使用状况
mysql > show status like 'Binlog_cache%';

(12) Innodb_log_waits 量
mysql > show status like 'innodb_log_waits';

开源监控软件
一，RRDTool
二，Nagios
三，MRTG
四，Cacti

MySQL复制(Replication)优化

作者：Lightning@小宝发布时间：September 25, 2009 分类：MySQL备份&优化&架构

最近发现master数据库和slave数据延时相差20分钟,赶紧登录slave看看服务器是不是繁忙,这时正好是早上8点多,数据应该不大,为什么导致这个问题呢?于是google到一篇有价值的文章(作者也是转载,我就不注明出处了)

Replication延时的类型
1.固定性的延时
Slave的数据持续性的落后于Master并且一直无法与Master的数据保持一致。
Slave的数据经常在白天落后于Master，而在晚上可以赶上并与Master的记录保持一致。
这种类型的延时通常是由于Slave服务器的负载已经到达了上限或在白天访问量大的时候到达上限造成的。

2. 非固定性的延时
Slave的数据只是短暂的落后于Master，可在短时间内恢复
这类型的延时通常与批量任务和报表有关，效率差的查询也会导致这类延时

Mysql Replication的限制

Mysql的Replication是单线程的，意味着只能有效的使用一个CPU内核和一个磁盘，一条复杂的查询或者事务都导致进程被阻塞，不过现在针对5.1版本的多线程Replication补丁，http://forge.mysql.com/wiki/ReplicationFeatures/ParallelSlave，还是pre版，有很多限制，感兴趣的可以去看看。

Replication的容量

1. 理解什么是Replication的容量
可以将Replication暂停一个小时，重新启动Replication后，观察Slave的数据多久可以与Master一致。从Replication重新启动到和Master数据一致所花费的时间与Replication暂停的时间的比值就是Replication的容量。

2. 建议保持Replication的容量在3倍以上，即延迟一个小时的数据，Slave只需要20分钟就能与Master的数据一致。

Replication的优化

1. 5.0的mysql中避免类似以下的更新语句
INSERT … SELECT
UPDATE …. WHERE (对于insert一条数据,然后又多次update的情况,个人建议,采用临时表(不是mysql的tmp table),可能一条数据在多次业务逻辑操作后,总会处于平静状态,这时候可以把它移动到另外的表做查询.)
复杂的查询会导致Replication线程阻塞。如果是insert或update与select结合的语句，可以讲select单独执行并保存在临时表中，然后再执行insert或者update。
如果使用的是5.1的mysql，新功能中的行级Replication（RBR）可以解决这个问题。RBR可以将在Master上通过复杂查询后更新的结果直接传给Slave，Slave可以直接将结果更新到数据库中。

2. 避免大的事务
太大的事务会造成Replication长时间阻塞，数据会严重滞后于Master。

Slave服务器的硬件选择

更快的CPU内核，对于单线程的Replication多核CPU是没有任何优势的。
更高速的硬盘，包括更高的转速和更好的高速缓存命中率，如果有钱的话上SSD吧

主从结构的扩展性问题

1.如何降低写操作的频率
Master的写操作会扩散到所有的Slave上，所以高频率的写操作会降低Slave的读操作效率。
至少保持一台Slave做全库同步，其他的Slave可以只做部分表的同步。当然，这需要web应用程序的配合来分配哪些查询读哪些Slave。(这一点很值得研究,这叫*分而治之*,有时候我们根本不需要全部去同步所有数据,按业务,和需求来同步,一方面减小的数据量,延迟明显就会下降,遇到复杂的sql语句,可以单独处理)

将一些更新操作放到memcached中，例如session和计数器。
Slave使用myisam引擎
将一些写入量很大的更新操作直接在slave上执行，而不通过Replication。(淘宝好像就是这样干的,把sql语句生成文件,然后拿到slave上执行)

2. 如何更有效的利用Slave的硬件资源
使用分区
有选择的对表进行同步
在Slave上对数据进行归档。
Session的持久化
为不同的应用服务器分配不同的Slave进行读操作。
或者根据查询类型的不同来分配不同的Slave。

3. 如何使你的程序最大化的利用Slave
将对数据更新不敏感的查询放到Slave上，而需要实时数据的查询则放到Master。
通过session的持久化，让做了修改的用户首先看到修改的内容，其他的用户可以等待Slave更新后再查看新内容。
对于某些数据，可以用memcached来存放数据的版本号，读Slave的程序可以先对比Slave的数据和memcached数据的版本，如果不一致则去读master。用户和博客类的信息可以用这种方法。
在查询前可以通过SHOW SLAVE STATUS检测Slave的状态，然后根据返回的结果进行服务器的选择。

MySQL慢查询日志分析之mysqlsla&mysqldumpslow

作者：Lightning@小宝发布时间：September 9, 2009 分类：MySQL备份&优化&架构

作者：老王
MySQL优化不是一劳永逸的工作，而是一个持久战。其中慢查询日志的分析是一个重要手段，以前我总是手动大概看看，不过这实在不是长久之计，今天试用了一下mysqldumpslow和mysqlsla，感觉效率高多了。
mysqldumpslow
mysqldumpslow是官方提供的perl脚本，所以你也不用费劲巴拉的安装了，只要有mysql的环境基本就能用：
/path/to/mysqldumpslow -s c
其中参数（-s c）的意思就是按照各种慢查询条数排序。不过mysqldumpslow有一个挺不爽的缺点，就是查询的结果只有一些抽象的SQL，没有可供实际运行的SQL例子。
mysqlsla
mysqlsla是第三方提供的perl脚本，不过它功能更强悍，可以分析包括慢查询在内的多种格式的日志，同时没有上面所说的mysqldumpslow的缺点。
tar zxf http://hackmysql.com/scripts/mysqlsla-2.03.tar.gz
cd mysqlsla-2.03
perl Makefile.PL
make
make install
使用起来很简单：
/path/to/mysqlsla slow.log
mysqlsla会自动判断日志类型，缺省会打印出前十条结果，可以通过类似“--top 100”的参数来修改，如果觉得每次输入麻烦，还可以建立一个配置文件“~/.mysqlsla”，在文件里写上：top=100，这样就不用每次都手动输入参数了。
还有很多其他的工具，不过我感觉只要会用这两个就足够了，mysqldumpslow相对通用，mysqlsla相对强大，剩下其他的杂七杂八的工具不看也罢。
慢查询分析是个长期工作，即便系统长时间没有引入新的SQL查询，也可能由于不断更新数据使得数据分布特征发生变化，从而导致索引失效，进而产生慢查询。所以说平时要多留神，有了上面介绍的利器，工作会清闲很多。

MySQL同步故障：" Slave_SQL_Running:No"

作者：Lightning@小宝发布时间：September 7, 2009 分类：MySQL备份&优化&架构

MySQL同步故障：" Slave_SQL_Running:No"
今天检查数据库发现一台MySQL Slave未和主机同步，查看Slave状态：
mysql> show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1062
....
Seconds_Behind_Master:NULL
MYSQL5中有 skip-error这个选项来掉过一些复制时产生的错误。
原因：
1.程序可能在slave上进行了写操作
2.也可能是slave机器重起后，事务回滚造成的.
解决办法I：
1.首先停掉Slave服务：slave stop
到主服务器上查看主机状态：
记录File和Position对应的值。
mysql> show master status;
+------------------+-----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000020 | 135617781 | | |
+------------------+-----------+--------------+------------------+
1 row in set (0.00 sec)
3.到slave服务器上执行手动同步：
mysql> change master to
> master_host='master_ip',
> master_user='user',
> master_password='pwd',
> master_port=3307,
> master_log_file='mysql-bin.000020',
> master_log_pos=135617781;
1 row in set (0.00 sec)
mysql> slave start;
1 row in set (0.00 sec)
再次查看slave状态发现：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...
Seconds_Behind_Master: 0
解决办法II：
mysql> slave stop;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> slave start;
由方法2写出的shell

#! /bin/bash

USRR="root"
PASSWD="password"

while true;
do
        while [`mysql -u${USER} -p${PASSWD} -e "show slave status"| head -n2 | tail -1 | awk '{print $11}'` == 'No']
        do
                mysql -u${USER} root -p${PASSWD} -e "SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;stop slave;start slave;";
                echo "continue...";
                sleep 1;
        done;
        sleep 60;
done;

偶是用方法2，刚刚的完成任务！

页码:
1
2
3
4
5
»

技术起点