<返回更多

快速实现wordpress迁移到RadonDB上

2020-03-16    
加入收藏

作者: 吴炳锡

作者介绍: 知数堂联合创始人及MySQL高级讲师,3306π社区联合创始人,腾讯TVP成员。

本文大概5500字,阅读大概需要15分钟,建议电脑前阅读。大纲如下:

可以关注知数堂腾讯课堂上我分享的RadonDB相关视频。

最近发现RadonDB在特性中引入一个新特性:Single table 到分区表快速转换,另外还引进了一个优秀的特性,把现有的MySQL库直接attach到Radon下面。看到这两个特性真是太赞了。可以非常方便用户实现原来的单表,快速变成拆分表,一条命令搞定。具体的issue参考:https://github.com/radondb/radon/issues/436 而且这个特性会在1.0.8这个版本发布。下面我们一块来体验一下吧。该文档可以用于先看看整体思想上有一个认识后再行动。

利用Radon attach获得的好处

基本环境及架构描述

这里为了更清楚整个过程,采用全部自建环境:单机多实例环境 安装:LAMP环境,可以用运行wordpress确认,在单库环境下是正常的。wordpress使用数据库端号:3306端口。为了看来了来效果,我在增加一个实例:3307 端口的数据库。

这里只是一个功能测试,所以不在给MySQL做高可用,如果需要高可用可以搭建xenon环境。Radon安装,可以看到前面章节,启动一个空的radon:

./bin/radon -c ./radon.json >radon. log2>& 1&

