基本架构: 写请求全部定向到主库,数据通过日志异步复制到副库,读请求可根据情况路由到主库或者副库,分散读压力目前读的压力平均分到3台服务器,性能提升在20-30%左右


中间件连接池会根据 CONNECTION的AUTO COMMIT 状态来缓冲连接,如果过程中AUTOCOMMIT的值发生变化,则之前缓存的数据库连接会失效. 导致重新建立连接性能下降. JDBC事务控制恰恰会主动把CONNECTION的 AUTOCOMMIT属性设为 FALSE (默认为TRUE). 如果禁用事务,数据完整性得不到保证并且会引发其他错误. 好在ONEPROXY最新版本已经解决了这个问题  (题外话,好像MYCAT连接池的设计思路也类似,使用时有没有坑有待验证)


在高并发下 ONEPROXY 中间件的连接池大小要调整

ONEPROXY 中间件的字符集要设置成UTF8,默认是GBK, 如果没有设对,那么对象序列化的BLOB存到MYSQL数据库会损坏导致无法反序列化
 


在写主数据库,读多个副数据库的架构下,最常见的问题是数据复制不及时,导致定向到副库的读请求没有读到数据ONEPROXY 通过事务控制来解决这个问题,如果读和写操作都在一个事务里,那么他们都会到被定向到主数据库所以事务的边界控制很重要,但是现在应用的代码非常混乱,导致控制事务很困难,ONEPROXY提供了一个折衷的方案,可指定对于某个表定向到主库/副库,现在对于读写都很频繁的表,购物车,订单,订单行,促销,支付记录等一律指定路由到主库错误率目前基本控制在零. 曾经也尝试过用PERCONA的参数 WSREP_CAUSAL_READS 来解决上述问题,但是并没有效果


目前对于ORACLE DB的支持还不够完善