2015年11月

需要把Confluence的内容备份下来,离线阅读。本来以为很简单,却花了挺长时间。备忘一下。
页面上的导出成pdf,只是当前的一个页面,不支持中文,而且看起来好像只有标题,内部部分基本上全丢。
导出为Word文档也一样。

在“管理”面板的一堆功能里,只有设置字体文件及pdf布局样式之类的东东。
在“设置”面板里同样也没有。

很偶然的在“工具”菜单里的“以层级方式查看”中,有一个“高级”table,里面有导出pdf、html和xml,其中的导出html是支持中文而且是全站的。
会生成一个zip包。里面是一批html及相应的附件,以index.html为起始页。

场景比较简单:PostgreSQL仅用来做序号生成器。
这种单纯的nextval操作,搞个主备出来很怪异,正赶上停主库所在服务器,写点东东备忘一下。

步骤如下:
1、停备库
[code]
su - postgres -c "pg_ctl stop -D /data/pgsql_data"
[/code]
2、把数据目录下的recovery.conf文件改名,比如:
[code]
mv recovery.conf recovery.conf.bak
[/code]
3、改postgresql.conf中的hot_standby = on为off,或者前加#注释掉。
4、启动备库(现在已经不是备库了)
[code]
su - postgres -c "pg_ctl start -D /data/pgsql_data"
[/code]
5、把序列号调整为合适的值(确保在切流量过来之前比当前主库的大即可)
[code]
SELECT setval('xxx_id_seq',10000001);
[/code]

如果不确定当前值,可以直接查询
[code]
xxxx=> select * from xxx_id_seq;
sequence_name | last_value | start_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called
---------------+------------+-------------+--------------+---------------------+-----------+-------------+---------+-----------+-----------
xxx_id_seq | 9553600 | 1| 1 | 9223372036854775807 | 1 | 1 | 0 | f | t
(1 row)
[/code]

对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有问题。

- 阅读剩余部分 -