1）使用atlas却发现“读库闲置，框架还是去主库读写数据”

配置完atlas之后，发现使用jdbc框架的话，读库和写库各司其职，但是使用mybatis框架之后，就发现框架的读写都去了主库，把读库放置一边，那么这种情况是因为“有事务存在的话，atlas就会强制走主库”，遇到这种情况就检查一下是否有事务的存在，比如@Transactional，如果要解决的话，就加上“@Transactional(propagation=Propagation.NOT_SUPPORTED)”即可。

2）自动读写分离挺好，但有时候我写完马上就想读，万一主从同步延迟怎么办?

SQL语句前增加 /*master*/ 就可以将读请求强制发往主库。在mysql命令行测试该功能时，需要加-c选项，以防mysql客户端过滤掉注释信息。不过这不能从本质上解决问题，使用Atlas需要考虑到这点，提高主机的IO性能，加大memory可以缓解延迟症状，但依旧不能避免延迟的出现，尤其是读多写少的应用。

3）resource limit问题

atlas有自己的连接池，会吃掉很多CPU, php应用端改用短链接来连接atlas, 这时候atlas对php发送来的sql只负责验证和转发的操作，后端DB的连接由atlas自己管理,未使用的连接线程进行剔除操作(DB的wait_timeout和interactive_timeout设置为300s,超时亦退出)。

1
2
3
4
5
6
2014-04-12 20:56:29: (warning) (libevent) event_del: event has no event_base  set .
2014-04-12 20:56:29: (critical) last message repeated 5  times
2014-04-12 20:56:29: (critical) network-conn-pool-lua.c.144: socket() failed: Too many  open  files (24)
2014-04-12 20:56:29: (warning) (libevent) event_del: event has no event_base  set .
2014-04-12 20:56:30: (debug) chassis-unix-daemon.c:168: 12951 returned: 12951
2014-04-12 20:56:30: (critical) chassis-unix-daemon.c:196: [angel] PID=12951 died on signal=11 (it used 16 kBytes max) ... waiting 3min before restart

如果MySQL后端的连接数也满了可能会报以下错误:

1
2
3
2014-11-13 12:21:07: (critical) network_mysqld_proto_password_scramble: assertion `20 == challenge_len' failed
2014-11-13 12:21:07: (warning) (libevent) event_del: event has no event_base  set .
2014-11-13 12:21:07: (critical)

可以临时增加MySQL connection数量:

1
echo  -n “Max processes=SOFT_LIMIT:HARD_LIMIT” >  /proc/ `pidof mysqld`/limits

关于Too many open files错误，可能由两种情况引起:

一、php长连接连接到atlas后，每个线程占用一个FD,直到超出系统资源限制而出现too many错误;

二、php应用端发送到atlas的sql过多，大量并发的情况下,linevent维护的队列过多，每个event吃一个FD，超出系统资源限制引起too many错误;

避免too many错误,增加用户的ulimit值加大FD的使用量,可增加系统ulimit 资源到 ~/.bash_profile文件或/etc/security/limits.conf文件:

1
2
3
4
5
6
# cat .bash_profile 
# .bash_profile
...
...
export  PATH
ulimit  -n 16384

本文转自苏幕遮618 51CTO博客，原文链接:http://blog.51cto.com/chenx1242/1903186

ITPub博客

Atlas几种常见故障解决

最新文章