OneProxy :: 发布6.2.x版本,提供强一致性的读写分离解决方案,建议更新!

经过三年的发展,OneProxy在通信、保险、金融、互联网等多个行业落地,为多个客户提供读写分离、分库分表等数据库高可用和可扩展解决方案,也对我们的产品提出了更高的要求。其中一个需求便是在读写分离场景下,如何保证读的强一致性?读写分离技术上虽然是透明的,但业务逻辑上并不一定能做到透明,更新操作后面的查询操作,通常需要保证读到更新的结果。以前建议用户梳理业务代码,使用hint的方式来强制从主库读取,如下所示:

select /* master */ ... from ...

在实际场景中,梳理业务代码是一件成本非常高的事情,也许是根本不可行的事情;另一方面即使投入足够的人手,也不一定能做到100%的覆盖率。在中间件上可以通过记录表更新时间点的方式,实现强一致性的读写分离,可以让用户无须花费大量的人力物力去梳理业务代码。从6.2.0版本开始,做出了如下的改变:

  • 默认保证当前会话的强一致性读,即更新操作后总能读到最新的数据,再不用担心读不到刚刚更新的数据了;也可以设置成全局(当前实例范围)所有会话都实现强一致性读。
  • 改进主从时延检测的方式,以前版本需要配置复制管理账号才能检测主从时延(通过show slave status命令),否则将不管复制时延。现在不需要配置了,即默认情况下都会检查后端MySQL节点的复制时延,采用OneProxy特有的检查逻辑(不依赖于MySQL复制)。
  • 保证前后版本的兼容性,可以方便地从早期版本升级,降级回早期版本。

从老版本升级到6.2.x版本后,如下参数将不再有效,可以从配置文件中移除:

......
repadmin-username       = ...
repadmin-password       = ...
proxy-replication-check = ...
......

可以说,从应用感知角度来讲做到了去读写分离的效果,无须关心后端有没有实现读写分离,真正实现单库感知,可以说让所有MySQL数据库的应用都可以真正透明地扩展到读写分离的数据库环境。不得不说强一致性读会影响读写分离的效果,会让一些可以走从库的查询(比如方问更新表上的历史记录)走到主库,为了提升读写分离的效果,对于强制走从库的查询语句则不做强一制性要求,如下所示:

select /* slave */ ... from ...

可以梳理业务逻辑,将明确不需要强一致性的查询调用加上走备库的hint,这个反向业务梳理会比较容易,仅需要在读写分离效果较差的时侯估些优化。可以通过如下测试用例来验证强一致性读写分离的效果:

update t_rwsplit set col2 = col2 + 1 where id = 2;
-- from master
select id, col2 from t_rwsplit where id = 1;
-- from master
select id, col2 from t_rwsplit where id = 1;
select sleep(1);
-- from slave
select id, col2 from t_rwsplit where id = 1;
-- from slave
select id, col2 from t_rwsplit where id = 1;

建议所有OneProxy用户(基本上都用了读写分离功能)都升级到6.2.x版本,享受一下强一致性的读写分离解决方案,通过客户端jar包方式的读写分离将无法透明做到读写分离的强一致性读,是时侯切换到OneProxy了。