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

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

Atlas几种常见故障解决(不定期更新)_第1张图片



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,超时亦退出)。

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后端的连接数也满了可能会报以下错误:

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数量:

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文件:

# cat .bash_profile 
# .bash_profile
...
...
export PATH
ulimit -n 16384