对250G的大表新建索引,等了24小时没结束。注:innodb_buffer_pool_size大小为20G
按自己的理解,应该会生成一个略大于原表的临时表,替换原表。
在大表的同目录下只发现一个文件名以#开始的小文件,未见大文件。
[code]
-rw-rw---- 1 mysql mysql 8923 Nov 9 01:14 #sql-4220_ble924.sql
[/code]
/tmp下面也没见大文件,用du -sh查到的结果也只有20k。
用lsof -p查到一批文件,发现打开了/tmp下两个30G的文件,但标记为已删除
[code]
# lsof -p 16928
...
mysqld 16928 mysql txt REG 8,1 41662738 671857 /data/software/mysql-5.5.8/bin/mysqld
...
mysqld 16928 mysql 263u REG 8,1 30028070912 25591817 /tmp/ibZMaeaz (deleted)
mysqld 16928 mysql 268u REG 8,1 30028070912 25591818 /tmp/ibRE7pZq (deleted)
[/code]
用iostat -x 1查看,其所在磁盘的ioutil为100%,主要为r,少量w。
因为磁盘的空余空间不足,只好kill了。kill以后,ioutil依然是100%,读入速度没变,写入速度达到读取速度。
kill之前process状态为
[code]
| 11659556 | root | localhost | quad | Query | 84097 | manage keys | ALTER TABLE T1 ADD INDEX I1 (C1, C2) |
[/code]
kill之后变成
[code]
| 11659556 | root | localhost | quad | Killed | 84097 | manage keys | ALTER TABLE T1 ADD INDEX I1 (C1, C2) |
[/code]
传言回滚会耗费两倍以上的时间(24小时*2=48小时),实测发现十分钟内搞定。完成后lsof未见那两个30G的文件,df查到磁盘空间已经释放。

后又用17G的中表进行测试,半个小时生成的tmp文件200M,所此估算约需要42小时,放弃之。

下面是建议:

- 阅读剩余部分 -

简要说一下流程:
1、流量全切到主上。
2、停所有的从:stop slave
3、查所有从库的状态,找到数据最新的那个,其它从库使用START SLAVE UNTIL同步到跟他一致。
[code]
START SLAVE UNTIL MASTER_LOG_FILE = 'log-bin.00xxxx', MASTER_LOG_POS = ****;
[/code]
4、在新主上找最大的log-bin文件,并用mysqlbinlog查到最后一个序号。长的是这个样子的:
[code]
# at 31013843
[/code]
5、其它从库的主切到这个从上,并启动各从库的同步。
[code]
CHANGE MASTER TO MASTER_HOST='xx',MASTER_USER='xxx',MASTER_PASSWORD='xx',MASTER_LOG_FILE='xxx', MASTER_LOG_POS=xxx;
start slave;
[/code]
6、启动新主的同步。同步完成后,就可以把流量切到新的主从上了。确认流量安全切完后,新主可以stop slave,停老主库。