Radon配置如下

  1. {
  2. "proxy" : {
  3. "endpoint" : ":3316" ,
  4. "meta-dir" : "bin/radon-meta" ,
  5. "peer-address" : ":8080"
  6.  
  7. "audit" : {
  8. "audit-dir" : "bin/radon-audit"
  9. },
  10. "log" : {
  11. "level" : "INFO"
  12. },
  13. "monitor" : {
  14. "monitor-address" : "0.0.0.0:13380"
  15. }
  16. }

添加MySQL到Radon中,在Radon进程所在的机器上执行:

  1. curl - i - H 'Content-Type: Application/json' - X POST - d '{"name": "backend1", "address": "192.168.0.2:3307", "user":"wubx", "password": "wubxwubx", "max-connections":1024}' http : //127.0.0.1:8080/v1/radon/backend

参数说明:

  1. {
  2. "name" : 后端节点命名,要求唯一,
  3. "address" : 后端 MySQL 连接串,
  4. "user" : MySQL 连接用户名,
  5. " password ": 数据库连接密码,
  6. " max - connections ": 最大支持多少个连接连后后端DB中, 加入Radon后也可以启到一个连接池的作用。
  7. }

整个环境节架构如下:

环境确认:博客链接3306端口,确认wordpress工作正常。

把wordpress库加入到Radon中

  1. mysql - h 192.168 . 0.2 - P3316 - uwubx - pwubxwubx
  2. mysql > radon attach ( '192.168.0.2:3306' , 'wubx' , 'wubxwubx' );

观察日志输出:

  1.  
  2. ...
  3.  
  4.  
  5.  
  6.  

从日志中可以看出来, Radon把原库直接挂载到Radon下面,把原始3306库下的wubx库下表注删到radon下面,同时把配置写到:bin/radon-meta/backend.json & bin/radon-meta/wubx/ 这个目录。同时也在3307两个原始节点上建出来: wubx库(日志:frm.write.database[db:wubx]),但没有表。这里看一下backend.json内容:

  1. {
  2. "backends" : [
  3. {
  4. "name" : "backend1" ,
  5. "address" : "192.168.0.2:3307" ,
  6. "user" : "wubx" ,
  7. "password" : "wubxwubx" ,
  8. "database" : "" ,
  9. "charset" : "utf8" ,
  10. "max-connections" : 1024 ,
  11. "role" : 0
  12.  
  13. {
  14. "name" : "192.168.0.2:3306" ,
  15. "address" : "192.168.0.2:3306" ,
  16. "user" : "wubx" ,
  17. "password" : "wubxwubx" ,
  18. "database" : "" ,
  19. "charset" : "utf8" ,
  20. "max-connections" : 1024 ,
  21. "role" : 1
  22. }
  23. ]
  24. }

从上面配置上可以看到:192.168.0.2:3306也直接挂载了Radon下面。从上面的配置中,可以看到: 192.168.0.2:3306 在Radon中成为一个IP:PORT的后端存储节点,另外Role:1 表示是一个attach上来的节点。

通过radon-meta对应库下的表分布对应关系查看:

  1. cat bin / radon - meta / wubx / wp_users . json
  2. {
  3. "name" : "wp_users" ,
  4. "slots-readonly" : 0 ,
  5. "blocks-readonly" : 0 ,
  6. "shardtype" : "SINGLE" ,
  7. "shardkey" : "" ,
  8. "partitions" : [
  9. {
  10. "table" : "wp_users" ,
  11. "segment" : "" ,
  12. "backend" : "192.168.0.2:3306" ,
  13. "listvalue" : ""
  14. }
  15. ]
  16. }

这里Single表即是没进行分库分表。所有的库都位于192.168.0.2:3306这个端口下wubx库下。架构如下:

现在把wordpress中配wp_config.php的配置从原来的3306连接指3316(radon)端口,可以发现,也可以正常对外提供服务了。Radon中遇到Single表的情况下是把SQL透明下发到后达。所在这里Radon更相当于一个TCP的代理层,主要可以启到“连接池”,审计等相关功能。接下来,我们可以看看Radon带来的福利了,例如:审计, 透明自动拆分, 并行执行, 分布式事务 等功能了。

利用wordpress体验Radon的透明分库分表

我们知道wordpress最大表是wpposts这个内容表,当我们Blog积累的内容足够多的情况下, 该表也许会成为一个瓶颈。这里我们对wpposts表做一次从single表到拆分表的转换:

  1. MySQL > RADON RESHARD wp_posts to new_wp_posts ;
  2. MySQL > alter table wp_posts rename wp_post_bak ;
  3. MySQL > alter table new_wp_posts rename to wp_posts ;

首先利用Radon reshard 把原来一个非拆分表,变成一个新的拆分表, 这里有一个不错的设计, 该操作完,也不会把wp_posts表删除,这是一个不错的设计。后面利用改表名后,再来看看业务运行情况。现在的架构如下 :

做完以上动作Wordpress白页了,内容页显示不出来,从Radon的报错日志(radon.log)中发现Radon还没支持 SQLCALCFOUNDROWS 这个函数。所以可以通过,查询源码中:

主要处理和wpdb->posts这个查询有关found_rows就可以,处理办法:

  1. if ( ! $q [ 'no_found_rows' ] && ! empty ( $limits ) )
  2. $found_rows = 'SQL_CALC_FOUND_ROWS' ;
  3. $found_rows = '' ;

再来确认:Blog又可以工作了。因为wordpress的分页用到了SQLCALCFOUNDROWS这个功能,所以唯一不爽的地方,没分页了。

再来看一下wpposts表在后端节点的分布情况:

cat bin/radon-meta/wubx/wp_posts.json

  1. {
  2. "name" : "wp_posts" ,
  3. "slots-readonly" : 4096 ,
  4. "blocks-readonly" : 64 ,
  5. "shardtype" : "HASH" ,
  6. "shardkey" : "ID" ,
  7. "partitions" : [
  8. {
  9. "table" : "wp_posts_0000" ,
  10. "segment" : "0-64" ,
  11. "backend" : "backend1" ,
  12. "listvalue" : ""
  13.  
  14. ...
  15. {
  16. "table" : "wp_posts_0031" ,
  17. "segment" : "1984-2048" ,
  18. "backend" : "backend1" ,
  19. "listvalue" : ""
  20. },
  21. {
  22. "table" : "wp_posts_0032" ,
  23. "segment" : "2048-2112" ,
  24. "backend" : "backend1" ,
  25. "listvalue" : ""
  26. },
  27. ...
  28. {
  29. "table" : "wp_posts_0063" ,
  30.  
  31. "backend" : "backend1" ,
  32. "listvalue" : ""
  33. }
  34. ],
  35. "auto-increment" : {
  36. "column" : "ID"
  37. }
  38. }

从以上定义来看 wp_posts以ID用HASH的方式给给拆分成64个物理表,实质上拆分成了4096个slot, 每个物理子表接受一个区间的slot服务, 并完美的迁移到Radon集群下面节点上,如果有多个Backend,该动作会把拆分后的表均匀的分到其它节点上,在joins查询各方面完美。限于篇幅问题,这里不再展开。如果对于拆分表后SQL是怎么运行的有兴趣,可以连接入Radon中,运行: explain 具体的SQL看一下 Radon SQL改写。

这里其实可以有一个大胆的尝试,利用attach功能,把小表跑在attach节点上,大表跑在Radon拆分的节点,然后加多个attach节点,这样下面整体的可管理性更强。这个方案需要进一步测试和官方确定是不是可以用。单个attach上去的节点也有点Radon中单独建的Single table作用。

特别注意事项点如果把现有的业务数据库直接加入到Radon中,原来的DB不要在做为Backend加入了。操作上就象上面操作,直接attach上去,就可以使用了,就行。

总结

通过本案例可以看出来,Radon对于现有项目迁移到分布式环境有着不错的支持方案,对于SQL丰富度支持,也不错,对于wordpress的SQL基本可以原生不动的迁移过来,可以说Radon对SQL的支持复杂度也上了一个新台阶。另一方面, 对于MySQL一些内置函数,支持不友好。从Radon代码上看,Radon对于支持的指令都是严格处理,拿一个show table status; 这个指令的处理,一般的中间件,就是直接传到后端第一个节点上,获取数据返回就ok了,但Radon的处理是把这个请求会发到后端所有的节点,然后把结果进行合并后,返回,这点上感觉Radon做事上是力求正确。不是单纯的兼容。所以最后,看到Radon在github开源项目上新的feature也都比较让人激动,听说这些功能也是一些互联网公司在免费使用Radon后给官方提需求,青云的小伙伴认真的把这些需求也加到了issue中,排期进行。据了解,他们也非常欢迎大家提的需求。个人的另一个感受,Radon代码风格很爽,可以研究一下Radon的代码,学习一下利用golang开发MySQL中间件:)。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>