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
|