今天有一台老服务重启失败,异常如下
[code]
org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /***
[/code]

挑了一台zk看了一下,数据正常。找到Mode为leader的那一台查看,数据也正常。郁闷了一会。

启动时,抓了一下服务连接的zk列表,发现其对一台follower的zk有多个连接,其它的仅有一个连接,怀疑多个连接的zk有问题。
用zkCli.sh连上去看了一眼,果然有问题,仅有zookeeper一个结点,业务结点全无。

集群配置信息正常,且当前结点为follower,数据却是错的,或者说数据丢失。导致这个问题的原因未找到,后续有结果了补充。

解决办法:
停zk,删除data下的version-2结点,启动zk。zk恢复正常,业务服务启动也恢复正常~

因为zk数据已经持久化到本地data的version-2下,单纯重启无效,只能清空后启动,从别的zk上同步数据过来。

在AWS的服务器上碰到了scp占用cpu100%的问题,通过kerberos认证。以下是收集到的信息,为后续解决作为参考。
[code]
#ps auxfww
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1140 0.0 0.0 19712 996 ? Ss Apr27 3:06 crond
root 29599 0.0 0.0 44836 1344 ? S 10:10 0:00 \_ crond
root 29601 0.0 0.0 8700 984 ? Ss 10:10 0:00 | \_ /bin/sh -c cd /xxx;sh xx_log_hourly.sh 1>>/data/logs/hourly.log.`date +%y-%m-%d-%H`.log 2>>/data/logs/hourly.error.`date +%y-%m-%d-%H`.log
root 29602 0.0 0.0 8704 1056 ? S 10:10 0:00 | \_ sh xx_log_hourly.sh
root 29672 0.0 0.0 53900 1904 ? S 10:11 0:00 | \_ scp root 10.x.0.y /data/logs/stat.log.2015-11-04_09 /data/logs/stat.log.2015-11-04_09.12
root 29673 99.6 0.0 58416 3380 ? R 10:11 650:16 | \_ /usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -lroot 10.x.0.y scp -f /data/logs/stat.log.2015-11-04_09
root 4658 0.0 0.0 44836 1344 ? S 19:10 0:00 \_ crond
root 4662 0.0 0.0 8700 988 ? Ss 19:10 0:00 \_ /bin/sh -c cd /xx;sh xx_log_hourly.sh 1>>/data/logs/hourly.log.`date +%y-%m-%d-%H`.log 2>>/data/logs/hourly.error.`date +%y-%m-%d-%H`.log
root 4663 0.0 0.0 8708 1056 ? S 19:10 0:00 \_ sh xx_log_hourly.sh
root 4766 0.0 0.0 53900 1904 ? S 19:10 0:00 \_ scp root 10.x.0.z /data/logs/hours/access.log.2015-11-04-18 /data/logs/access.log.2015-11-04-18
root 4767 99.6 0.0 58412 3336 ? R 19:10 113:23 \_ /usr/bin/ssh -x -oForwardAgent no -oPermitLocalCommand no -oClearAllForwardings yes -lroot 10.x.0.z scp -f /data/logs/hours/access.log.2015-11-04-18
[/code]
简单总结:
这两个操作是完全相对的脚本,对应不用的服务器,平时正常,分别在10:10时与Y服务器scp时有问题,另一个是19:10时对Z有问题。

- 阅读剩余部分 -

之前碰到过一次,需要查一批正在运行的脚本的调用关系,用ps输出树状结果以方便查看。
当时没记,备忘一下。实际上用ps --help后,找forest字样就是了,f应该是forest的简写。
树状结果的参数是f,比如,用ps auxf执行的结果,其中有部分会是类似这个样子的
[code]
root 6788 0.0 0.0 64644 1236 ? Ss Feb04 0:00 /usr/sbin/sshd
root 6135 0.0 0.0 98860 4528 ? Ss 14:27 0:00 \_ sshd: [email protected]/1
root 6139 0.0 0.0 108636 1824 pts/1 Ss 14:27 0:00 | \_ -bash
root 6185 0.0 0.0 61168 4312 pts/1 S+ 14:28 0:00 | \_ ssh aa.bb.cc.dd
root 6715 0.0 0.0 98860 4492 ? Ss 15:14 0:00 \_ sshd: [email protected]/3
root 6719 0.0 0.0 108636 1824 pts/3 Ss 15:14 0:00 \_ -bash
root 6748 0.0 0.0 108448 1040 pts/3 R+ 15:14 0:00 \_ ps auxf
[/code]

ps结果只显示一行,超长自动截断的问题,也可以通过参数ww来控制,ps --help中找到wide output就是了。

目前的做法:
每个功能点独立实现,有重发标志位及App本地的唯一标识。平台中的功能点发现重发标志后,根据唯一标识确认是否已经成功。来确定返回结果。

可以的做法:
平台统一增加重发标志参数,唯一标识用现有的callId。平台中设定哪些接口需防重发,及重发的有效时间,收到非重发请求时,根据用户及唯一标识缓存结果到有效时间,重发命中时直接返回。